avamar technical differences srg.pdf

1

Avamar 6.1 Technical Differences

Copyright © 2012 EMC Corporation. All Rights Reserved. Module 1 – Course Introduction

2


Copyright © 2012 EMC Corporation. All Rights Reserved. Module 1 – Course Introduction

1


Copyright © 2012 EMC Corporation. All Rights Reserved. Module 2 – VMware Enhancements

2



3



4



5



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.

6



This animation shows the automated steps undertaken when an image backup is triggered.

1. Work Order for VM Image Backup is initiated by MC to the agent on the proxy appliance.

2. Architecture Determined by VCBImage – identifying the current hypervisor for the VM, and its location on which datastore

3. VCBImage initiates a Snapshot of the VM

4. Proxy Appliance mounts snapshot also using VCBImage

5. Backs up VM folder to Avamar using avtar

7



This animation highlights the operations triggered by an image restore.

1. MC issues the restore work order to the proxy

2. 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

3. Avtar ships the image recover data (using Changed Block Tracking - CBT - if enabled and available) to the proxy server, which forwards data to datastore

4. VM is registered and ready (though powered off)

8



This animation indicates the processes involved to allow the ability to browse the contents of an Image backup within MC.

1. When you click on the “Browse for Granular Restore” button, MC issues Browse request to Proxy. The VMware FLR plugin accepts the requests

2. The FLR plugin on the proxy triggers an AvFS mount of the folder containing the backup files associated with the request.

3. 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

4. The Proxy forwards file/folder structure back to the MC to display to console, and updates the list as subdirectories are selected.

9



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. 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

2. 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.

10



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.

2. The Proxy then uses VMware VIX API to copy files to guest VM filesystems.

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.

11



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

12



1. Configure vCenter-to-Avamar authentication

• Either Install a certificate on the Avamar MCS

• Or turn off authentication for all vCenter-to-Avamar MCS communications

2. Create dedicated vCenter user account

• With specific rights, outlined in the Avamar VMware Guide.

3. Add vCenter server to MC

• Use account created above.

4. Deploy Proxy

• 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!!!

• In MC, Associate proxy/proxies with datastores and groups

5. Add VM clients to MC

• Choose Changed Block Tracking

13



14



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

Image Restore

• Individual disks / full VM

• To original VM, different-but-existing VM, new VM

• To an ESX/ESXi host in the vSphere

File Level Recovery (FLR)

• 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.

Same platform only

VM must be powered on and VMware Tools installed.

15



16



17



18



19



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 thin-disk 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.

20



21



22



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.

23



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 we’re taking a snapshot, and especially with recovery)

24



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

25



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.

26



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

27



28



29



30



31



32



33



34



35



36



37



38



39



1


Copyright © 2012 EMC Corporation. All Rights Reserved. Module 3 – Hyper-V Integration

2



3



4



5



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”

6



7



8



9



10



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

11



12



13



14



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. VM’s created with storage housed on CSV can be configured as highly available VM’s in the cluster.

6. VM’s can also be created as standalone using either local storage or CSV

15



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 VM’s stored on the CSVm but hosted on another Hyper-V server, will have their I/O’s directed over the LAN from host to host, resulting in a potential performance impact.

This animation shows the dataflow of such a situation.

16



17



Using federated backup of all VM’s in “hv-cluster” will result in backup work orders forwarded to the active hosting servers of the respective vm’s. 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 vm’s such as vm5 and vm6. To back those up, you will need to select them via their hosts (hv1 and hv3 respectively).

18



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.

19



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.

20



21



22



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

23



24



25



26



27



28



29



30



31



32



33



34



35



36



37



38



39



40



41



1


Copyright © 2012 EMC Corporation. All Rights Reserved. Module 5 – Sybase

2



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

3



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 can’t 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

4



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.

5



6



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.

7



The Sybase plug-in supports two-node active-passive clusters on Solaris only. An active-passive 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

8



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’

9



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.

2. 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.

3. For each issued dump command, the avsybase process starts an avtar process.

4. For each received dump command, the Sybase server launches a backup server that loads the libsybase_avamar.x library.

5. 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.

6. Depending on the specified backup destination, the avtar process writes the backup data to either the Avamar server or a Data Domain system.

10



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.

11



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.

12



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. Download and Install the Avamar client and plug-in for your OS

2. Register/Activate

3. Copy the Avamar Plug-in for Sybase library file

4. Edit avsybase scrip to include OCS path for library

13



14



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.

15



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.

16



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.

17



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.

18



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.

-----------------------------------

19



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

.

20



21



22



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

1


Copyright © 2012 EMC Corporation. All Rights Reserved. Module 6 – SAP

2



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.

3



4



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.

5



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.

6



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.

7



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.

8



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.

9



10



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-in’s 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.

11



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.

12



1


Copyright © 2012 EMC Corporation. All Rights Reserved. Module 6– MS SQL Enhancements

2



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

3



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.

4



5



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.

6



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.

7



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.

8



New feature to detect a gap in the SQL log files and promote an incremental backup to full backup.

Use Case: Another backup vendor’s 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.

9



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:

10



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)

11



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>,…

12



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

13



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.

14



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

15



16



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.

17



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

18



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.

19



20



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

21



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.

22



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 order—master, 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

23



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.

24



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

1


Copyright © 2012 EMC Corporation. All Rights Reserved. Module 7 – Microsoft Exchange VSS Plug-in Enhancements

2



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.

3



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 multi-streaming to group backups by volume or by database.

4



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.

5



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.

6



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 it’s already been backed up on EXCH2.

4. The passive copy backups are sent to the Avamar server.

7



8



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

9



10



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

11



12



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

13



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.

14



15



• 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

16



• Add Best practices: use multi stream for large databases ~20-30 TB

• Use Full’s and Incremental, use multi-streaming. To scale out large databases

17



1


Copyright © 2012 EMC Corporation. All Rights Reserved. Module 8 – Other Client Enhancements

2



3



4



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.

5



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.

6



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

7



8



• 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.

9



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.

10



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.

11



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 plug-in for Oracle RAC is configured from one of Oracle RAC nodes by using this utility.

12



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.

13



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. If the var folder is NOT shared, de-activate Oracle RAC name from Avamar Administrator/Policy Manager

3. Select the available nodes 4. Click configure to add new nodes to the Oracle plug-in configuration on the RAC 5. Start the EMCagent using the cluster command on any node

14



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.

15



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.

16



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

17



• 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.

18



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.

19



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.

20



• 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.

21



• 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.

22



• 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.

23



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-in’s 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

24



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.

25



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.bgl-

avamar.emc --ap=client --acnt=/clients/bala2k3win145.bgl-avamar.emc

C:\Domino\data –debug

Restore:

#avlotus.exe --operation=restore --id=client@/clients/bala2k3win145.bgl-

avamar.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.

26



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 re-initiated after the failover.

27



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 “suncluster-configure.sh” script, which lists all of the configuration options.

28



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.

29



On successful configuration on the active node, the script prompts you for registration or re-registration 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.

30



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 disable AVMRAppRes-<resource group name>

clrs set -p Failover_enabled=true AVMRAppRes-<resource group name>

clrs enable AVMRAppRes-<resource group name>

2. Failover the resource group after specific number retrials . Cluster Commands:


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=# AVMRAppRes-

<resource group name>


31



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.

32



2



• 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

3



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.

4



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.

5



6



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.

7



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.

8



9



10



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.

11



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

12



13



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 Institute’s OpenSSL for client/server communications features Data-at-Rest Encryption, and In-flight Encryption running on non-Windows® 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 Microsoft’s® 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.

http://en.wikipedia.org/wiki/Federal_Information_Processing_Standard

14



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.

15



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.

16



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.

17



18



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.

19



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, Avamar’s 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.

20



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

21



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.

22



Here is a list of error codes and messages.

23



24



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.

25



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.

26



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.

27



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"

28



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

29



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 user’s 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.

2



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

3



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.

4



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

5



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.

6



7



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, 2…n etc.

8



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.

9



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.

10



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.

11



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/I“Path_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.

12



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

13



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.

14



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.

15



16



17



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)

18



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.

19



avamar technical differences srg.pdf

Documents

Transcript of avamar technical differences srg.pdf