INTEROPERABILITY OF AVAMAR AND DISKXTENDER FOR WINDOWS

TECHNICAL NOTES INTEROPERABILITY OF AVAMAR AND DISKXTENDER FOR WINDOWS ALL PRODUCT VERSIONS TECHNICAL NOTE P/N 300-007-585 REV A03 AUGUST 24, 2009 Table of Contents Introduction...................................................... 2 System Requirements............................................. 3 DiskXtender Configuration......................................... 6 Avamar Configuration............................................. 9 Restore Considerations........................................... 11 Known Issues with Earlier DiskXtender Releases..................... 12 1

Introduction Introduction The purpose of this document is to describe the interoperability of EMC Avamar and EMC DiskXtender for Windows when you use Avamar to back up and restore files on a DiskXtender extended drive. Definitions of DiskXtender Terms Extended drive. NTFS volume, such as a hard drive or partitioned part of a hard drive, for which DiskXtender provides file migration services by moving files to media and fetching files from media according to the parameters you set. File migration. Movement of files and file data from the extended drive to external storage media, such as optical, tape, EMC Centera, or Network Attached Storage (NAS). Purge. Removing file data from the extended drive (after the file has been moved to media), while leaving a file tag behind. The file appears as if it is still on the drive. Fetch. Retrieving file data from storage media when a user requests the file. Specifically, a fetch is moving the file data from the media back to the extended drive. The data remains on the extended drive until it qualifies again for purge. File tag (also called a file stub). Identifying information for a file. The file tag includes such information as file location, file attributes, file size, and file age. When DiskXtender purges a file, it removes the file data from the extended drive and leaves behind a file tag on the extended drive. A file tag consumes between 0 bytes and 1 cluster of disk space. (On Microsoft Windows NTFS systems, a cluster of disk space averages approximately 4 KB, although the size depends on a number of variables.) Retention. The process of restricting editing and deletion of files for a specified period of time. INTEROPERABILITY OF AVAMAR AND DISKXTENDER FOR WINDOWS TECHNICAL NOTE 2

System Requirements System Requirements Supported Releases DiskXtender release 6.3 with patch 2, or later releases of DiskXtender, is recommended when you use Avamar. There are several known issues that require workarounds when you use earlier releases of DiskXtender with Avamar. Known Issues with Earlier DiskXtender Releases (page 12) provides details. Avamar releases 4.0.3.24 and later are qualified for use with DiskXtender to ensure a proper configuration. Supported DiskXtender Media Services When you use Avamar to back up a DiskXtender extended drive, all media services are supported, including: EMC Centera NAS DiskXtender MediaStor IBM Tivoli Storage Manager (TSM) Sun StorageTek ACSLS Number of Files on the DiskXtender Server Past experience in backing up millions of small files demonstrates that the Avamar client can process, on average, approximately 1 million files per hour of backup time. Because there is typically a 2-to-1 variation between the maximum time and the average time, this implies that a file system with 5 million files requires a backup window of 10 hours. This calculation is based on a typical daily file modification rate of approximately 2 percent of files. If the average daily file modification rate on the DiskXtender server is less than 2 percent (that is, the file system is relatively static), then the maximum number of file tags that can be protected by the Avamar client agent can be extended to about 8 million. In other words, the total number of files on all extended drives on the DiskXtender server should total no more than 8 million files. If the average daily file modification rate is 2 percent or higher, then it is important to limit the maximum "size" of the client to 5 million file tags or less. In other words, in this case, the total number of files on all extended drives on the DiskXtender server should total no more than 5 million files. INTEROPERABILITY OF AVAMAR AND DISKXTENDER FOR WINDOWS TECHNICAL NOTE 3

System Requirements Avamar Client Installation Install the standard Avamar client on the DiskXtender server. For more information on installation of the Avamar client, refer to the Backup Clients Installation Guide and Reference Manual. Avamar Client Cache File Size If there are a significant number of purged files on the extended drive, the combination of the small file tag size and large quantity of the file tags together with either changes to them or the creation of new files can significantly impact the performance of backups. Therefore, it is important to ensure the proper sizing of the Avamar client cache files. By default, the Avamar file cache can grow up to 1/8 of the physical RAM. A general rule of thumb is for every 1 million file tags on the DiskXtender server, there should be 512 MB of physical RAM. For instance: 1 million file tags requires 512 MB RAM 5 million file tags requires 2.5 GB RAM (recommended maximum) 8 million file tags requires 4 GB RAM (maximum) Also keep in mind these important notes on cache file sizing: The most important rule is to ensure that the caches do NOT grow to the extent that the client ends up swapping because it has insufficient physical RAM to handle all processes. NEVER exceed 1/4 of the total available physical RAM. It is important to set the maximum file size as a fraction of the total available physical RAM. In other words, specify the file cache sizes by using negative integers. If you use a cache size value that is different from the default, it is best to place the customized cache settings in the avtar.cmd file. Any client that requires more than 4 GB of RAM to accommodate an adequately sized file cache will probably run into other bottlenecks that prevent it from backing up reliably every night. The following table shows the maximum number of file tags that can be cached depending on available physical memory and whether filecachemax is set to -8 (default setting) or -5. AMOUNT OF PHYSICAL RAM DEFAULT FILE CACHE SETTING (-8 OR 1/8 OF PHYSICAL RAM) CUSTOM FILE CACHE SETTING (-5 OR 1/5 OF PHYSICAL RAM) 0.5 GB 1 M files 2 M files 1.0 GB 2 M files 4 M files 1.5 GB 4 M files 4 M files 2.0 GB 4 M files 8 M files (max) 2.5 GB 4 M files 8 M files (max) 3.0 GB 8 M files (max) 8 M files (max) INTEROPERABILITY OF AVAMAR AND DISKXTENDER FOR WINDOWS TECHNICAL NOTE 4

System Requirements AMOUNT OF PHYSICAL RAM DEFAULT FILE CACHE SETTING (-8 OR 1/8 OF PHYSICAL RAM) CUSTOM FILE CACHE SETTING (-5 OR 1/5 OF PHYSICAL RAM) 3.5 GB 8 M files (max) 16 M files (over max) 4.0 GB 8 M files (max) 16 M files (over max) INTEROPERABILITY OF AVAMAR AND DISKXTENDER FOR WINDOWS TECHNICAL NOTE 5

DiskXtender Configuration DiskXtender Configuration Configuring DiskXtender to Use the Archive Attribute If you use DiskXtender 6.3 with patch 2, or a later release of DiskXtender, then you can configure DiskXtender to enable the Archive attribute when it changes the extended attributes for a file. DiskXtender may change the extended attributes for a file when you edit retention on the file or when the migration (back-end media) information for a file changes, for example, as part of compaction or multi-target migration changes. NOTE: The Archive attribute is also enabled when other changes to the file occur, such as when you edit the file data or change the Read-only attribute. You can then configure Avamar to back up files based on whether the Archive attribute is enabled. This helps to ensure that all files are backed up appropriately regardless of the type of change to the file. In earlier releases of DiskXtender, there was no way for Avamar to recognize changes to the extended attributes for a file. Known Issues with Earlier DiskXtender Releases (page 12) provides details and workarounds. The method you use to enable the Archive attribute for changes to extended attributes depends on the DiskXtender release. IF YOU USE THIS DISKXTENDER RELEASE FOLLOW THESE INSTRUCTIONS TO ENABLE THE ARCHIVE ATTRIBUTE 6.3 Patch 2 Enabling the Archive Attribute with a Registry Edit (page 7) 6.3 Service Pack 1 Enabling the Archive Attribute with the Service Option (page 6) 6.4 Enabling the Archive Attribute with a Registry Edit (page 7) 6.4 Service Pack 1 and later Enabling the Archive Attribute with the Service Option (page 6) Enabling the Archive Attribute with the Service Option To use a service option to configure DiskXtender to enable the Archive attribute for changes to extended attributes: 1. Ensure that DiskXtender 6.3 Service Pack 1, 6.4 Service Pack 1, or a later release is installed. 2. From the Service menu, select Properties. The Service Properties dialog box appears. 3. Click the Options tab. INTEROPERABILITY OF AVAMAR AND DISKXTENDER FOR WINDOWS TECHNICAL NOTE 6

DiskXtender Configuration 4. Scroll through the list and select the Enable Archive attribute after EA changes option. 5. Select Enable the Archive file attribute when extended attribute (EA) changes occur for a file to enable the option. 6. Click OK. By default, DiskXtender does not enable the Archive attribute when EAs change. Enabling the Archive Attribute with a Registry Edit To edit the Windows registry on the DiskXtender server to configure DiskXtender to enable the Archive attribute for changes to extended attributes: 1. Ensure that DiskXtender 6.3 with patch 2 or DiskXtender 6.4 is installed. 2. Stop the DiskXtender service. 3. Open the Windows Registry Editor on the DiskXtender server. 4. Navigate to the following registry key: HKLM\SYSTEM\CurrentControlSet\Services\DxSpy\Parameters 5. Create a DWORD value with the name ArchiveToggle. 6. Set the value to 1. 7. Restart the DiskXtender service. Setting the Extended Drive Option for Backups The 3rd party backup mode for managed files setting, which is available on the Options tab of the Extended Drive Properties dialog box in DiskXtender, controls how Avamar should back up files that DiskXtender has moved to media. If the file has been purged, then Avamar backs up only the file tag. However, if the file has been migrated to media but the file data is still on the extended drive either because the file has not yet been purged or because the file was fetched after it was purged then you can specify whether the backup should contain only the file tag or both the file tag and the file data. The following options are available for the 3rd party backup mode for managed files setting: To back up only the file tags for fetched files, leave the default selection of Fast backup - read migration info only. To back up the full file data for fetched files, select Snapshot compatible - unfiltered file data. Do not select the full backup option (Full backup - read all file data, including migration info). When this option is selected, the backup includes the full file data for all files, even if the files are purged. This option is not recommended because it causes a fetch for any purged files for the purpose of the backup. A significant number of file fetch requests decreases system performance, and the extended drive may not have enough disk space to accommodate the file data that is fetched. INTEROPERABILITY OF AVAMAR AND DISKXTENDER FOR WINDOWS TECHNICAL NOTE 7

DiskXtender Configuration NOTE: The Snapshot compatible option, which is available only in DiskXtender 6.3 and later, also is recommended because it enables faster backups than either the Fast backup or Full backup options. Configuring Purge Settings Consider the backup schedule and your file backup requirements when you determine how to configure file purging in DiskXtender. To include the full file data in an Avamar backup, which is recommended, then wait to purge files until after a backup has occurred. To do this, configure purge rules with an age delay that is sufficiently longer than the time between backups. In addition, set the 3rd party backup mode for managed files option to Snapshot compatible. NOTE: The Snapshot compatible setting is not available in DiskXtender releases earlier than 6.3. As a result, if you use an earlier release, you will not be able to back up the full file data for files that have been migrated to media. If you plan to include only file tags in the backup, then the purge settings that you select depend on other criteria in the environment, as discussed in the DiskXtender documentation. In addition, you should leave the default of Fast backup for the 3rd party backup mode for managed files option. Increasing the Retention Delay When you apply retention to a file through DiskXtender, the file cannot be edited or deleted on the extended drive until the retention expires. You also cannot rename retained files, change their attributes, or move them to another location on the extended drive. The retention setting for a file is stored in the EAs for the file. When you restore a file with retention to the extended drive, the restore is typically done in two passes: one to restore the file data and the other to restore permissions, attributes, and so forth. DiskXtender evaluates the file and applies retention, if the file qualifies. If this evaluation occurs too quickly, the file may be retained and therefore become read-only before Avamar can perform the second pass to restore the original retention setting and other EAs. If necessary, you can extend the number of seconds that retention enforcement is delayed. To edit the retention delay, use the Delay in seconds before retention period is enforced option on the Options tab of the Extended Drive Properties dialog box. The default setting of 10 seconds may not be sufficient when you restore files with retention. You can further delay retention enforcement, if necessary, by setting an age delay for the move rules. When move rules contain an age delay, files do not qualify for the rules and therefore, retention is not enforced until a certain number of days have passed since the file was created, last accessed, or last written to (modified). INTEROPERABILITY OF AVAMAR AND DISKXTENDER FOR WINDOWS TECHNICAL NOTE 8

Avamar Configuration Avamar Configuration If you use DiskXtender 6.3 with patch 2, or a later release of DiskXtender, then you can configure DiskXtender to enable the Archive attribute when it changes the extended attributes for a file. You can then configure Avamar to back up files based on whether the Archive attribute is enabled. In earlier releases of DiskXtender, there was no way for Avamar to recognize changes to the extended attributes for a file, which occur when you edit retention on the file or when the migration (back-end media) information for a file changes as part of compaction or multi-target migration changes. Known Issues with Earlier DiskXtender Releases (page 12) provides details and workarounds. You can configure Avamar to back up either a single client or all clients in a dataset based on the status of the Archive attribute. If there is a single DiskXtender server in the environment, for example, then you may want to make the change on only that server. If there are multiple DiskXtender servers, then you may want to create a dataset for the DiskXtender servers, and then make the change for the dataset. Configuring a Single Client to Use the Archive Attribute To configure Avamar to back up a single client based on whether the Archive attribute is enabled: 1. On the DiskXtender server, navigate to C:\Program Files\avs\var\. 2. Use a text editor such as Notepad to create a file with the name avtar.cmd. 3. Open the file and type the following flags: --resetarchive --usearchiveattr IMPORTANT: Ensure that each flag is on a separate line, and that there are two hyphens (--) in front of each flag. 4. Save and close the file. The next time that a backup occurs, Avamar reads the avtar.cmd file and backs up only files with the Archive attribute enabled. Configuring a Dataset to Use the Archive Attribute To configure Avamar to back up all clients in an entire dataset based on whether the Archive attribute is enabled: 1. Open the Avamar Administrator interface. 2. Open the Tools menu and select Manage Datasets. The Manage All Datasets window appears. 3. Select the dataset that contains the DiskXtender clients. INTEROPERABILITY OF AVAMAR AND DISKXTENDER FOR WINDOWS TECHNICAL NOTE 9

Avamar Configuration 4. Click Edit. The Edit Dataset dialog box appears. 5. Select the Options tab 6. From the Select Plug-In Type list, select Windows File System. 7. Click More in the bottom right corner of the dialog box. 8. In the Enter Attribute box, type --resetarchive. 9. Click the plus sign (+) button to add the attribute to the list at the bottom of the dialog box. 10. In the Enter Attribute box, type --usearchiveattr. 11. Click the plus sign (+) button to add the attribute to the list at the bottom of the dialog box. IMPORTANT: Ensure that each flag is on a separate line, and that there are two hyphens (--) in front of each flag. 12. Click OK. The next time that a backup of the dataset occurs, Avamar backs up only files with the Archive attribute enabled. INTEROPERABILITY OF AVAMAR AND DISKXTENDER FOR WINDOWS TECHNICAL NOTE 10

Restore Considerations Restore Considerations Restoring Individual Files When you restore files to the extended drive that have been accidentally deleted, restore them to the same location from which they were deleted. Do not restore files to a different location. The type of media to which the files are migrated determines whether you need to restore the file tag or the full file with all of its data. The EMC DiskXtender Release 6.3 Microsoft Windows Version Administration Guide, or later releases of the same guide, provide details on how to restore individual files. The guidelines also apply to earlier releases of DiskXtender and discuss the recommendation to use the DiskXtender Recycler to recover files when you use EMC Centera, NAS, TSM (as a media service), or removable media formatted with the UDF file system. IMPORTANT: If the DiskXtender Recycler is enabled, do not restore a file from a backup unless you are certain that the file is not in the DiskXtender Recycler and that the file in the backup is a full version of the file (not a file tag). Data loss can occur when you restore a file tag from a backup but the file data is no longer on the media. Restoring Files with the RA Attribute Files that have the RA (Read-only and Archive) attributes set cannot be overwritten during a restore to original location. They can only be restored to an alternate location. NOTE: This is a known issue with the Avamar Windows File System client and is not specific to DiskXtender. Restoring the Entire Extended Drive To restore the entire extended drive after a catastrophic system failure, review the steps in the EMC DiskXtender Release 6.3 Microsoft Windows Version Administration Guide, or later releases of the same guide, to ensure that you perform the necessary steps to restore the environment in the proper order. The steps also apply to earlier releases of DiskXtender. INTEROPERABILITY OF AVAMAR AND DISKXTENDER FOR WINDOWS TECHNICAL NOTE 11

Known Issues with Earlier DiskXtender Releases Known Issues with Earlier DiskXtender Releases If you use DiskXtender 6.3 with patch 2, or a later release of DiskXtender, then you can configure DiskXtender to enable the Archive attribute when it changes the extended attributes for a file. You can then configure Avamar to back up files based on whether the Archive attribute is enabled. However, in earlier releases of DiskXtender (6.3 patch 1 and earlier), there was no way for Avamar to recognize changes to the extended attributes for a file. As a result, the file information in the backup was outdated. If you restored an outdated file, several issues could occur. The following sections describe the scenarios when these situations could occur, as well as how to work around the resulting issues. Editing Retention If you change the retention setting for a file by using an earlier release of the DiskXtender Explorer Add-ons utility, then Avamar does not recognize to the change to the file. As a result, the retention information for the file in the backup reflects the original retention setting for the file. If you restore the outdated file to the extended drive from the backup, then the file is restored with the original retention setting. The workaround for this issue depends on whether you edit retention for one or a few files, or for a significant number of files: If you edit retention for one or a few files, change the state of the files by either fetching or purging them. (To fetch a file, open the file. To purge an individual file, use the DiskXtender Explorer Add-ons utility.) This changes the Offline attribute for the files, which causes Avamar to back them up again. If you edit retention for a significant number of files, perform a no-cache backup. Multi-Target Migration With multi-target migration, DiskXtender migrates the same file to multiple pieces of media. Consider the following issues when you configure multi-target migration in an environment with Avamar and an earlier release of DiskXtender. Adding a Media Target If you add a media target after a file has already been migrated to media, then DiskXtender adds the information for the new target to the EAs for the file. The files that have already been written to media and purged must be fetched back to the extended drive so that they also can be written to the new media. The files are then purged again. This fetch process synchronizes the files on the first media with the files on the second media, and is called sync-fetch. If the Avamar backup occurs after the file has been migrated to all media targets, then the backup includes the correct migration information for the file. However, if you add a media target after the backup occurs, then Avamar does not note the change. As a result, the migration information for the file in the backup does not include the migration information for the new target. INTEROPERABILITY OF AVAMAR AND DISKXTENDER FOR WINDOWS TECHNICAL NOTE 12

Known Issues with Earlier DiskXtender Releases If you restore the outdated file to the extended drive, then DiskXtender must sync-fetch the file again during the next background scan. This is not an issue with a relatively small number of files. However, system performance decreases considerably when DiskXtender must sync-fetch a large number of files. Avamar backs up the file with the information for the new target only after the file qualifies for backup as a result of other changes, such as content edits, changes to the Read-only attribute, and so on. To work around this issue, perform a no-cache backup after the initial sync-fetch process is complete. File Expiration from Media Targets With DiskXtender 6.3 and later, you can define expiration policies for each target media group by using the Automatically expire files setting on the Options page for the media group. When a file meets the expiration criteria for a target media group, it is deleted from the media in the group during the next background scan. However, the file remains on media in other target media groups until it meets the expiration criteria for those groups. Avamar does not note when the EAs for a file are updated to reflect the expiration of the file from a target media group. As a result, the migration information for the file in the backup includes the migration information for the target from which the file was expired, even though the file was deleted from the target. If you restore the outdated file to the extended drive, then DiskXtender must "expire" the file again, which involves removing the migration information for the expired target from the file attributes. DiskXtender cannot delete the file from the target media a second time, as the file was already deleted from the media during the initial expiration. The file in the Avamar backup is updated to reflect the expiration from the media target only if the file qualifies for backup as a result of other changes, such as content edits, changes to the Read-only attribute, and so on. Compaction When you compact a piece of media, DiskXtender returns all active files that are on the media to the extended drive, and removes the migration information from the files. The files then qualify for move rules, and DiskXtender moves them to a different piece of media. You can use compaction to remove a piece of media from DiskXtender but keep the files from the media on the extended drive. You also can use compaction as part of the process to reclaim wasted space on some types of removable library media. However, Avamar does not recognize the attribute changes that are made to the files during the compaction process in earlier releases of DiskXtender. These attribute changes include the removal of the migration information for the compacted media, and the addition of the migration information for the new media to which the file is migrated. As a result, the migration information for the files in the backup reflects the migration information for the compacted media instead of the new media. INTEROPERABILITY OF AVAMAR AND DISKXTENDER FOR WINDOWS TECHNICAL NOTE 13

Known Issues with Earlier DiskXtender Releases If you restore the outdated files to the extended drive and the files are purged, then data unavailability occurs. This is because the file tag points to the compacted media, and DiskXtender cannot fetch the file data from the compacted media, which is no longer in the system. To work around this issue, perform a no-cache backup after you compact a piece of media. If you do not perform a no-cache backup, the files are still available on the new piece of media that they move to after the compaction. To recover the files, perform a File Restore media task on the media. In addition, configuration of automatic media compaction for removable media by using the Automation page for a media group is not recommended when you use Avamar to back up the extended drive. You must monitor media compaction closely to ensure that the files on the backup reflect the files on the extended drive, and automatic compaction takes place without user intervention. Instead, monitor and manually perform media reuse by using the instructions in the EMC DiskXtender Release 6.3 Microsoft Windows Version Administration Guide, or later versions of the same guide, which are available on the Powerlink website. These instructions also apply to earlier releases of DiskXtender. Promotion of Copy Media If you use removable library media, such as tape or optical, you may create copies of the media to ensure storage redundancy. If an original piece of media becomes corrupt, you can promote a copy of the media and remove the original from the system. However, when you promote the copy in an earlier release of DiskXtender, Avamar does not recognize the attribute changes that are made to the files on the extended drive to recognize the copy instead of the original. As a result, the migration information for the files in the backup reflects the migration information for the original instead of the copy. If you restore the outdated files to the extended drive and the files are purged, then data loss may occur. This is because the file tag points to the original media, and DiskXtender cannot fetch the file data from the original media, which is no longer in the system. An EMC Customer Support Representative may be able to recover the files from the original media. However, if the original media is irreparably damaged, then you may not be able to recover the files. If you restore the outdated files to the extended drive and the restore includes the full file data, you can update the files to force DiskXtender to remigrate the files to media. When the files are updated, Avamar recognizes the updates and backs up the files with the correct information. INTEROPERABILITY OF AVAMAR AND DISKXTENDER FOR WINDOWS TECHNICAL NOTE 14

Copyright ゥ 2009 EMC Corporation. All rights reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. THE INFORMATION IN THIS PUBLICATION IS PROVIDED "AS IS." EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. All other trademarks used herein are the property of their respective owners. INTEROPERABILITY OF AVAMAR AND DISKXTENDER FOR WINDOWS TECHNICAL NOTE 15