Anda di halaman 1dari 237

Avamar 6.

1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 1 Course Introduction

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 1 Course Introduction

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

Avamar 6.1 Technical Differences

IMPORTANT: It is most likely the case that restoring large files by performing an VM Image restore will be faster than using FLR. Session Management

Improved the management of a users session by localizing all users activities to a single proxy Single instance of a mounted backup and VMware Tools connection per user session for the life of a session Lower memory profile Lower number of vCenter/VMware Tools connections Resources are tied to a given user session Overall: Lower resource usage and improved security

Session Management now enables the user to take advantage of multiple Proxies concurrently for multiple user sessions. Previously, all browse requests hit a single proxy and restore work orders to first available Proxy

Not good for multiple user sessions Resource utilization and security was poor

User Session are best effort distributed across multiple Proxies. More Proxies means better distribution of User Sessions.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

Avamar 6.1 Technical Differences

This animation shows the automated steps undertaken when an image backup is triggered. 1. 2. 3. 4. 5. Work Order for VM Image Backup is initiated by MC to the agent on the proxy appliance. Architecture Determined by VCBImage identifying the current hypervisor for the VM, and its location on which datastore VCBImage initiates a Snapshot of the VM Proxy Appliance mounts snapshot also using VCBImage Backs up VM folder to Avamar using avtar

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

Avamar 6.1 Technical Differences

This animation highlights the operations triggered by an image restore. 1. 2. MC issues the restore work order to the proxy If a request is made for a New VM for recover, the proxy will communicate this directly to the vCenter server, which will perform the action. Otherwise the target is the original, or other preexisting VM. Restore job will not be issued if the target VM is powered on. A VM snapshot is taken once the creation is complete Avtar ships the image recover data (using Changed Block Tracking - CBT - if enabled and available) to the proxy server, which forwards data to datastore VM is registered and ready (though powered off)

3. 4.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

Avamar 6.1 Technical Differences

This animation indicates the processes involved to allow the ability to browse the contents of an Image backup within MC. 1. 2. 3. 4. When you click on the Browse for Granular Restore button, MC issues Browse request to Proxy. The VMware FLR plugin accepts the requests The FLR plugin on the proxy triggers an AvFS mount of the folder containing the backup files associated with the request. The VMware VDDK API on the proxy has the ability to view NTFS, ext2, ext3, and LVM file systems from a VMDK file. It does this over the AvFS mounted connection The Proxy forwards file/folder structure back to the MC to display to console, and updates the list as subdirectories are selected.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

Avamar 6.1 Technical Differences

This animation indicates the actions which are undertaken when selecting a recovery destination for an FLR. After selecting the files/folders for recovery, the MC user then chooses a destination. It must be a VM. When clicking on the Filesystem, the following actions take place to allow the user to navigate the target filesystems. 1. 2. The browse request is sent to the proxy, which uses VMware VIX API to browse guest filesystems only works if VM is powered on, and has VMware Tools installed It forwards the fs info to management console.

Disable the option Restore everything to its original location. To restore everything to original location, perform the following steps: - Select Restore (Browse for Granular Restore/FLR Yellow button) - Navigate on the destination VM to the original path. - Input local administrator credentials of destination VM. - Navigate to original location.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

Avamar 6.1 Technical Differences

This animation indicates the internal processes which activate during the actual file recovery. 1. The MC sends the work order to the proxy, which uses its AvFS connection to access the VMDK, then the VMware VDDK API to extract the files selected for recovery. The Proxy then uses VMware VIX API to copy files to guest VM filesystems.

2.

A side effect of having a smaller resource footprint and improved security, is that users will not be able perform concurrent FLRs. The user impact should be minimal. Multiple FLR work orders will be queued per user session. After the current FLR finishes, the user is free to browse the next backup and target VM for the next FLR. User Session are best effort distributed across multiple FLR Proxies. User Sessions maybe assigned to the same FLR Proxy in which case all operations are handled one at a time and queued.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

10

Avamar 6.1 Technical Differences

MC Client (aka Proxy) will have 5 plugins registered Linux VMware File-Level Restore Linux File System Windows VMware Image Linux VMware Image Windows VMware File-Level Restore AvFS/axionfs on the Proxy is configured in the background

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

11

Avamar 6.1 Technical Differences

1.

Configure vCenter-to-Avamar authentication


2. 3. 4.

Either Install a certificate on the Avamar MCS Or turn off authentication for all vCenter-to-Avamar MCS communications With specific rights, outlined in the Avamar VMware Guide. Use account created above. Insure two-way name resolution before hand Deploy the appliance (ova) through vSphere downloaded from the Avamar server) network settings configured at this point Activate with the Avamar Server upon first boot The only supported mechanism for registering/activating with the Avamar server is on the console on first boot and on subsequent boot. On subsequent boot, you have the opportunity to register with a different Avamar server. It will also prompt for root password changes on the source Avamar. DO NOT LOGIN TO THE PROXY AND RUN AVREGISTER!!! THE PROXY WILL NOT BE CONFIGURED CORRECTLY!!!

Create dedicated vCenter user account

Add vCenter server to MC Deploy Proxy

In MC, Associate proxy/proxies with datastores and groups

5. Add VM clients to MC Choose Changed Block Tracking


Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

12

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

13

Avamar 6.1 Technical Differences

Backup

Scheduled or on-demand Optional: CBT/Data Domain (CBT is a check made upon adding VMware backup clients, and again upon dataset configuration) (If a Data Domain appliance has been configured for the Avamar server, you may select the check box in the dataset configuration to send VMware image backup data to Data Domain) Proxy can process single stream only / others are queued Individual disks / full VM To original VM, different-but-existing VM, new VM To an ESX/ESXi host in the vSphere Click 'Browse for Granular Restore' button. Wait for browse and choose folders/files to restore. Select destination VM. Input local administrator credentials of destination VM. Navigate to destination folder to restore.

Image Restore

File Level Recovery (FLR)

Same platform only VM must be powered on and VMware Tools installed.


Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

14

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

15

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

16

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

17

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

18

Avamar 6.1 Technical Differences

Thin-provisioned disks are virtual disks that "appear" to the VM as one size, but only consume up to the amount of data that is required by that disk. So, a 10 GB drive that is 50% utilized will only store 5 GB on disk (a traditional "thick" virtual disk would consume the entire 10 GB on disk) From Avamar 5.0 to Avamar 6.0, disk recoveries of Virtual Machines resulted in full-sized thick disks, even if the original VM had deployed thin disks. The end user could run a series of Vmware procedures to re-convert the disk back to thin. When backups are performed using Avamar 6.1 and the Unified Proxy, a per-disk flag is set for thin disks. When recovery is performed, it maintains the original thin architecture of the disk. This does not necessarily improve recover times, but does result in less space utilized on the datastore after a recovery, and most importantly, preserves the original architecture of the LUN. Note: There may be an issue where, for a virtual machine that is perpetually in the Off state, the thindisk flag may not be set. You can verify in the backup log whether this flag has been set as expected. A stun/unstun cycle will likely fix the issue. This cycle happens during certain VM operations including power on/off, suspend/resume, create/delete snapshot.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

19

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

20

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

21

Avamar 6.1 Technical Differences

The first couple of lines in the log shown here indicate that, for this backup, a couple of snapshots from previous backups needed removal before starting this backup. The highlighted area indicates the current non-Avamar snapshot architecture as discovered by VCBimage on the proxy. The asterisk indicates the current place in the tree of snapshots, which is important. That will be targeted as the place where VCBimage will take its snapshot for this backup.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

22

Avamar 6.1 Technical Differences

The log file also gathers information on the datastores, which can be useful information for a few things: Naming conventions (identify problems with things such as I18N mismatches) Free space (could be an issue, since were taking a snapshot, and especially with recovery)

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

23

Avamar 6.1 Technical Differences

Also shows all other VMs in the vCenter (capped at 30) - (17/17) indicates 17 VMs are shown out of a total of 17. If there were more than 30, such as 150, that section would be (30/150) - Also important for naming conventions

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

24

Avamar 6.1 Technical Differences

This section displays all of the files that currently comprise the VM. It is looking directly at the file structure through the datastore, rather than through vCenter. This example shows an excessive amount of files due to the multiple snapshots. The highlighted sections summarizes this by indicating that there are actually still only two disks, however 4 snapshots, and ctk files as well, which helps to explain the amount of files in play. Often on systems with many existing snapshots, there is a chance for fragmentation, where snapshot files may get orphaned, and future snapshots may be prevented.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

25

Avamar 6.1 Technical Differences

This section shows the detail of the disks, as directly related to the backup being attempted.

File(base) is the base VMDK Snapshot(base) is the current snapshot shown in a previous slide, which is used as the source for the Avamar snapshot Snapshot(curr) is the Avamar snapshot which is taken of snapshot(base) We are looking for size match on the following line between base & curr The lines after are verifying CBT match, and whether we will be able to use that for this backup The final line indicates information directly from vCenter: Is CBT enabled Is a thin disk (which will flag for new thin disk restore) Independent and SCSI flags

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

26

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

27

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

28

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

29

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

30

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

31

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

32

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

33

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

34

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

35

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

36

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

37

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

38

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 2 VMware Enhancements

39

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

Avamar 6.1 Technical Differences

Hyper-V Cluster

Join multiple Hyper-V servers together to form a Hyper-V Cluster


Clustered VMs

VMs can be configured as clustered VM is active on one node at a time but can migrate to other nodes A cluster node can also have local VMs
Clustered Shared Volumes (CSV)

New in Windows Server 2008 R2 Cluster disk model where multiple-nodes can write to the disk at the same time Only supported for Hyper-V Enables Live Migration

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

Avamar 6.1 Technical Differences

Backups coordinated via VSS Framework on Host OS

Backup of VM images Allows selection of individual VMs and Role-based access database (Initial Store) FULL backups only
No Change Block Tracking

Supports all VM OS types

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

10

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

11

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

12

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

13

Avamar 6.1 Technical Differences

1. Build a number of standalone Hyper-V servers 2. Attach shared storage via supported architecture 3. Configure a windows cluster comprised of the servers 4. Configure shared storage as Cluster Shared Volumes (CSV) 5. VMs created with storage housed on CSV can be configured as highly available VMs in the cluster. 6. VMs can also be created as standalone using either local storage or CSV

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

14

Avamar 6.1 Technical Differences

When one of the cluster nodes in a CSV configuration makes a soft shadow copy (as opposed to a VSS hardware based snapshot/clone), it requires full control of the I/O for that disk in order to maintain the consistency of the shadow copy. This is expected and desireable behavior. The downside for this during a Hyper-V environment is that any VMs stored on the CSVm but hosted on another Hyper-V server, will have their I/Os directed over the LAN from host to host, resulting in a potential performance impact. This animation shows the dataflow of such a situation.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

15

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

16

Avamar 6.1 Technical Differences

Using federated backup of all VMs in hv-cluster will result in backup work orders forwarded to the active hosting servers of the respective vms. In this example, the backup order will first go to the cluster itself, then for VM1, forward the work order to hv1 (the active host) to perform the backup. For vm2, it will forward to hv2, etc. It will ignore any non-clustered vms such as vm5 and vm6. To back those up, you will need to select them via their hosts (hv1 and hv3 respectively).

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

17

Avamar 6.1 Technical Differences

Recovery Overview ( to New VM)

Hyper-V VSS Writer supports restoring VMs to a different Hyper-V Server.


All files for the VM are restored. Restore one or more VMs from the same backup.

Hyper-V VSS Writer expects backup application to indicate where VM files should be
relocated to.

From Hyper-V perspective, same workflow as restoring a deleted VM on original


server. Restore Options

Select Hyper-V Server in Restore Destination Client Select Third Radio button in Restore Destination Choices Items Marked for Restore will display the VM files for the marked VMs.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

18

Avamar 6.1 Technical Differences

The Avamar Config Checker is located on the Avamar Server itself, as a zip file in the same Downloads folder as other Windows plug-ins. It supports MS SharePoint, SQL, Exchange and Hyper-V configurations, and provides a detailed report of its findings, with info, warning and fail messages to guide the user towards fulfilling the prerequisites.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

19

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

20

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

21

Avamar 6.1 Technical Differences

You can alternately browse the mounted VHD from with the GLR Proxy host for recoveries.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

22

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

23

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

24

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

25

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

26

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

27

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

28

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

29

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

30

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

31

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

32

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

33

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

34

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

35

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

36

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

37

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

38

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

39

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

40

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 3 Hyper-V Integration

41

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

Avamar 6.1 Technical Differences

Sybase has 2 other relational databases: (a) Sybase ASA (Adaptive Server Anywhere) -- an embedded relational database and (b) Sybase IQ -- a warehousing databases. These are totally different products from the Sybase ASE, and they are not supported by this Avamar plug-in

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

Avamar 6.1 Technical Differences

A Sybase server runs on a host. The Sybase server manages multiple databases. More than one Sybase server can run on a host simultaneously. If multiple servers are running on a host they are independent of each other (in other words, they cant touch each others databases). Each Sybase database has its own transaction logs. Databases do not share logs or log files. There are two main types of Sybase databases: Data and logs are in the same file. Data and logs are in different files. ---------------------------------------------------------------------------Sybase architecture For one host you can have one or multiple different Sybase versions installed. However, AvSybase in Greenville only supports one Sybase installation per Host Sybase 15.5 Server1 DB11 DB12 Server2 DB21 DB22 For one Sybase installation, you can create one or multiple Sybase servers (instances), each operates independently. For one Sybase installation, you can create one Sybase backup server that can be shared by multiple Sybase servers For one Sybase server (instance), systems databases (master, model, sybsystemprocs, etc) that are created during Sybase server (instance) creation, data and log for each database are on the same Sybase database device temp databases, system or user created, Avsybase always skips all temp databases for backup user databases that are created by users to save their data, Sybase highly recommend put data and log for each user database on different Sybase database devices

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

Avamar 6.1 Technical Differences

Two main types of Sybase databases:

Data and logs are in the same device


One file; System generated; not user defined

Data and logs are in different files.


Two files; user defined Comment: Generally, Sybase refers to it as "device" Data and transaction logs in the same device

Only database backups can be performed No Incremental backups (Transaction log) performed
Data and logs are in the different devices

Both Data and Transaction logs can be backed up independently Incremental backup (log) performed
When data and logs are in the same file transaction log backups cannot be performed. Only database backups can be performed. When the data and logs are in different files the logs can be backed up independently.
Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

Avamar 6.1 Technical Differences

The Sybase plug-in supports one stream per Sybase database. Therefore, multi-streaming means backing up multiple databases at the same time. The Sybase plug-in starts multiple avtars to perform the multi-stream backup (similar to Oracle plug-in). Multi-streaming is a feature that enables a single backup or restore operation to use multiple sessions (data streams) to the Avamar server. This option enables you to specify the maximum number of backup or restore sessions that can run concurrently. Despite the multi-stream option setting during a backup or restore, the Sybase plug-in creates two cache files for each database, a file cache and a hash cache. By default, the backup or restore multi-stream value is 1, and the software backs up or restores only one database at a time. You can specify a greater multi-stream value (for example, with the -max-streams option of the avsybase command) to back up or restore multiple databases at a time. A maximum multi-stream value of 10 is enforced only for GUI on-demand backups, scheduled backups, and GUI on-demand restores when the multi-stream is set in the Avamar Administrator.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

Avamar 6.1 Technical Differences

The Sybase plug-in supports two-node active-passive clusters on Solaris only. An activepassive cluster consists of multiple hosts (nodes) connected by a SCSI bus attached to a shared storage system. Cluster services such as disk services can be defined and assigned their own IP addresses and names (virtual cluster hosts). The services and their associated storage can migrate for failover between the nodes in the cluster. Backup or restore operations are configured for the virtual cluster host, and the operations run on the active node. If backups or restores are running during a failover, the operations fail. Failed backups and restores must be restarted manually on the new active node. SunCluster and Veritas Cluster are two separate cluster applications and AvSybase plug-in support both of them on Sun Solaris SPARC OS. For SunCluster (1) Two packages need to be installed: Avamar Client for Solaris and Avamar Sybase plug-in for Solaris (2) Run the suncluster-config.sh script after installation and start with passive SunCluster node For Veritas Cluster (VCS) (1) Three packages need to be installed: Avamar Client for Solaris, Avamar Cluster Client package and Avamar Sybase plug-in for Solaris (2) Run the avclusinstall script after installation and start with active VCS node
Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

Avamar 6.1 Technical Differences

A full backup can back up all the databases on the Sybase server, including the transaction logs for each database. If more than one Sybase server is on a host each Sybase server has to be backed up separately. Backups can be full (the data and logs are backed up) or incremental (only the logs are backed up).

Restore: CLI method A user performs a CLI restore by running the avsybase command with the required options at the operating system command line on the Sybase database host. A CLI restore can restore either one Sybase database or the whole Sybase server. GUI method A user performs a GUI restore by using the Avamar Administrator GUI and specifying the required plug-in options. A GUI restore can restore either one or more Sybase databases or the whole Sybase server. Sybase sql commands Sybase databases are backed up using the Sybase dump command: sql> dump database MYDB to my_backup_device Sybase databases are restored using the Sybase load command: sql> load database MYDB from my_backup_device

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

Avamar 6.1 Technical Differences

A CLI backup, started with the avsybase command on the operating system command line, has a similar workflow except the avagent process is not involved. The CLI backup details are obtained from the avsybase command options, not from an Avamar Management Console Server (MCS) work order. 1. The avagent process on the Sybase server (Avamar client) performs the following a) Polls the Avamar Administrator MCS service, which gives avagent a backup (snapup) work order: The backup workorder is an XML message with details about the backup to perform, including a list of Sybase databases or transaction logs to back up and information required to connect to the Sybase server: b) Starts the Sybase plug-in binary, avsybase, and passes the workorder to the avsybase process. For each database to be backed up, the avsybase process uses the Sybase Open Client/Server (OCS) API to issue a dump command to the Sybase server. The number of dump commands issued depends on the multi-streaming configuration. Each dump command specifies the database to be backed up. For each issued dump command, the avsybase process starts an avtar process. For each received dump command, the Sybase server launches a backup server that loads the libsybase_avamar.x library. Each Sybase backup server connects to a single avtar process and uses the libsybase_avamar.x library to pass the backup data to the avtar process. Depending on the specified backup destination, the avtar process writes the backup data to either the Avamar server or a Data Domain system.

2.

3. 4. 5. 6.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

Avamar 6.1 Technical Differences

A CLI restore, started with the avsybase command on the operating system command line, has a similar workflow except the avagent process is not involved. The CLI restore details are obtained from the avsybase command options, not from an MCS workorder. 1. The avagent process on the Sybase server (Avamar client) performs the following:

a. Polls the Avamar Administrator MCS service, which gives avagent a restore workorder: The restore workorder is an XML message with details about the restore to perform, including a list of Sybase databases to restore and information required to connect to the Sybase server. b. Starts the Sybase plug-in binary, avsybase, and passes the workorder to the avsybase process. 2. For each backup to be restored, the avsybase process uses the Sybase OCS API to issue a load command to the Sybase server. The number of load commands issued depends on the multi-streaming configuration. Each load command specifies the backup (database and transaction log) to be restored and places the database in offline mode if it is not already offline. 3. For each launched backup server, the avsybase process starts an avtar process. 4. For each received load command, the Sybase server launches a backup server that loads the libsybase_avamar.x library.

5. The avtar process reads the backup data from either the Avamar server or a Data Domain system. 6. Each Sybase backup server connects to a single avtar process and uses the libsybase_avamar.x library to read the backup data from the avtar process. Note: The Sybase server cannot create a database during a restore operation. If a database was lost, you must first create the database before you start the database restore. You should keep records of all the databases and their sizes on the Sybase system. Refer to the Sybase documentation for information on how to restore lost databases.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

10

Avamar 6.1 Technical Differences

Before you install the Avamar Plug-in for Sybase software on a client system, ensure that you meet all the client software and hardware requirements. To ensure that you meet all the software requirements, use the EMC Avamar Compatibility and Interoperability Matrix on the Avamar Support landing page at https://support.EMC.com/products/Avamar. Go to the Product Information section and then click the Avamar Compatibility and Interoperability Matrix link.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

11

Avamar 6.1 Technical Differences

1. Create the symbolic link for the libsybase_avamar.x library in


$SYBASE/$SYBASE_ASE/lib directory

2. Edit the avsybase script file to include Sybase OCS library path for
LD_LIBRARY_PATH, and restart avagent process For Windows Sybase environment: copy libsybase_avamar.dll library file to %SYBASE%/%SYBASE_ASE%/lib directory

1. 2. 3. 4.

Download and Install the Avamar client and plug-in for your OS Register/Activate Copy the Avamar Plug-in for Sybase library file Edit avsybase scrip to include OCS path for library

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

12

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

13

Avamar 6.1 Technical Differences

Needed to make connection to the appropriate database. DBA provides this info In the Browse Command Line Options dialog box, type the required information in the following fields: Sybase installation directory Type the full pathname of the Sybase installation directory for the server to be backed up, represented by $SYBASE on Linux or UNIX and %SYBASE% on Windows. Do not type the environment variable $SYBASE or %SYBASE% but type the actual text of the full pathname. For example, type /sybase instead of $SYBASE. ----------------------------------------------------Sybase server name Type the Sybase server name. It is not the Avamar serve name and it is not the hostname of the system where Sybase is installed. For example, type SERVER1. ----------------------------------------------------OCS library directory Type the full pathname of the Sybase OCS library directory, represented by $SYBASE/$SYBASE_OCS/lib on Linux or UNIX and %SYBASE%\%SYBASE_OCS%\dll on Windows. Do not type any environment variable but type the actual text of the full pathname. For example, type /sybase/OCS-15_0/lib instead of $SYBASE/$SYBASE_OCS/lib. ----------------------------------------------------------------Sybase username Type the Sybase username. Sybase user password Type the Sybase user password.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

14

Avamar 6.1 Technical Differences

Full backup option to back up all the data in the selected databases. Incremental backup option to back up the transaction logs of the selected databases. (Advanced) Incremental backup with no_truncate option option to run a Sybase dump transaction command with the no_truncate option, which performs an incremental backup that does not truncate the logs afterwards. Use this option in a disaster recovery situation only. Do not use this option in a regularly scheduled backup. (Advanced) Log truncation with truncate_only option followed by full backup option to run a Sybase dump transaction command with the truncate_only option, which truncates the logs. After the logs are truncated, the Sybase plug-in also performs a full backup of the database. Do not use this option in a regularly scheduled backup. (Advanced) Log truncation with no_log option followed by full backup option to run a Sybase dump transaction command with the no_log option, which truncates the logs without logging the truncation. After the logs are truncated, the Sybase plug-in also performs a full backup of the database. Use this option in a disaster recovery situation only. Do not use this option in a regularly scheduled backup (Advanced) Protected backup password password that the Sybase server uses with the Sybase dump command. Preprocessing script Type the name of a preprocessing script to be run immediately before the backup. Postprocessing script Type the name of a postprocessing script to be run immediately after the backup.
Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

15

Avamar 6.1 Technical Differences

If a full backup of the database has not been performed previously, the Sybase plug-in performs a full backup of the database instead of an incremental backup. During an incremental backup, the software backs up transaction logs of one or more databases, not the entire Sybase databases An incremental backup backs up the transaction log in a single database and, by default, truncates the inactive portion of the log after the backup. 1. The backup of tran log is per database. If you select one database, tran log for that database is performed; if multiple databases are selected, tran log for each of the selected databases is backed up; if you select the whole server, then all databases on the server will go through incremental backup 2. The incr backup will automatically be promoted to full backup for the following databases, whose tran log backup is not allowed by Sybase: - no full backup of the database has ever been performed since the database creation - data and log on same Sybase database devices, such as Sybase system databases - In-Memory Database (IMDB), Relaxed-Durability Database (RDDB) introduced in Sybase ASE 15.5 - Read-only databases During an incremental backup, the software backs up transaction logs, not the entire Sybase databases. or During an incremental backup, the software backs up transaction logs of one or more databases, not the entire Sybase databases.
Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

16

Avamar 6.1 Technical Differences

1. Restore Destination Client It's to specify which machine the Sybase database/server is recovered to. By default, the same host that's backed up is presented. If you need to recover to a Sybase server on a different host, Specify the different hostname in this field. 2. Restore Destination Choices This is at Sybase server (instance) level. Either restore to the original destination, which is the same Sybase server (instance) and database, or restore to different database or different Sybase server (instance). If you want to perform a relocated recovery to a different Sybase host, click Browse next to the Restore Destination Client box and select the destination host in the Browse for Restore Client dialog box. The Sybase host is referring to the machine/system level. You can relocated recover the database into a different machine, where there is another database on a Sybase server. For Restore Destination Choices: Select Restore databases to original destinations (same server and database) to restore databases to the same server and database names as used in the source databases. In this case, all the databases to be restored must already exist on the destination server. Select Restore databases to different destinations (different server and database) to perform a relocated restore of databases to different server or database names than used for the source databases. All the databases must be restored to the same destination server, either the source server or a different-named server. Relocated Recovery is a restore of data from a backup to a different location on the same host or an alternate host. The destination is referring to the Sybase server and database level. You can relocated recover the database into different database on the same or different Sybase server. For example, you can perform a relocated recovery to recover a database to a different-named destination database on a different Sybase server on a different host. The destination database must already exist on the destination server and must have the same storage layout as the source database.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

17

Avamar 6.1 Technical Differences

Sybase installation directory Type the full pathname of the Sybase installation directory for the destination server, represented by $SYBASE on Linux or UNIX and %SYBASE% on Windows. --------------------------------Do not type the environment variable $SYBASE or %SYBASE% but type the actual text of the full pathname. For example, type /sybase instead of $SYBASE. -------------------------------OCS library directory Type the full pathname of the Sybase OCS librarydirectory, represented by $SYBASE/$SYBASE_OCS/lib on Linux or UNIX and %SYBASE%\%SYBASE_OCS%\dll on Windows. Do not type any environment variable but type the actual text of the full pathname. For example, type /sybase/OCS-15_0/lib instead of $SYBASE/$SYBASE_OCS/lib. ------------------------------Select Enable debugging messages if you want to enable logging of debug messages. --------------------------------Protected backup password Type the same password that was used for a password-protected backup, (dump) which the Sybase server uses with the Sybase load command option with passwd= to restore the backup -------------------------------Enable debugging messages if you want to enable logging of debug messages -------------------------------Point-in-time recovery timestamp For a point-in-time recovery, type the timestamp ---------------------------------Preprocessing script Type the name of a preprocessing script to be run immediately before the backup. Postprocessing script Type the name of a postprocessing script to be run immediately after the backup. ----------------------------------Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

18

Avamar 6.1 Technical Differences

Automatic restore to a specified time The Sybase plug-in can restore a Sybase database to the latest backup time or to a specific point in time. By default, the Sybase plug-in software restores a database to the latest time contained in the last transaction log backup, which might not be the current point in time. To restore a database to the current time, you should perform a transaction log backup of the database (if possible) prior to performing the database restore. The log backup would contain the most recent logs, and would be used during the database restore. The point-in-time should be later than Old time and before the New time of the incremental (transaction log) backup you selected Old Time: the time of the oldest transaction stored in the backup New Time: the time of the most recent transaction stored in the backup. (dump command starts) To view these time range of backup records: > avsybase --operation=list-times .

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

19

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

20

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

21

Avamar 6.1 Technical Differences

A CLI browse operation with the Sybase plug-in software is an on-demand browse operation that you perform by running the avsybase command (or avsybase.exe on Microsoft Windows) with the --operation= browse option and other supported options on the operating system command line. The avsybase binary is located in the bin subdirectory in the Avamar client installation directory. To launch the CLI, open a command prompt and change to the appropriate directory to run the avsybase command. The following are the default directory locations of the avsybase binary on the supported operating systems: On Linux: /usr/local/avamar/bin On Solaris: /opt/AVMRClnt/bin On Windows: C:\Program Files\avs\bin

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 5 Sybase

22

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 SAP

Avamar 6.1 Technical Differences

SAP is a product developed and marketed by the German company SAP AG. SAP is a German acronym for Systemanalyse und Programmentwicklung," which can be loosely translated into "Systems and Application Products. While SAP can be run with many different database products, nearly 85% of SAP customers now choose Oracle because of its dominance in the database marketplace. SAP is an ERP Software provider, ERP stands for Enterprise Resource Planning. ERP software applications support many different business processes within an organization. SAP NetWeaver is the platform that provides the shared technology foundation for SAP business applications. NetWeaver is the technical basis layer upon which most SAP applications reside. The Basis layer sits between the applications and the operating system with database. SAP basis specialist administrates network architecture, database access, and backups, etc. Database backup can be performed by using database-specific tools and backup management software. For Oracle databases, SAP developed a set of backup and recovery tools called BR*TOOLS. Avamar SAP plug-in for Oracle works with BR*TOOLS to manage backup and restore.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 SAP

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 SAP

Avamar 6.1 Technical Differences

Multi-streaming is a feature whereby a single backup or restore operation uses multiple sessions (data streams). This enables the Plug-in for SAP software to back up or restore more than one SAP Oracle database on the same host concurrently. The multi-stream option enables you to specify the maximum number of parallel backup or restore sessions that can run concurrently. The software always attempts to run backups or restores at maximum multi-stream. For example, if the multi-stream is set higher than the number of files to be backed up or restored, then a full backup or restore operation will concurrently back up or restore all the Oracle databases on the server. Backup: if max-streams=n, Plug-in receives m files (where m is greater than n) to be backed up, backint will divides the m files into n groups, and spawns n avtar processes simultaneously to do the backup. the 243 files is a backup example. When backint receives a list of files to restore, it first sorts them by backup id. Files with the same backup id are then grouped and divided by (max-streams). backint spawns up to max-steams of avtar process simultaneously. For both backup and restore each stream backs up or restores a number of files determined by the division of total number of files and number of sessions set by the user, excepting the last stream that accounts for rounding calculations.
Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 SAP

Avamar 6.1 Technical Differences

Windows: Run the AvamarClusterConfiguration tool - part of the Avamar Client package Unix: For a Sun Cluster configuration, run the suncluster-configure.sh script For a Veritas Cluster Server (VCS) configuration, if the file system client was already configured for a cluster before the SAP plug-in was installed, then reconfigure it by running first the avclusuninstall script and then the avclusinstall script.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 SAP

Avamar 6.1 Technical Differences

CLI bkups are started by a user running brbackup or brarchive command, which starts the backint process (same as for GUI). The backint process requests ad-hoc work order from MCS through avagent (new for CLI) and starts avtar processes. The rest of the workflow is same as for GUI backups. 1. The avagent process on the SAP server performs the following: a. Polls the Management Console Server (MCS), which gives avagent a backup (snapup) workorder. The backup workorder is an XML message with details about the backup to perform. b. Starts the avsap binary and passes the work order to the avsap process. 2. The avsap binary executes the appropriate BR*Tools command, either brbackup for a backup operation or brarchive for an archive operation. 3. The brbackup or brarchive process communicates with the Oracle database to gather information needed for the backup, shuts down or starts up the database instance if needed, and starts the Avamar SAP plug-in backint process. 4. The backint process starts one or more avtar processes, depending on the parallelism (multi-streaming) configuration, and passes a list of database or archived transaction log files to be backed up. 5. Depending on the specified data storage destination, the avtar process writes the backup data to either the Avamar server or Data Domain system. 6. The backint process sends backup progress updates and communicates the success or failure of the backup to MCS. Note: If a backup is performed with the inquire option, Avamar Administrator does not show progress. However the success or failure of inquire operations is communicated to BR*Tools.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 SAP

Avamar 6.1 Technical Differences

Backed-up data must be restored from the command line interface (CLI) on the SAP server with the proper BR*Tools interface, for example brrestore or brrecover. The following figure and process steps describe how the SAP server, Avamar server, and SAP plug-in software processes interact during a SAP Oracle restore: 1. The brrestore or brrecover command, with the parameters for the files to be restored, starts the backint process. 2. The backint process queries the Avamar server for the requested backup files. 3. The backint process starts one or more avtar processes, depending on the parallelism (multi-streaming) setting, which restores the specified files. Note: MCS does not display progress during restore operations. And the backint process communicates the success or failure of the restore to BR*Tools.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 SAP

Avamar 6.1 Technical Differences

Install requirements, key screen shots from demo Next, determine the hosts in your environment that contain the data to be backed up (Avamar clients). Avamar Client software is installed on each client machine and is used for backing up file system data. Are there database applications that will be backed up using the specialized Avamar database client software plug-ins? If so, both the Avamar Client software and the applicable Avamar database client software are installed on the machine.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 SAP

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 SAP

Avamar 6.1 Technical Differences

SAP terminology and concepts : Oracle database backup and recovery through SAP BR*Tools. The Avamar SAP plug-in uses BR*Tools commands. BR*Tools is configured to use Avamar SAP plug-ins backint interface program. BR*Tools commands run backint binary and pass in the type of operation (backup, restore, inquire) and the list of files. The backint binary runs avtar processes to backup or restore passed in list of files. Once backint binary returns successfully, BR*Tools command may run another instance of backint binary in same way as above. BR*Tools may run this way several backint binaries. The avsap binary executes the appropriate BR*Tools command, either brbackup for a backup operation or brarchive for an archive operation.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 SAP

10

Avamar 6.1 Technical Differences

A whole database backup is when all the tablespaces of an Oracle database are backed up. A Partial backup is exactly the same as whole backup except that the user backs up a subset of tablespaces or database files. brbackup with backint uses the Oracle alter tablespace begin backup method to back up the database data. As a result, all backups are always full. Archived log backup backs up the archived transaction logs needed to roll the database forward (i.e., bring it to a specific point in time between backups) during recovery. A user can back up archive logs either as part of whole/partial backup or independently. Offline backups are whole or partial backups that back up the database files having the database shutdown at the beginning of the backup and restarted after the backup is complete. Online backups are whole or partial backups that back up the database files without shutting down or starting up the database. A restore is a process of retrieving the backed up data from a backup server such as Avamar. A recovery is the process of applying the necessary archived logs after a restore operation.
Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 SAP

11

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 SAP

12

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

Avamar 6.1 Technical Differences

The above table lists the SQL Server versions and host operating systems that the Avamar Plug-in for SQL Server supports

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

Avamar 6.1 Technical Differences

Characters used in database names are restricted to valid filename characters. You should particularly avoid any of the following characters, which are known to interfere with proper operation of the Avamar SQL Server plug-in: asterisk (*), forward slash (/), backward slash (\), colon (:), semicolon (;), question mark (?), right angle bracket (>), left angle bracket (<), vertical bar (|), or period (.)

The Avamar Config Checker is located on the Avamar Server itself, as a zip file in the
same Downloads folder as other Windows plug-ins. It supports MS SharePoint, SQL, Exchange and Hyper-V configurations, and provides a detailed report of its findings, with info, warning and fail messages to guide the user towards fulfilling the prerequisites.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

Avamar 6.1 Technical Differences

In the Type column in the bottom right pane, f-0 indicates a full backup, d-n indicates a differential backup, and i-m indicates a transaction log (incremental) backup.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

Avamar 6.1 Technical Differences

To restore a filegroup, expand the node for the instance in the folder tree in the bottom left pane, select the database in the bottom left pane, and then select the checkbox next to the files in the filegroup in the bottom right pane. If there are multiple files in the filegroup, ensure that you select the checkbox next to each file to ensure that you restore the entire filegroup. The name of the filegroup to which a file belongs appears in the Filegroup column of the bottom left pane.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

Avamar 6.1 Technical Differences

To restore a filegroup, expand the node for the instance in the folder tree in the bottom left pane, select the database in the bottom left pane, and then select the checkbox next to the files in the filegroup in the bottom right pane. If there are multiple files in the filegroup; select the checkbox next to each file to ensure that you restore the entire filegroup. The name of the filegroup to which a file belongs appears in the Filegroup column of the bottom left pane.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

Avamar 6.1 Technical Differences

New feature to detect a gap in the SQL log files and promote an incremental backup to full backup. Use Case: Another backup vendors software is installed alongside Avamar and performs a backup that truncates the log chain, creating a gap in the log files. Avamar detects this log gap when an incremental backup is started and automatically promotes the incremental backup to a full backup. Requirements to use this new feature:

At least one Full AvSQL backup must be performed At least one Log backup must be performed Once these requirements have been met, the feature will automatically check for log
gaps on each new incremental backup and promote the incremental backup to a FULL should a log gap exist.

As a best practice, a log backup should be taken after a promotion to a full backup.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

Avamar 6.1 Technical Differences

Multi-streaming enables you to improve backup and restore performance by backing up and restoring SQL Server data using multiple parallel data streams. You can either back up multiple databases in parallel with one stream per database, or back up a single database using multiple parallel streams. If you use multiple data streams to send backup data for a single database to the Avamar server or Data Domain system, then the backup for the database is stored as multiple files. As a result, the number of streams that you use for the backup is also used for the restore. If using multi-stream backup to DD, the number of streams to DD also equals the number of connections needed to the Avamar server Multi-Stream options are configurable only at the backup time. Old Single-Stream Backup/Restore architecture:

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

Avamar 6.1 Technical Differences

Avamar sends the data in multiple streams by spawning multiple instances of avtar. There is one avtar instance for each data stream, plus an additional avtar progress instance. The steam size is used to determine how many streams per database is used. This is configured only at backup time. You can specify a maximum of six streams for each backup. You also can specify the minimum size of a stream, which must be one of the following: One stream per database 256 MB (default) 512 MB 1,024 MB 2,048 MB DB size = 1090mb 1090/256mb =4.26 streams back up this DB with 4 streams generates 4 streams + 1 progress (management) stream Total 5 steams. When multiple databases are included in a backup, Avamar sets the order in which the databases are backed up based on database size, with the largest database backed up first. Avamar calculates the number of streams to use to back up the database, and then allocates those streams for the backup. What is considered a small db? This is something that is being worked out by engineering As a rule for now: (200 Gig)

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

10

Avamar 6.1 Technical Differences

avsql plug-in was modified to support GUI changes for redirect recovery to multiple locations. redirect, plugin and filelist views were introduced. 'Restore Plug-in' needs to select 'Windows SQL' if the selection for 'Restore Database Choices' is 'Restore to the original location' or 'Restore to a different SQL Server instance or location'. The new control group "editable-restore-targets-box" was introduced in the avsql plug-in catalog. app-instance flag was introduced in avsql plug-in which is used to specify the destination instance during redirect recovery. The --redirect flag for CLI:

The flag is used to define the new file location for every file separately. The flag is currently available from command line or by specifying it in Additional
options.

Example flag usage:


--redirect=<physical file name file1>=<new location\new_file_name1>,<physical file name file2>=<new location2\new_file_name2>,

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

11

Avamar 6.1 Technical Differences

Full backups always back up the entire database, including all objects, system tables, and data. As the backup operation progresses, it copies the transaction logs. This ensures that you can recover the complete database to the state it was in when the backup finished. Differential backups back up any data that has changed since the last full backup. As the backup operation progresses, it copies relevant portions of the transaction logs. This ensures that you can recover the database to the state it was in when the backup finished. To restore the database, the Differential Restore restores the last full backup, followed by the differential backups performed after the full backup. Because it only saves changes to data, a differential backup is smaller and faster than a full backup, and can therefore be performed more often. By default, transaction log backups only back up the transaction logs. Transaction logs are serial records of all database modifications. They are used in recovery operations to update the database with complete transactions and roll back incomplete transactions. When you back up a transaction log, the backup stores all changes that have taken place since the last transaction log backup. Transaction log backups record the state of the transaction log at the start of the backup (unlike full and differential backups, which record the state of the data at the end of the backup). When a transaction log backup is complete, the log is truncated to remove any transactions that have been committed to the database. When restoring the database, you restore the data to the state it was in at the end of the last full or differential backup, and then sequentially restore the transaction log backups in order. Full Backup (f-0) Entire DB, all objects, systems tables and data Differential Backup (d-n) Only data that has changed since last backup Only saves changes to data Smaller and faster than full backup Incremental Backup (transaction log) (i-m) Serial records of all database modifications Used in recovery operations

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

12

Avamar 6.1 Technical Differences

Avamar can back up databases that use any of the three recovery models: simple, full, or bulk-logged. However, the recovery model may determine the type of backup that you can perform of the database Performing a backup with the Avamar Plug-in for SQL Server, you can back up either all SQL Server data on a specific server, one or more instances, or one or more databases. Recovery models are used to control transaction log maintenance. Simple - No log backups. Automatically reclaims log space to keep space requirements small, essentially eliminating the need to manage the transaction log space. The simple recovery model minimizes administrative overhead for the transaction log, because the transaction log is not backed up. The simple recovery model risks work-loss exposure if the database is damaged. Data is recoverable only to the most recent backup of the lost data. This includes system databases such as the master, msdb, and model databases.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

13

Avamar 6.1 Technical Differences

Performing an incremental (transaction log) backup, then specify how Avamar handles databases that use the simple recovery model, which does not support transaction log backups, by selecting one of the following options from the For simple recovery model databases list. If you are performing an incremental (transaction log) backup, then you can use the For simple recovery model databases plug-in option to specify how Avamar handles databases that use the simple recovery model, which does not support transaction log backups. Avamar can exclude databases with the simple recovery model from the backup and write either an error or a warning message to the log. Alternatively, Avamar can perform a full backup instead of a transaction log backup

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

14

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

15

Avamar 6.1 Technical Differences

Allows control of the recovery operation that occurs after the restore using restore options in the Avamar Plug-in for SQL Server. The possibility to select recovery operation was introduced (new flag recoveryoperation) :

RECOVERY
At the end of restore the database is fully recovered and online. This is set as the default flag value. (pre 6.1 AvSQL plug-in functionality)

NORECOVERY
After the restore the database remains in restoring state. User is able to apply additional manual restore.

STANDBY
At the end and during recovery the database will be in STANDBY (Read-Only) mode. Additional flag "standbyfilelocation" to specify undo file location was introduced. In this file the recovery changes are saved, this gives to user the possibility to revert the recovery effects.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

16

Avamar 6.1 Technical Differences

You can control the recovery operation that occurs after the restore using restore options in the Avamar Plug-in for SQL Server. The database remains in a restoring state after the restore. This enables you to perform additional manual restore tasks, such as applying additional SQL transaction log files. In NORECOVERY operation roll backs do not occur, the database in unable to accept any connections. Database is off-line

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

17

Avamar 6.1 Technical Differences

The database is in standby (read-only) mode after the restore. This enables you to bring up a database for read-only access between transaction log restores, and can be used with either warm standby server situations or special recovery situations in which it is useful to inspect the database between log restores. This option also creates a file with recovery changes. You can use the file to revert the recovery changes, if necessary.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

18

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

19

Avamar 6.1 Technical Differences

Simplified database naming during restore When you restore SQL Server data from Avamar, the resulting file is named DESTINATION_DIR/INSTANCE/DATABASE/FILENAME, where DESTINATION_DIR is the target directory for the restore, INSTANCE is the name of the original instance for the restored data, DATABASE is the name of the database, and FILENAME is the name of the database files. If the data was backed up using multiple streams, then there will be one restored file for each stream. Formally known as Simplify SQL directed database naming when first developed After selecting Set Destination -> More Options -> Show Advanced Options, select new name, (next slide)

Note in 6.0 it was more difficult, in 6.1 is more human readable Select new destination to get to the new database name

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

20

Avamar 6.1 Technical Differences

The redirected restore options on the Restore Command Line Options dialog box enable you to control the database name and file locations when you are restoring a database to the original instance but with a new name. If you are restoring a single database with a new name, specify the new name in the New Database name box. Redirected Restore settings (Alternate database location, Alternate log location, and Path to alternate log location) Authentication options enable you to choose whether Avamar uses NT authentication or SQL Server authentication to connect to SQL Server when you restore an instance, database, filegroup, or file to either its original location or to a different location. SQL server address box - specify the hostname or IP address of the SQL server to connect to. Authentication method choose whether to use NT authentication or SQL Server authentication. If you select SQL Server authentication, specify the login ID and password for the SQL Server account in the SQL login ID and SQL password boxes, respectively. To specify the file location for the target database in redirected restore, user should use the Set Destination in the section 'Items marked for Restore' from previous page Point-in-Time: Restore to the specific point-in-time or mark name in transaction log.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

21

Avamar 6.1 Technical Differences

It is rare that you need to restore only system databases. However, the restore might be required if one or more system databases are damaged. When you restore multiple system databases, Avamar automatically restores the databases in the correct ordermaster, msdb, and model. Avamar can also automatically manage the stop and restart of the necessary SQL Server services during the restore. Restore system databases and Manage SQL services automatically during restore checkboxes on the Restore Command Line Options dialog box enable you to properly restore system databases, such as the master, msdb, and model databases. When you restore an entire instance, or if you specifically select system databases for restore, then select the Restore system databases checkbox to ensure that the system databases are included in the restore. If you leave the checkbox clear, then the system databases are not restored. The Manage SQL services automatically during restore option automatically stops and restarts SQL services during the restore: When you restore the master database, this option automatically stops the SQL Server instance, including dependent services such as the SQL Server agent service and the Analysis Service, and restarts the instance in single-user mode before the restore. After the restore, the instance is automatically restarted. When you restore the msdb database, this option automatically stops the SQL Server agent service, and then restarts it when the restore is complete. When you select both system and user databases for restore, the system databases are restored first. You must select the Manage SQL services automatically during restore checkbox to ensure that all system databases are restored in the proper order and with the necessary service stops and restarts. Avamar sql will stop and restart the instance in single-user mode for restoring master database. After the master db restore, the instance is automatically restarted. Then MSDB and model db will be restored in order. Master needs to be off-line, checkbox will do that

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

22

Avamar 6.1 Technical Differences

When you use the CLI to initiate a backup or restore, you specify the options for the SQL Server plug-in binary on the command line. The plug-in interacts with the avtar process to write backup data to or read backup data from the Avamar server.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

23

Avamar 6.1 Technical Differences

The avsql binary is located in C:\Program Files\avs\bin, where C:\Program Files\avs is the Avamar client installation directory. To launch the CLI, open a command prompt and change directory to the bin directory of the Avamar client installation directory

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 6 MS SQL Enhancements

24

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 7 Microsoft Exchange VSS Plug-in Enhancements

Avamar 6.1 Technical Differences

The new Exchange VSS Plug-in now has support for, Exchange incremental and federated backups as well as enhancements to management features and CLI support. The Exchange legacy plug-in has been retired.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 7 Microsoft Exchange VSS Plug-in Enhancements

Avamar 6.1 Technical Differences

You now have the ability to mount an existing Recovery Storage Group (RSG) for Exchange 2007 or Recovery Database (RDB) for Exchange 2010 using the Exchange GLR plug-in. You can select to automate the suspension of the database and/or overwrite the existing RSG/RDB before a restore. Fields have been added to specify the database and log folder locations for the RSG or RDB. Multi-streaming enables parallel processing of backup jobs using multiple processors. You can use as many as six streams. Each stream requires a separate processor core. By taking advantage of multi-processors, you can improve backup performance when storing backups on either the Avamar server or on a Data Domain (DD) system. If multi-streaming backups to DD, then only one connection is used to the Avamar server. You can configure multistreaming to group backups by volume or by database.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 7 Microsoft Exchange VSS Plug-in Enhancements

Avamar 6.1 Technical Differences

The Avamar 6.1 Exchange VSS plug-in now has an added drop-down list in the catalog to choose a Full Backup or Incremental Backup. However, only full backups can be used for granular-level recovery. An incremental backup will back up only the transaction logs and truncate the logs when the backup is successful. An incremental backup will be promoted to a full backup if a previous full backup can not be found, if there are any gaps detected in the logs or if circular logging is enabled. You can configure Exchange to save disk space by enabling circular logging. Circular logging allows Exchange to overwrite transaction log files after the data that the log files contain is committed to the database. In Exchange 2010, circular logging is disabled by default. By enabling it, you reduce drive storage space requirements. However, without a complete set of transaction log files, you can't recover any data more recent than the last full backup. In a normal production environment, circular logging isn't recommended. For circular logging-enabled databases you can select one of three (3) backup policies. You can promote the backup, which will promote any incremental backup request that contains a Storage Group DB with circular logging enabled to full. This will backup all the databases and promote all to full. The second option is circular, which will backup only those storage group DBs that have circular logging enabled, promoting them to a full backup. The third option is skip, which will skip backing up those storage group DBs that have circular logging enabled and backup up all other storage group DBs, allowing an incremental backup to be performed.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 7 Microsoft Exchange VSS Plug-in Enhancements

Avamar 6.1 Technical Differences

Prerequisites to preparing the Exchange DAG for federated backup include installing .NET 4.0 and MAPI/CDO. MAPI CDO is only needed on DAG nodes that will be performing GLR and the node running the Avamar backup user configuration too. Install the Avamar File System client and the Exchange VSS plug-in on all DAG servers and run the Avamar Backup User tool to create the AvamarBackupUser with the proper permissions. After registering the clients, you then run the cluster configuration wizard, for which you will need to have a static IP registered in DNS for the Avamar DAG Backup Client . This new feature supports federated browse, backup and restore including GLR. For DAG Federated backups you can set a preferred server order list, which is a list of Exchange servers from which the databases will be backed up. For example: --serverorderlist=<exchserver1>,<exchserver2> DAG Federated restores are performed to a single DAG node.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 7 Microsoft Exchange VSS Plug-in Enhancements

Avamar 6.1 Technical Differences

Some steps have been performed prior to performing a DAG: You would have installed the Avamar File System client and Exchange VSS plug-ins (GLR is optional) on each of the Exchange DAG servers. Run the AvamarBackupUser configuration tool in one of the active Exchange servers. This tool requires the installation of the MAPI CDO kit. Configure Avamar services to run under the backup user account on all DAG nodes. Register the clients 1. Log into one of the active Exchange server as AvamarBackupUser and run the Cluster Configuration tool to install a separate Avamar client resource for the DAG. A node in the DAG is identified as the primary dag node, and it drives the process, performing the discovery of primary and secondary copies, and directing work orders accordingly. This DAG client coordinates a federated backup of the passive databases in the DAG by allowing you to specify which databases to back up, and what order the backup should check the Exchange servers for a passive copy of each database. 2. Configure the backup policy by selecting the Exchange DAG name as the backup client, not the individual exchange servers. 1. Set the different backup options for the backup to passive replica writer. 2. Set the preferred server order list (PSOL) (for example EXCH2, EXCH3, EXCH1 3. Optionally you can set circular logging behavior preference. 3. Avamar sends the backup requests to the DAG Node. The first avagent on the primary node is the one acting as the federated DAG client and the remaining DAG nodes act as regular DAG nodes. The databases are backed up from the servers. DB1 on EXCH3 is skipped since its already been backed up on EXCH2. 4. The passive copy backups are sent to the Avamar server.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 7 Microsoft Exchange VSS Plug-in Enhancements

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 7 Microsoft Exchange VSS Plug-in Enhancements

Avamar 6.1 Technical Differences

1. Configure the backup policy by selecting the Exchange DAG name as the backup client, not the individual exchange servers. 2. Set the different backup options for the backup. For example, active, passive replica writers etc. 3. Set the Server preferred order list (for example EXCH1, EXCH2, EXCH3) 4. Set circular logging behavior preference. 5. Begin the backup

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 7 Microsoft Exchange VSS Plug-in Enhancements

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 7 Microsoft Exchange VSS Plug-in Enhancements

Avamar 6.1 Technical Differences

We are selecting to restore everything to a different location because the backup was initially performed under the DAG client.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 7 Microsoft Exchange VSS Plug-in Enhancements

10

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 7 Microsoft Exchange VSS Plug-in Enhancements

11

Avamar 6.1 Technical Differences

Generally, full disaster recovery of an Exchange server requires the following: 1. Rebuild the Windows server on similar equipment as the original server, to the same Windows version and service pack level. Full operating system backups with the Avamar Client for Microsoft Windows help you to rebuild your Windows Server with full backups of critical volumes and system state. The Avamar for Windows Server Guide provides instructions on performing full system state backups, and performing disaster recovery of the Windows server. 2. Rebuild the Exchange server to the same version and service pack as the original Exchange server. 3. Restore Exchange databases. Restore from Avamar plug-in for Windows Exchange VSS backups.

Find the DAG backup to restore The location for the restore must be the client where the active database currently
resides.

Set the plug-in options for the databases you will be restoring Select Automate replication suspension so that replication to the passive nodes is
suspended while you are performing the restore.

Click OK to initiate the restore.


4. Resume replication

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 7 Microsoft Exchange VSS Plug-in Enhancements

12

Avamar 6.1 Technical Differences

A federated DAG backup provides access to backups of all Exchange databases through one Avamar client, even though they came from multiple Exchange servers in the DAG. This simplifies the restore process in several ways, since you only need to select one Avamar client, the DAG client, in order to select and restore the databases. You do not need to locate, select, and restore backups separately from each server in the cluster. Avamar automatically routes each restored database to the correct node where the active copy currently resides. Because the DAG federated backup only contains one copy of each database, there is no duplication from restoring copies of the same database from different server node backups. To restore the active copies of Exchange databases from a DAG federated backup to their original locations: 1. In Avamar Administrator, click the Backup & Restore launcher button. 2. In the Backup and Restore window, find the DAG backup to restore. Because you are restoring from a DAG federated backup, select the DAG client, not the Exchange server clients. The DAG clients only display the client name where the Exchange servers clients display the FQDN. 3. Select the database to restore. 4. Select Actions > Restore Now. 5. Select restore everything to its original location. 6. From the Encryption method list, select the encryption method to use for client/server data transfer during this restore. 7. Click More Options. 8. In the Restore Command Line Options dialog box, set the plug-in options: 9. Resume Replication a. To resume replication in Exchange Server 2010 using the Exchange Management Shell: i. Resume replication using the Resume-MailboxDatabaseCopy command ii. If replication fails, run the Update-MailboxDatabaseCopy command.
Copyright 2012 EMC Corporation. All Rights Reserved.

Module 7 Microsoft Exchange VSS Plug-in Enhancements

13

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 7 Microsoft Exchange VSS Plug-in Enhancements

14

Avamar 6.1 Technical Differences

Uses CLI Framework developed for plug-ins Support has been added for backups, browsing and recoveries. Examples:
Browse: avexvss --operation=browse <--format={xml|list}> <--backuptype={active|passive|all}> Exchange Information Store Backup: avexvss --operation=backup --server=server_name -id=root --ap=password --acnt=/clients/client.domain <--backuptype={active|passive|all}> <--brtype={level0_full|incremental}> {Exchange target} GLR does not support CLI

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 7 Microsoft Exchange VSS Plug-in Enhancements

15

Avamar 6.1 Technical Differences

Add Best practices: use multi stream for large databases ~20-30 TB Use Fulls and Incremental, use multi-streaming. To scale out large databases

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 7 Microsoft Exchange VSS Plug-in Enhancements

16

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 7 Microsoft Exchange VSS Plug-in Enhancements

17

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

Avamar 6.1 Technical Differences

All references to Celerra have been rebranded to Celerra/VNX. In Avamar 6.1 DART or VNX/VNXe file names, versions, and statistics are accurately reported. During a multiple volume backup, the largest volumes will be given priority and be backed up first. The maximum available NDMP streams will now be dynamically determined and adjusted to the maximum available. Avndmp gracefully accomodates the limit if NetApp or Celerra reject the NDMP session due to the stream limit. The maximim NetApp streams allowed has also been increased from four (4) to eight (8). In this release there is automatic merging of pre-Avamar 6.0 accounts into a single account, by detecting and handling multi-volume backups that were stored to different Avamar accounts. Users can take advantage of v6.x multi-streaming without requiring new Level-0 Full backups. Enhanced storage layout for Celerra/VNX backups. This enhancement greatly reduces small chunks on the GSAN to improve HFSCHECK performance and recovery performance. It also allows the 7.8TB nodes to be used effectively. Error handling has been improved. Warning and error messages have been refined. The system can recognize and handle more failure conditions faster and detect common failure cases and recommend remedies.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

Avamar 6.1 Technical Differences

The volume names are sorted alphabetically in the Avamar Administrator GUI for both backup and restore operations. The top level of the restore will be alphabetized for multivolume backups (the volumes are sorted). Pre-Greenville backups will not be sorted.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

Avamar 6.1 Technical Differences

The Avamar Administrator now allows Celerra/VNX backups to be restored directly to a Windows or Linux file system client. There following are exceptions of files that can not be recovered to these clients. ACLs and Extended Metadata, Special files, pipes, device files, Windows Alternate Datastreams or Hardlinks are not recoverable. An error message is reported for every file not fully recovered

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

Avamar 6.1 Technical Differences

Logs Backup Oracle plug-in provides archive log files backup ONLY feature Introduced a special flag Backup Archive Logs in Avamar Administrator console to
select backup of Log files only.

Periodically user can take archive logs backup only by selecting Backup Archive Logs
option instead of backing of the entire database

Prerequisite: Log backup requires at least one full backup before scheduling log
backup.

This feature saves backup time for large datasets ( full backup/incremental) and user
can schedule frequently based on the requirement.

No changes in restore functionalities.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

Avamar 6.1 Technical Differences

In this release a special flag Corrupt Block Only is introduced in the Restore dialogue box of the Avamar administrator console. This feature provides the capability to detect and recover block corruption from Avamar GUI. The Oracle data corruption could be due to media/physical or logical corruption. RMAN computes and maintains block level checksum for all backups. Avoracle internally validates and recovers the corrupted blocks from backups through RMAN.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

Avamar 6.1 Technical Differences

Introduced in Avamar 6.1 is the Flashback Database (FRA) flag. This feature provides capability to flashback databases to past states or to return database objects to a previous state without using point-in-time (PIT) media recovery. Flashback database recovery is done by selecting the supported recovery mode value. The flashback options are:

Current Time (PIT only) To SCN (FRA Only) (System Change Numbers) To Log Sequence To TimeStamp Restore Point Before SCN (FRA Only) Before Log Sequence (FRA Only) Before ResetLogs (FRA Only) Before TimeStamp (FRA Only)

Using this feature requires that Flashback Mode be enabled for Oracle Database. The Oracle database also needs to be in a mount state. Avoracle internally uses flashback logs and archive logs to complete the flashback recovery through RMAN, archive logs may be used if the selected recovery mode value falls between flashback logs. NOTE: RMAN does not support backup of Flashback logs.
Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

10

Avamar 6.1 Technical Differences

In this release support has been added Oracle RAC on Windows platforms. The new AvamarRACConfiguration.exe utility is used to configure the Avamar Oracle plug-in on Oracle RAC environments for Windows platforms, check the existing configuration, re-register the client with a different Avamar Server and to reset or Remove the existing configuration. It will be shipped with the Avamar RMAN windows package. There are no changes in the Avamar Oracle plug-in installation procedure, the Avamar RMAN package still needs to be installed on all the required cluster nodes. The Avamar Oracle plugin for Oracle RAC is configured from one of Oracle RAC nodes by using this utility.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

11

Avamar 6.1 Technical Differences

This is the dialogue box for the Avamar Oracle RAC configuration on Windows. The Avamar RAC configuration utility scans and displays all existing RAC nodes, the Oracle RAC name, the default var folder (user configurable), the MCS port , which defaults to 28001, and the backup domain, also user configurable. The Oracle RAC Name: Oracle RAC SCAN Name/VIP is used to configure the Oracle plug-in. The var folder is a separate var folder used to configure the Oracle plug-in on the RAC environment. Enabled the Shared check box if the var folder is a shared folder among all Oracle RAC nodes. If the var folder is not shared, then there might be a hit in backup performance when a failover occurs. This is because avtar

from the new node will need to contact the server to determine the unique chunks.

The Cluster Configured Nodes section displays the list of all configured Oracle RAC nodes. Available Nodes is a multi-selection box which contains list of available Oracle RAC nodes. Under the Registration section, enter the information to register the Oracle RAC node(s) with the Avamar server. Configure the RAC nodes by clicking the configure button for all the selected nodes. As part of configuration the plug-in creates a Windows service called Backup Agent for Oracle RAC (Avagent /backup agent) on all configured RAC nodes. The EMCagent is created as an Oracle cluster resource, which controls (start/stop/check/clean ) tasks and the Backup Agent for Oracle RAC service. The Oracle RAC node(s) are registered to the Avamar server using SCAN/VIP name. Upon successful completion a Configuration successful message is displayed. After successful configuration start the EMCagent, cluster resource, from any desired node. The EMCagent start command is different for Oracle 11gR1 and 11gR2. Oracle 11gR1 > crs_start EMCagent -c <hostname> Oracle 11gR2 > crsctl start resource EMCagent n <hostname> All backup and restore of Oracle RAC databases will be performed on single RAC node. In the event of a failure the EMCagent cluster resource starts automatically on any available RAC node. Any current backup or restore operation should be re-initiated. Host level Disaster Recovery is an existing feature of the Avamar Oracle plug-in. The DR procedure is available in the Avamar Oracle plug-in guide. Note that you should restore the SPFILE from the backup piece using RMAN CLI before the actual restore operation.
Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

12

Avamar 6.1 Technical Differences

Follow these steps to add a new node to an Active/Active Oracle cluster RAC on Windows. 1. Stop the EMCagent cluster resource if it is running

Oracle 11gR1 > crs_stop EMCagent Oracle 11gR2 > crsctl stop resource

EMCagent

2. 3. 4. 5.

If the var folder is NOT shared, de-activate Oracle RAC name from Avamar Administrator/Policy Manager Select the available nodes Click configure to add new nodes to the Oracle plug-in configuration on the RAC Start the EMCagent using the cluster command on any node

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

13

Avamar 6.1 Technical Differences

Follow these steps to re-register an active/active cluster RAC on windows with another Avamar server: 1. Stop the EMCagent cluster resource if it is running 2. Click Change Avamar Server Registration checkbox 3. Fill in the Avamar server registration information 4. Click the Register button 5. Start the EMCagent cluster resource on any available node This will register all existing configured RAC nodes with the new Avamar Server.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

14

Avamar 6.1 Technical Differences

Follow these steps to remove the Oracle RAC plug-in from the nodes. 1. Launch the Cluster Configuration Setup 2. Reset Removes the Oracle plug-in configuration from all Oracle RAC nodes. This operation should be done on any one of the configured RAC nodes. Perform reset before Oracle plug-in de-installation from Oracle RAC nodes. 3. De-install the Oracle plug-in from all nodes. NOTE: Selective node removal is not supported.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

15

Avamar 6.1 Technical Differences

New Features for DB2 Plug-in

DB2 Granular Level Recovery DB2 Datadomain Backup Support DB2 Active-active Cluster (DPF) DB2 Command line Support (CLI) DB2 Disaster Recovery

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

16

Avamar 6.1 Technical Differences

This feature provides the ability to perform a granular level browse and select one or
more tablespaces to restore from full database backups. A hidden internal file is used to store the tablespace information during the backup. This file is restored during granular level browse and contents of this file are displayed on the GUI. The GLR icon (yellow button), as shown in this figure, is introduced to enable granular level browse. Automatic recovery to end of logs, point-in-time and end of backup are provided as appropriate. The Browse Image Restore icon, (blue button), reverts the operation to the usual restore GUI browse.

DB2 does not permit tablespaces to be restored to another database DPF-GLR is not supported for end of backup, end of logs or Point in time.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

17

Avamar 6.1 Technical Differences

A new check box has been added to the DB2 plug-in catalog, which allows DB2 backups to be stored on a Data Domain system. Enable the check box in order to select the Data Domain server configured to the Avamar grid. Multiple streams to and from a Data Domain system are not supported for DB2.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

18

Avamar 6.1 Technical Differences

Shown here is a single partition configuration on a Symmetric multiprocessor (SMP) machine. A multi-partition configuration, is comprised of multiple partitions of the same database on a cluster of SMP machines. A machine can also host multiple partitions. The DPF (database partitioning feature) is a complex, distributed configuration where DB2 database can be distributed in several parts called database partitions. Each of the partitions can be configured on separate physical machines or more than one partition can be configured on a single SMP machine, as shown in this illustration. The partition where the CREATE DATABASE command was executed is called the catalog node, other partitions are called non-catalog nodes. In order to take a multi-partition database backup, the backup is required to be invoked on the catalog node. DB2 internally forwards the backup request to DB2 partition servers running on the other DPF cluster nodes and initiates the backup simultaneously on all database partitions.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

19

Avamar 6.1 Technical Differences

The DB2 plug-in uses Inter Agent Communications (IAC) mechanism to perform
backups in a DPF setup. The DB2 plug-in on a cluster node that received the work order is called the catalog node and the DB2 plug-ins on the other DPF cluster nodes are called non-catalog nodes.

In the backup command line options dialogue box, specify to backup all nodes or
enter a comma separated list of partition numbers to backup.

The catalog node sends sub-work order to the non-catalog nodes and these spawn
avtar processes and reply to the catalog node with an update_fc_status message. The catalog node issues the DB2 backup.

The DB2 partition servers on all cluster nodes load the vendor library and initiate the
backup simultaneously on all cluster nodes. The Vendor library on various cluster nodes connect to the avtar which is already spawned by the non-catalog nodes. The DB2 partition servers give the backup data corresponding to the database partition to the vendor library which in turn gives the data to avtar. The catalog node creates the snapview.

The same account credentials on the Avamar server of the catalog node are used on
the non-catalog nodes.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

20

Avamar 6.1 Technical Differences

Backups from non-catalog partitions, on various DPF cluster nodes are listed under
the host having the catalog database partition, the catalog node, on the Avamar server.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

21

Avamar 6.1 Technical Differences

In a DB2 DPF environment, a restore operation is to be invoked on each of the


partitions independently.

Note that DB2 does not provide a single system view restore option. Partition backups belonging to the host having the catalog partition can be restored
using the option restore everything to its original location.

Partition backups belonging to hosts having non-catalog nodes can be restored using
the option restore everything to a different location.

In a DB2 DPF setup, the rollforward operation needs to be invoked only on the
catalog node. Where as restore operation has to be invoked on individual nodes. The rollforward operation can not be invoked on non-catalog partitions. Manual rollforward is required for DPF backups after a restore.

Backups and restores using the CLI framework are also supported for DPF backups.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

22

Avamar 6.1 Technical Differences

In a disaster if the DB2 application becomes corrupt at the application level, the host, along with Avamar components installed, remain intact. Therefore you should only need to perform the following three tasks. 1. Reinstall the DB2 application of same version 2. Recreate the DB2 instance (in case of UNIX) or DB2 Copy (in case of Windows) 3. Restore You can follow the Avamar DB2 plug-ins existing procedure to restore a DB2 database to its original location In the event of a system level disaster you will have to re-construct the system and DB2 environments. These are the high-level steps you should perform in order to recover. 1. Install the operating system of the same version and release 2. Assign the same IP address and hostname 3. Install the DB2 application of the same version 4. Recreate the DB2 instance with the same name 5. Install the Avamar File System Client and Avamar DB2 Client of the same version Perform Step 6 or 7 as appropriate 6. UNIX clients can re-register the client/host to the Avamar server to which it was registered before the disaster 7. Windows clients have to be retired first in Avamar Administrator and then re-register the client 8. Follow the procedure to restore into a retired client

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

23

Avamar 6.1 Technical Differences

In this release support has been added to perform a browse, backup, Recovery and GLR for the DB2 plug-in. It uses the CLI Framework developed for plug-ins. The CLI backup or restore operations do not display progress information in the activity windows. Some Examples are listed here: Browse:
#./avdb2 --sysdir=/usr/local/avamar/etc --operation=browse db2inst1

Backup:
#./avdb2 --sysdir=/usr/local/avamar/etc --operation=backup -id=db2admin@/DB2RHEL/aiq-rhel5-64-db2-97 --password=P3t3rPan -server=aiqferrari.bgl.avamar.emc --acnt=/DB2RHEL/aiq-rhel5-64-db2-97 -db2_inst_user=db2inst1 --inst_admin_password=P3t3rPan db2inst1/AVAMAR1

Restore:
#./avdb2 --sysdir=/usr/local/avamar/etc --operation=restore -id=db2admin@/DB2RHEL/aiq-rhel5-64-db2-97 --password=P3t3rPan -server=aiqferrari.bgl.avamar.emc --acnt=/DB2RHEL/aiq-rhel5-64-db2-97 -db2_inst_user=db2inst1 --inst_admin_password=P3t3rPan --restore-only -labelnum=12 For more information refer to the EMC Avamar 6.1 for IBM DB2 User Guide.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

24

Avamar 6.1 Technical Differences

Lotus Domino has i18N support for backups and recoveries. This feature supports different locales. A user can have Lotus Domino in different locales like Chinese, Japanese, Korean, etc. Users can have Lotus database filenames, normal filenames, directory links, databases links, DAOS paths and transaction log path names in Avamar supported Unicode characters. Users can recover all backed up data from the Avamar server by using the Avamar standard date format through GUI. Internally the Avamar Lotus plug-in converts the entered timestamp as per the locale standard and restores the data. CLI support has been added to support backup and recoveries. As shown in this picture, the Lotus CLI help option displays all supported backup and restore flags. Lotus does not support the CLI browse functionality. An administrator can use OS commands for browse. The CLI backup/restore operation does not display progress information in the activity window. CLI Support examples: Backup:
#avlotus.exe --operation=backup -- id=client@/clients/bala2k3win145.bglavamar.emc --ap=client --acnt=/clients/bala2k3win145.bgl-avamar.emc C:\Domino\data debug

Restore:
#avlotus.exe --operation=restore --id=client@/clients/bala2k3win145.bglavamar.emc --ap=client --acnt=/clients/bala2k3win145.bgl-avamar.emc -recover-backuptime --overwrite-files --quick-sync-daos debug For more information refer to the EMC Avamar 6.1 for Lotus Domino User Guide.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

25

Avamar 6.1 Technical Differences

There is new Solaris Cluster support for Avamar file system (FS) client on Solaris 10 ( SPARC & x86). A Sun Cluster configuration script suncluster-configure.sh, will be shipped along with the Avamar Solaris client packages. This script resides in the bin folder of the Avamar Client installation path. This script can be used to configure Avamar Solaris Cluster. Single-node and multi-node Sun cluster configurations are supported. UFS, VxFS, and ZFS shared storage and file systems are supported. High availability In the event of a server failure, the Avamar service avagent will be started automatically by the Solaris Cluster on the failover node. The backup and restore operation have to be reinitiated after the failover.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

26

Avamar 6.1 Technical Differences

Configuration should start from passive nodes first. In order to configure the Solaris cluster you will need the Logical Host name, Virtual IP, Shared Disk, and Resource Group for the cluster. Avamar Solaris Cluster configuration can be started by executing the sunclusterconfigure.sh script, which lists all of the configuration options.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

27

Avamar 6.1 Technical Differences

Selecting option one (1) lists all the available pre-configured resource groups which are configured with Logical Hostnames. Upon selection of the resource group the install script does a set of the following tasks. Creates a folder called avcluster under the Avamar client installation path. The folder is created with the preselected resource group name. All Avamar binaries are placed in this folder. Example: /opt/AVMRclnt/avcluster/<rs-group-name>/

The Avamar agent resource is registered with the appropriate property values like critical or non critical resource type with the Solaris Cluster service. A Critical resource type: Resource Group will failover on failure of the Avamar agent resource. A Non-Critical resource type: Resource Group will not failover on failure of the Avamar agent resource.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

28

Avamar 6.1 Technical Differences

On successful configuration on the active node, the script prompts you for registration or reregistration of the client with the Avamar server. Enter the DNS name of the Avamar server. The above configuration procedure can be repeated for multiple Solaris Cluster resource group configurations. After successfully configuring the cluster resource, start the Avamar Agent service on any desired node by typing the command:
clrg online n <desired-node> <resource-group-name

Please NOTE: You should not use the existing Avamar client registration procedure.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

29

Avamar 6.1 Technical Differences

By default, the Avamar agent resource will be added as a non-critical resource. You can modify the Avamar agent resource properties dynamically so that failure of the Avamar resource agent can be treated based on the requirements. The resource options are: 1. Failover the resource group on Avamar resource exception. Cluster Commands:
clrs clrs disable AVMRAppRes-<resource group name> enable AVMRAppRes-<resource group name> clrs set -p Failover_enabled=true AVMRAppRes-<resource group name>

2.

Failover the resource group after specific number retrials . Cluster Commands:
clrs disable AVMRAppRes-<resource group name> clrs set -p Failover_enabled=true -p Retry_count=# AVMRAppRes-<resource group name> clrs enable AVMRAppRes-<resource group name>

3. No failover on Avamar resource exception. Cluster Commands:


clrs disable AVMRAppRes-<resource group name> clrs set -p Failover_enabled=false -p Retry_count=# <resource group name> clrs disable AVMRAppRes-<resource group name> AVMRAppRes-

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

30

Avamar 6.1 Technical Differences

To remove the Avamar Agent Resource from a Sun Solaris cluster resource group, run the suncluster-configure.sh script and select option two (2). All the pre-configured resource groups for Avamar will be listed. You can remove the agent by selecting the resource group and typing y when prompting to confirm. This will un-register the Avamar client from the selected resource group with the Avamar server, delete the Avamar binaries from the /opt/AVMRclnt/avcluster/<rs-group-name> folder for the selected resource group, and removes the Avamar agent resource for the selected resource group.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

31

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 8 Other Client Enhancements

32

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

Avamar 6.1 Technical Differences

Node add/replace from the UI Improved encryption including client-server encryption using FIPS 140-2 validated
encryption and key rotation for encryption of data at rest

Improved management including LDAP/AD group authentication, unifying the DTLT


and Management Console LDAP configuration, with the exception of configuring single user and global mapping.

Enhanced supportability including hardware fault detection in Avamar GEN4 switches


and clear/concise descriptions for new error/event codes

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

Avamar 6.1 Technical Differences

A new maintenance workflow has been implemented to add storage nodes to a server. It is found in the maintenance tab in the avinstaller GUI. This workflow automates the entire process of adding new nodes, presuming only that the hardware has been physically added to the configuration. There is an Avamar server change that now, if needed, automatically performs balancing during the maintenance window. Automatic balancing is only done during the maintenance window. There is an option included in the Add Node workflow which can be set to enable balancing at the end of the workflow. If this option is not selected, then balancing will not take place until the next maintenance cycle. When specifying load balancing, the balancemin values of 10 or 15 are recommended. At this time this is a restricted workflow and should not be performed by the customer.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

Avamar 6.1 Technical Differences

These are the steps for adding a node to an existing Avamar grid. It is assumed that the node has been racked and plugged into the network to perform these steps. During the avamar installater progress, there are a series of checks and tasks performed approximately midway through the progress, instructions appear indicating how to add a physical node to a grid. Up to this point all checks and tasks that have been performed have been on the grid before node addition in order to verify it is in a good state first. After the user continues, the workflow will proceed to configure and start the new nodes. For more detailed information, refer to the Avamar Product Guide.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

Avamar 6.1 Technical Differences

A new maintenance workflow has been implemented to replace a storage node. After it is uploaded to the utility node, it will be found in the maintenance tab of the avinstaller GUI. This workflow automates the entire process of replacing a storage node, presuming only that the hardware has been physically added to the configuration. By clicking on the question mark icons that appear after each workflow name, you will bring up the online help for that particular workflow. The online help will define all the options that are available for input for that particular module. Refer to the product guide for more information. At this time this workflow is restricted and should not be performed by a customer.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

Avamar 6.1 Technical Differences

The Node Setting tab contains two (2) inputs: Offline Node and Replacement Node. These two fields may auto fill depending on the state of the replacement node. Offline Node. Confirm the physical node number of the defective node. The state of the defective node should be Offline, and it should be the only node that is Offline. If so, the workflow autofills this field with the physical node number of the defective node (for instance, 0.2). 0.spare.# Where # is a number such as 0, 1 This selection appears in the list if the Avamar server has a node available for putting into operation that is identified by the Avamar system as a spare. This selection appears for both Gen2/3 and Gen4 node replacement. A node MAC address This selection appears in the list if you already replaced the physical hardware in the rack and connected it to the ADS network before running this workflow. Such a node has not been given a node type yet, and therefore appears by MAC address. This selection appears for only Gen4 node replacement. You can determine the MAC address of the replacement node by establishing a PuTTY session with it and typing ifconfig. Its MAC address is the 12 hexadecimal characters after HWaddr in the eth0 (for Gen2/3) or eth1 section (for Gen4) of the displayed information. New node This selection appears in the list if you have not yet installed/powered on/configured the replacement node in the rack. Selecting this option causes a hardware installation guide to appear later. After entering the values, click Continue, the installation process will begin, which will include the Storage Node replacement instructions. Proceed through the installation. More information is available in the product guide.
Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

Avamar 6.1 Technical Differences

The switch configuration has been added to the avinstaller workflow in the switch config tab. This is used for Gen4 multi-node grids. This tab is also shown in the upgrade installer UI.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

10

Avamar 6.1 Technical Differences

Shown here are new fields added to the Avamar Installer workflow Server Settings tab.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

11

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

12

Avamar 6.1 Technical Differences

FIPS 140-2, Federal Information Processing Standard (FIPS) Publication 140-2, is a U.S. government computer security standard used to accredit cryptographic modules. The title is Security Requirements for Cryptographic Modules. The standard defines the security requirements that must be satisfied by a cryptographic module used in a security system protecting Sensitive But Unclassified (SBU) information within IT systems. Federal agencies, Defense Information Systems Agency (DISA) and National Institute of Standards and Technology (NIST), have defined two types of product categories with regards to FIPS certification requirements. The categories are divided into Information Assurance (IA) products such as firewalls, IDSs, Proxy Servers, Virus Scanning, etc, and Non-IA products such as storage and software (i.e. Deduplication and other types of technology). DISA/NIST classifies the EMC Data Domain and EMC Avamar appliance as storage devices and Avamar software solution as software, which aligns under the non-IA device category. Therefore, FIPS-140 compliance (component level certification) rather than FIPS-140 certification (product level certification) is acceptable for BRS products. Leveraging component level certification means BRS has achieved a Level-1 certification that conforms to DISA and NIST FIPS certification requirements for the product category. The EMC Avamar Operating System 6.1 and later release utilize Open Source Software Institutes OpenSSL for client/server communications features Data-at-Rest Encryption, and In-flight Encryption running on nonWindows platforms (SLES, RHEL, Solaris x86, Debian, CentOS, Oracle Linux, HP-UX PA-RISC), FIPS 140-2 certification number 1051. For the In-flight Encryption feature running on Windows platforms, EMC Avamar Operating System 6.1 and later releases utilize Microsofts FIPS 140-2 certification number 238. FIPS 140-2 validated encryption is less efficient than non-validated encryption, so this may need to be considered during deployment. With this change, Stunnel is no longer used for encryption on the server side. This encryption will be automatically used whenever network encryption is enabled. There is a slight maximum performance hit (~8%) when high encryption is used (default), which typically will not be noticed since this only impacts data transmitted over the network. There is no encryption from clients to a Data Domain system and vice-versa. The Avamar server itself is a client and customer servers that are backed up are clients. Encryption of Data at Rest is available as a configuration option for a Data Domain system. Refer to the Data Domain OS (DDOS) Administration Guide for more information. Clients NOT FIPS 140-2 compliant are HP-UX 11 PA-RISC, AIX, Mac OS X, Novell Netware, SCO, Iomega, IBM zLinux Refer to the Avamar Security Guide for more information on this feature.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

13

Avamar 6.1 Technical Differences

Administrators may periodically change the key used for encryption of stripes. Key changes take effect with backups performed after the key is changed. Existing data will be re-encrypted if data needs to be re-organized during the stripe crunching process that is part of daily maintenance operations. This means that data which is not overwritten is encrypted by previously specified keys. In 6.1, the gsan will now maintain an index of 'salts' stored in the persistent store. Salts are encryption keys, in this case an at-rest encryption key. Each stripe will also keep a reference for what indexed salt it is using. In 6.0->6.1 upgrades, the first salt will be index 0, blowfish encryption. Subsequently added salts will use the new AES encryption. The index is only for reading stripes and decryption purposes, on crunched re-encryption, it will always use the latest indexed salt, the most recent. Use the new avmaint atrestencryption command to update keys. For example: avmaint atrestencryption --restsalt=asd%aTx75Y !b restpassword=password Note that the quotes are not part of the new key. You may want to add the --restpassword flag as this is what encrypts the persistent store section that stores/indexes the salts. It is not a required entry, but it lets you choose what to encrypt the persistent store with, otherwise the GSAN will choose a random password that may never be known. An added benefit is that the key rotation will allow previous unencrypted systems to become (at least partially) encrypted at rest. This is because of natural crunching, however it will be difficult to get 100% of the stripes encrypted from an unencrypted state.. Both the at rest password and rest salt can be specified at the time of installation in the avinstaller as these fields have been added to the server settings tab.

Once you rotate a key, the grid will start incurring a performance penalty. Right now the marketed penalty is approximately 40-50%, which means the grids need to be doubled in size if enabled. So unless there is a need to rotate keys, the Avamar administrator, should not rotate keys.
Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

14

Avamar 6.1 Technical Differences

Granular backup scheduling - provide the ability to schedule backups at minute level granularity versus the hour granularity in previous releases. The daily schedule can be set to 5 minute granularity. The feature is designed to prevent scheduling multiple times per hour, but allows a schedule to start at a more granular boundary than an hour. Multiple schedules within the same hour are not supported. If another selection is made within the same hour, the user will be given the option to replace the existing entry within the hour, or cancel the add. The weekly and monthly schedules can be set to start and end at minute granularity. Support for this feature has been added to both the Avamar Administrator UI and MCCLI. In the MCCLI the --hours option has been superseded by the new --time option but will still work for backward compatibility. Here is an example of the MCCLI Schedule Add Command:
mccli schedule add [GLOBAL-OPTIONS] {--days=STRING | --time=STRING | --nth-day=STRING | --week=STRING} [--desc=STRING] [--domain=STRING(/)] [--duration=STRING] -name=STRING [--start=STRING] [--tz=STRING] [DISPLAY-OPTIONS]

MCCLI Schedule Edit Command example:


mccli schedule edit [GLOBAL-OPTIONS] {--days=STRING | --time=STRING} [--desc=STRING] [--domain=STRING(/)] [--duration=STRING] -name=STRING [--start=STRING] [--tz=STRING] [DISPLAY-OPTIONS] Refer to the Avamar Administration guide for more information.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

15

Avamar 6.1 Technical Differences

The server now provides an additional safeguard for client data by allowing an administrator to not automatically delete the most recent backup for all clients, even if it expires. This feature is especially useful for DT/LT clients, where a relatively short retention periods may be set to manage cost. If retention is only 14 days, a user on a long vacation or on a leave of absence is at risk of having all backups expire and deleted from the grid. If a backup is being prevented from deletion by this feature and a new backup is taken, the older backup will be allowed to expire. The Never Delete Last Backup option is defaulted to false, to enable this feature the administrator has to change this entry in the mcserver.xml from false to true: <entry key="keep_last_backup" value="false" /> and restart mcs.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

16

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

17

Avamar 6.1 Technical Differences

Major Avamar / Data Domain enhancements include

Support for all major database applications Significant performance improvements with multi-streaming Better stability and tighter integration
Avamar v6.1 uses DDBOOST SDK 2.4.0.2, which is compatible with DDOS 5.0 and 5.1. DDOS 4.9 is no longer supported. The Avamar 6.1 Upgrade Workflow will not allow an upgrade to take place until all attached Data Domain systems are at a supported DDOS level. Similarly, for new deployments, Avamar 6.1 will refuse to attach a Data Domain system if it is not at a supported DDOS level.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

18

Avamar 6.1 Technical Differences

Because files are stored individually on the DDR, it is best practice to set some constraints on the file size and files per backup. It is best practice to keep the backup limit to 1000 files per backup and to avoide storing small files on the DDR when possible. This will help to keep the total file count on the DDR under control. This limit can be overridden by modifying the --ddr-max-files=<filecount> flag. It is not recommended to exceed 3000 files. This limit also applies to snapviews. For example two (2) backups each with 600 files cannot be snapped. Files less than 100 MB in size are considered to be small files. DDR does not scale well with files less than 100 MB in size. This helps to limit the total number of files in the storage unit, since storing too many files on the DDR has an impact on performance. Hfscheck takes longer since each file incurs RPC calls from the Avamar server to the DDR. Checkpoint creation and rollback fail when managing too many files, approximately 100,000 files in 6.0 and approximately 500,000 files in this release due to DDBOOST timeouts. Avamar Garbage Collection takes longer, since the process must delete expired files from DDR recursively using numerous RPC calls. Native DDR Garbage Collection takes longer as well, since it runs once a week, Avamars dynamically expired backups, checkpoint creation/deletions and rollbacks incur significant overhead when managing many files Use Case: For most cases, the type of plug-ins supported (Database and VMWare) will not generally contain many files directed to the DDR server and if there are numerous files they are directed to the Avamar server. Most databases contain a handful of "large" DB files. An exception is the SQL database where users can create thousands of databases under one instance which is something to keep in mind for deployment. This may be the rare case where it may be appropriate to increase the limit to up to 3,000 using the --ddr-max-files flag. However, do not exceed the 3,000 limit much if at all or strange failures may occur. A general case where the 500,000 file limit can be breached is 5 clients with 100 unexpired backups where each backup has 1,000 files. Or 50 clients with 100 unexpired backups where each backup has 100 files, and so on. This is something to keep in mind for deployment. The operational failures and performance impacts are due to the DDBOOST and DDOS architectures.
Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

19

Avamar 6.1 Technical Differences

SQL Server (legacy) plug-in Tail log is always backed up to Avamar while large database files and large log files are backed up to DDR Exchange VSS* plug-in Backup of Exchange log files are always backed up to Avamar. Large EDB files are backed up to DDR, expecting a low DB count, typically 10 SharePoint VSS* plug-in Remote Blob Storage (RBS) mode backup to a Data Domain system is not supported since it generates too many files Backup of small files go to Avamar. These are usually files associated with SharePoint Search and Index. Hyper-V VSS* plug-in Backup of *.avhd files (snapshots) and configuration files is supported Oracle (Windows/Linux/Solaris/HP-UX/AIX) plug-in Backup of RMAN data streams piped through STDIN is supported. There are concerns with incremental backups and snapviews if snapping backups aggregating more than 1,000 files. VMware image backups There are generally about 12 files per VM backup for the first volume. For additional volumes add three (3) files (vmdk + 2 metadata files). SAP Oracle plus many log files are supported Sybase Assuming large database files and log files both are supported DB/2 Stream based backups, database plus log files, are supported. DB/2 backups are single stream backups when backups. * VSS backups are file system backups and must stay under the approximate 1000 file limit
Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

20

Avamar 6.1 Technical Differences

Avamar 6.1 monitors the internal Gen4 switches and detects and reports failures. It will send notifications via Connect EMC in case of major failures. Internal Gen4 switches in multi-node grids are being monitored every 30 minutes using various show commands executed in the switch console. A switch monitoring script parses the output of these show commands and detects failures. Depending on the severity of the detected failures the script may execute the mccli event publish with the corresponding event code. Malfunctions of the monitoring system itself are reported as Switch Scanner Error. In case of major failures, events that are severe enough are reported to Connect EMC.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

21

Avamar 6.1 Technical Differences

Here is a list of error codes and messages.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

22

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

23

Avamar 6.1 Technical Differences

In Avamar 6.1 certain hardware monitoring events have unique GSAN codes. These codes correspond to Management Console (MC) event codes. MC event codes that are reporting home, create support requests. The serverlogscanners.xml file filters for events that get reported and can be updated by support or engineering to add new error codes if appropriate.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

24

Avamar 6.1 Technical Differences

Listed here are the GSAN codes and their corresponding Dell event IDs. These events were previously listed as event 1, which get filtered out, but now that they are specific events, tickets are reported for them.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

25

Avamar 6.1 Technical Differences

Multi-streaming

Improved performance during backup and restore for multiple simultaneous streams Must configure appropriately depending the server load and on the number of server
processors available

Particularly noticeable for database backups & recoveries through Avamar plug-ins Increased client-server connection limit to 27per node by changing the
max_concurrent_jobs parameter in mcserver.xml from 20 to 30. A 16 node server should support 432 (27x16) connections. The total number of concurrent connections per grid has also been increased so that a 16 node grid can use all available connections. Server restart has been enhanced to reduce time to restart. Improvement is dependent on customer data so no exact figure can be provided.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

26

Avamar 6.1 Technical Differences

Multi-Target restores Avtar and many plug-ins now support the ability to select multiple files and directories from a backup and restore them to different locations. This feature allows a single restore operation to restore different portions of a backup to different places on the same client. It is very useful for restoring database files to one volume and log files to a different volume. The new Restore everything to multiple locations option, allows the user to select a different destination for each source file or directory. For directories, the contents of the directory will be restored into the specified path (think "save as" functionality). For example, the contents of "/data04/example/dir10/" will be restored into "/data01/restore/dir10/" For files, the new path must contain a new filename for the target file, for example, "file44" will be renamed to "/was-file44"

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

27

Avamar 6.1 Technical Differences

By default the Avamar Administrator uses the new Enhanced Log File Viewer

Can hide/display debug messages. In the Activity Monitor Actions Session Log
Options show debug information to enable When enabled (default) Enhanced Log File Viewer includes

Summary section at the top that summarizes errors and exceptions Hyperlinks to jump to individual log files Error message summary in timestamp sorted order with hyperlinks to each individual
error message

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

28

Avamar 6.1 Technical Differences

New Download Support Bundle option in Activity Monitor

User can select new option after selecting a row in Activity Monitor Allows a Support Bundle ZIP file to be easily created and downloaded to the users
system The bundle is created on the client on-demand The bundle can then be provided to Support Only works with pageable clients.

Support bundle includes:


Applicable session log files Avagent messages Directory listing of the VARDIR and BINDIR Linux host information such as dmesg, uname a, ps ef, etc.

Supported on Windows and Linux only


Optionally you can upload the bundle to the utility node of the avamar server. Refer to the Avamar Administration Guide for detailed steps on how to download the support bundle ZIP file.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 9 Admin Updates

29

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 10 - Administration, DTLT and Client Mgr

Avamar 6.1 Technical Differences

Listed are the administration enhancements in Avamar 6.1. More detail is provided in the following slides. Administration Enhancements

Allow privileged users to override backup dataset and schedule Prevent simultaneous restores UI Enhancements Tray icon status Option to not backup on wireless Support for OS agnostic restores New OS Support

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 10 - Administration, DTLT and Client Mgr

Avamar 6.1 Technical Differences

New with the Avamar 6.1 release is the LDAP Configuration Wizard, which is integrated into the Management Console GUI. While the wizard is meant to supersede the avldap script for configuring LDAP, the Avamar avldap script still exists and can still be used. The LDAP Configuration tool can be used to create the ldap.properties and krb5.conf files, edit existing configuration files and also test the LDAP configuration. Changes to the LDAP configuration via this tool will apply to both MCS and Desktop/Laptop (DTLT). Beginning with 6.0, by default users do not have to login to the DT/LT browser interface, since pass through authentication is used.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 10 - Administration, DTLT and Client Mgr

Avamar 6.1 Technical Differences

LDAP Group mapping associates an LDAP Group to an Avamar role within an Avamar domain. This is new feature is particularly important for enterprise organizations because it means that they no longer need to create users within Avamar Administrator to provide users with access. An administrator can simply manage user access to Avamar Administrator with LDAP group membership, and map those groups to appropriate roles within Avamar. Organizations, only need to manage user access to Avamar with appropriate group membership changes in AD/LDAP. When configured, users can login to the Management Console using their Active Directory credentials and inherit the Avamar role based on the LDAP group they are associated with. If more than one role is found within the Avamar domain, the user will inherit the highest privileged role. From the Administration, Account Management tab, select the clients and right-click on clients or the maps table or select New Maps in the menu or toolbar to create, edit or delete an LDAP map. You will need to provide Active Directory user credentials to search for a group in Active Directory

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 10 - Administration, DTLT and Client Mgr

Avamar 6.1 Technical Differences

Timeout values for LDAP group integration default to 60 seconds. This also includes the login that happens just before doing an LDAP group search when adding a new LDAP group role map and you search for groups. When adding a new directory service in the wizard and when testing a directory service there is now a timeout. To change the default timeout length, edit the mcserver.xml file and change the value of <entry key="ldap_services_timeout_seconds" value="60" /> This key is located in the "ldap" node. Then restart mcs. If customers want the ability to manually add LDAP users (like pre-6.1), you can edit the mcserver.xml file under the <node name=ldap> element; change the value of the entry key enable_new_user_authentication_selection to true and restart mcs. The default is false. This enables the combo box in the new user dialogue to choose LDAP.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 10 - Administration, DTLT and Client Mgr

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 10 - Administration, DTLT and Client Mgr

Avamar 6.1 Technical Differences

The following new Administration properties have been added for DTLT. Disallow multiple restores at a time is a new property added to /usr/local/avamar/etc/dtlt.properties. The purpose of this property is to prevent a user, who may not see their restore complete immediately, from filling the queue with restores of the same file. The property disallowMultipleRestores={true,false} default value is true. If this property is set to true, then the user will receive a pop up message stating they already have a restore request in the queue. The Limit Restore Size property is called LimitRestoreSize and is located in /usr/local/avamar/etc/dtlt.properties. Its purpose is to allow an administrator to set a limit of how much data a user can restore at a time in order to prevent a user from tying up the network by attempting a multi-gigabyte or larger restore. By default there is no restriction. If a user tries to restore more than the set limit they see an error telling them to contact the Avamar administrator to restore the files for them. An example is limitRestoreSize={MegaBytes(MB)} for example limitRestoreSize=5000. By default this property is empty. Limit the number of on-demand backups per day to restrict DTLT users from performing more than an allowed amount of on-demand backups per day per client machine. This will prevent a single user from tying up connections by continually submitting on-demand backups. By default there is no limit so the value is false. The restrictBackupsPerDay property is located in the /usr/local/avamar/etc/dtlt.properties file and can be set to -1, which is no limits, 0, which is no backups allowed , 1, 2n etc.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 10 - Administration, DTLT and Client Mgr

Avamar 6.1 Technical Differences

A property has been added to allow the administrator to disable restores from an alternate computer. This will turn off the ability for domain users to perform restores from an alternate computer. The new property is called disableRestoreFromAlternateComputer and is located in /usr/local/avamar/etc/dtlt.properties file. It can be set to true or false. The default value is false. When a client is activated to an Avamar grid by default the allow_scc_snapup_file_selection is set to true. When the value is true the user is allowed to add additional files for an on-demand backup. The new property allowUserInitiatedBackupsFileSelection in the /usr/local/avamar/etc/dtlt.properties file when set to true, it overrides any value set for allow_scc_snapup_file_selection. If the value is set to anything but false, it looks at the allow_scc_snapup_file_selection property in the MCDB for each client. DTLT backup clients may have long time periods during which they do not back up. If the backups expiration policy dictates that a backup be made obsolete, the server will delete a backups unique data during the garbage collection (GC) process even if it is the clients last remaining backup. The server will also allow the backup to be deleted manually without suitable warning, making it easy to overlook that all of the clients unique data will be removed from the system during GC. The new option added to mcserver.xml is keep_last_backup and needs to be set to true to never delete the last version of a backup. It applies to all clients on a server and if the value is changed then you must restart MCS.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 10 - Administration, DTLT and Client Mgr

Avamar 6.1 Technical Differences

The user-login-required property has been moved to /usr/local/avamar/etc/dtlt.properties file. It is no longer located in /usr/local/avamar/etc/ldap.properties file. If the user-login-required property is already set to true in the ldap.properties file, it will have to be manually set in dtlt.properties. It only applies if the value is set to true since the default is false. The allowUserSelectableDataset and userSelectableDatasetLimit properties have been removed from /usr/local/avamar/etc/dtlt.properties . These have been replace by a new property allowUserInitiatedBackupsFileSelection .

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 10 - Administration, DTLT and Client Mgr

Avamar 6.1 Technical Differences

The isclientos is a new attribute that has been added to track the client OS type in EmailHome for 6.1 and later cleints. If the client OS is a non-server OS then we identify it as a DTLT client. In addition to the existing information and the client OS it also sends the following values to the Bytes Protected Client report:

Client Host Name Client Type Client version Client OS GB protected

Client versions prior to 6.1 will not send this attribute, it is default to false, meaning this value is always false for those clients. In the report, Avamar checks the clients version and if it is pre 6.1, the value is changed from false to unknown.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 10 - Administration, DTLT and Client Mgr

10

Avamar 6.1 Technical Differences

The following is a summary of the enhancements made to SMS install. There are new default values for the client setting properties listed in the table. The values are different for server and non-server operating systems. Their associated xml files will be written to the <AVAMAR INSTALLDIR>\var directory. The files are named as reminder.xml, progresswin.xml and balloon.xml. There are new command line arguments that can be used for activations so that you no longer need to activate the client after the install. These options are:

Server: should be set to the Avamar server IP or the complete server name. Domain: should be the FQN of the Domain. The default is /clients. Group: This is a comma separated list of the FQN of the groups. It will default to the /Default Group.

For example: msiexec/IPath_to_msi_package /qn SERVER=10.31.183.12 DOMAIN=/clients GROUP=/clients/test command will activate the client to the specified server, domain, and group association.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 10 - Administration, DTLT and Client Mgr

11

Avamar 6.1 Technical Differences

Avamar 6.1 has improved DTLT support as listed here. More detail is provided in the following slides.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 10 - Administration, DTLT and Client Mgr

12

Avamar 6.1 Technical Differences

The Admin can configure (enable/disable) the Add to dataset feature for the clients in one of two ways via Client Manager or MC. If a client is allowed to add to a dataset, then the backup targets, group dataset and user defined dataset, are merged and applied for all scheduled and on-demand client backups. The Allow Privileged Users to Override Schedule feature allows the user to change the time of their scheduled backup. By default, this option is disabled. The Admin can configure this feature in one of two ways. The ability to change the backup time vanishes when a client is part of a group that only performs weekly or monthly backups.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 10 - Administration, DTLT and Client Mgr

13

Avamar 6.1 Technical Differences

Some additional client enhancements in this release are the ability for the user to set their default start page to search or browse when they launch the restore UI from the tray icon. With the addition of restore from an alternate computer, a user can also restore from a Mac to Windows system and vice versa. Some File/Folder exclusions for Mac have been modified. New values have been added into the ds_excludes for the Mac plug-in. These are the paths that are excluded from a backup on a MAC: */.Trash/ */Library/Caches/ */Library/Cookies/ */Library/Logs/ */Library/PubSub/Feeds/ */Library/Application Support/SyncServices/Local/Windows Lastly, the tray icon indicator now shows the status of the last backup. For example: successful, failed, offline, or warning.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 10 - Administration, DTLT and Client Mgr

14

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 10 - Administration, DTLT and Client Mgr

15

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 10 - Administration, DTLT and Client Mgr

16

Avamar 6.1 Technical Differences

Listed client pre-move checks. Prior to a client move, these checks are performed. If any of these are true, the user will be notified, the event will also be logged and then queued for retry. Update the table based on the following: All pre-checks for Client Move in an order: 1. Verify if the client is not already present on target grid. 2. Verify if the Client is not in any other background process of Client Manager. 3. Verify if the target server has not reached maximum number of clients. The total number of clients includes all those clients which are not yet activated as well. 4. Verify if the target server is online and active with state "FULLACCESS". 5. Verify if the REPLICATION service is not running on source server. 6. Verify if the REPLICATION service is not running on target server. 7. Verify if the client has no running/waiting activities on the source server. 8. If the Last Backup option is selected, verify if the client does not have multiple plugin backups. 9. Verify if the client does not have any backups done to Data Domain Server. 10. Verify if the client is online from the source server. If any of these pre-checks fails, move is considered as failure. Retry is done only if the following pre-check items fail: 4, 5, 6, 7 and 10. At step 4, a local retry of activation for a maximum of 5 times in case of failure is tried. There is a wait of 5 seconds after each retry. Avamar just logs a message for all temporary failures and retry attempts and the client move is queued for retry. ACM will retry any failed sub-operations after waiting for 120 minutes up to 24 times. This setting is configurable in /usr/local/avamar/etc/acm.properties by modifying the following properties: move.retry.frequency.minutes=120 move.retry.attempts=24 After retrying 15 times, it will be logged as a permanent failure and removed from the retry queue. A move retry is attempted if the operation fails with the following error codes: 30014 - Replication failed 22280,22282,22295 Registration failure on target grid 30006 - Client is active after replication (before we try to do retire) 22506 - Retire failed (If it fails because the client is still active - 23018, it's not handled)

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 10 - Administration, DTLT and Client Mgr

17

Avamar 6.1 Technical Differences

The last check-in date and time has been added to delete and retire reports. This additional filter in retire clients report, provides a filter based on number of days a client is idle to select clients to retire or delete. In the Client Details view you can rename a computer, view the backups associated with that client (filter by on-demand and scheduled backups), view any plug-ins installed on the client and edit properties associated with a group dataset, retention, etc.

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 10 - Administration, DTLT and Client Mgr

18

Avamar 6.1 Technical Differences

Copyright 2012 EMC Corporation. All Rights Reserved.

Module 10 - Administration, DTLT and Client Mgr

19