Migration Archiving - File Archiver for Windows Agent

Topics | How To | Related Topics

Overview

How to Setup and Run a Migration Archive Operation

Protecting Stubs in Backups

Migration Archiving Considerations

Data Classification
Encryption
Filters
Quotas
Limitations
NAS Archiving
Stubs (Recovery, Icons, Recall Failures, Etc.)

Registry Keys for Migration Archiving

Advanced Archive Options

Overview

Migration Archiving of data allows preservation, transparent retrieval, and discovery of information held within file system and Network Attached Storage (NAS) environments. Migration archiving reduces the size of data on the primary storage and decreases the duration of backup operations by the corresponding iDataAgent. Migrating data from file systems and NAS devices to secondary, tiered-storage maximizes storage utilization across the enterprise.

Migration archiving can optionally create stubs that contain information about the archived data to facilitate end-users with non-browse recovery operations from third-party applications. Migrated data can also be recovered from the CommCell Console using the browse recovery operation whether the stubbing feature is enabled or disabled. Additionally, migration archiving employs centralized, policy-based storage to reduce costs and simplify management.

Migration archiving operations use:

Archiving Rules
These rules specify criteria for the types of data to archive. These rules are configured on a per subclient basis. Rules are grouped by:
- File Rules - These rules relate to the low and high watermarks for free space on volumes as a basis for determining whether to scan a volume for archiving and to know when to stop archiving. For example, to scan a volume and start the archiving operation when the volume is low on free space and to stop the archiving after space has been freed up on the volume due to archiving. The rules also allow files to be archived based on a file's age and/or size.
  It is recommended to set minimum file size to 2 Kb so that files to be archived are at least the size of the stub.
- Stub Rules - The stub rules allow you to determine when stubs are pruned and to disable stub creation altogether.

Data Classification Rules - With the addition of Data Classification Enabler, migration archiving can archive files based on rules beyond traditional files and folder paths. These rules include or exclude folders/files "owned" by specific individuals or specific folders/files in archive operations. With Data Classification, data is classified according to its use, type, and value that allows flexibility in creating rules that meet the changing needs of organizations.

On Demand File Lists
Migration archiving also supports using an On Demand File List to archive data though the use of an external list of files. This can be useful for data protection administrators to archive the data they want on demand, regardless of the archiving rules. On demand file lists can be used as a stand-alone method of performing manual archiving, or it can be used with the criteria established in the Archiving Rules.

How to Set Up and Run a Migration Archive Operation

The following section provides the steps to set up and run a Migrate Archive Operation:

Enable the Archiving Rules for the subclient that contains the content you wish to archive. See Enable (Disable) Archiving Rules for step-by-step instructions.

By default, this option is selected and archiving rules are initially disabled. When selected, all archiving rules will be ignored except for Stub Rules.
Configure the Archiving Rules for the subclient. In particular, decide if you want to create stubs in your environment. Even if the Archiving Rules are disabled, the Stub Rules will apply. See Configure Archiving Rules - File Archiver Agents for step-by-step instructions.
Optionally, create an On Demand File List to archive data though the use of an external list of files on a given subclient. This file can be used with or without enabling the Archiving Rules. See How to Set Up and Run an On Demand Archive Operation.
Run an archive operation. See Start a Migration Archiving Operation for step-by-step instructions.
- If stubs were created, end-users or applications can recover files with a non-browse recovery operation by simply opening the stub file, thereby causing it to be restored. (see Recover a File from Windows Explorer).
- If stubs were not created, then you can perform a browse recovery with CommCell Console (see Recover a File from the CommCell Console.

Protecting Stubs in Backups

Stubs serve as placeholders for the data that is moved to secondary storage. Protecting stubs is useful to maintain the ability of non-browse recovery operations. For example, if there is a disk failure, the data can be restored along with the stubs. This reduces the size of the data in the volume as stubs consume less space.

Stubs can be protected by running a backup as follows:

Local File System instance
Stubs from Local File System instance can be backed up by running a Full backup from the Windows File System iDataAgent.
Celerra and FPolicy instances
Stubs from Celerra and FPolicy instance can be backed up running a Full backup from the NAS NDMP iDatAgent.

For more details on Celerra Instance, see Managing Celerra Data.

For more details on FPolicy Instance, see Managing NetApp Data.
Network File Share instance
Stubs from Network File Share instance can be backed up by running a Full backup from the Windows File System iDataAgent. In this case, the backup must be run from a client that does not have the File Share Archiver Client installed.

For more details on Network File Share Instance, see Managing Network File Share Data.

File access times when both File Archiver and File System iDataAgents are installed

Archiving files based on file access times has special considerations. Ordinarily the action of backing up a file using the File System backup agent will cause the file access time to change to the time of the backup. This action may have an undesired effect on the archiver agent if you want to archive files based on access times.

To workaround this situation, you should either use Classic File Scan with the Preserve File Access Time option selected as the scan method OR a software snapshot (VSS or Qsnap) to accomplish the backup. If the software snapshot fails (i.e. VSS service unavailable or unable to quiesce the volume), you can use the Open Files Failure Actions dialog box to select the desired action to be performed.

Windows 2008 servers have access time update disabled by default. The user must enable access time update for migration rules to work properly. This attribute is configurable on Windows 2003 and is enabled by default.

Including Stubs in Incremental Backups

Stubs are not included by default in Incremental Backups when the Classic Scan method is used to scan files. This means that stubs created after the most recent full backup may be lost if the operating system or file structure where the stubs reside is destroyed or rendered unusable before the next full backup is run. However, the archived data is still recoverable through a browse recovery operation from the CommCell Console.

iDataAgents can be configured to include stubs in Incremental Backups (and in turn Synthetic Full Backups ) so that stubs are not lost. Stubs can be included in Incremental Backups as follows:

Enable the Check Archive Bit During Backups option on the backup set of the associated File System iDataAgent prior to running the incremental backup. See Set the Archive Bit Attribute for step-by-step instructions.

Enable the Use Change Journal or Use Data Classification option on the backup set of the associated File System iDataAgent prior to running the incremental backup. See Using Change Journal, Classic File Scan, or Data Classification Enabler for Backups.
When archiving NAS data, the issue of whether or not its corresponding NAS NDMP iDataAgent includes stubs in incremental backups is dependent upon the type of filer. However, most NAS File Servers will include stubs by default in Incremental Backups since the change to the content of the file as a result of the stubbing will be recognized by the system and therefore will include stubs in Incremental Backups.

Migration Archiving Considerations

Before performing any migration archiving procedures, review the following information:

Data Classification

If you archive a job using a non-DataClassSet subclient, the Data Classification install folder (if present) will not be excluded from the job unless you either have installed the Data Classification Enabler in the default location (under Program Files) or filter out the folder from the archive job. Therefore, the easiest way to prevent this problem is to install the Data Classification in the default location.
Migration archiving from the DataClassSet (archive set) level is not supported. You must archive data from the subclient level.

Encryption

Before you can run a stub recovery operation of encrypted data (i.e., using pass-phrase security), you must export the pass-phrase to the local computer. Refer to Export an Encryption Pass-Phrase for the procedure to export the pass-phrase. If you have changed the encryption settings for your client since the data was archived, refer to Change Encryption Settings to understand potential impacts to recovery behavior.

Filters

Filters can be used with the Items That Failed list on the data protection Job History Report to eliminate backup or archive failures. Filters may be used to exclude items which consistently fail and are not integral to the operation of the system or applications.
Some items fail because they are locked by the operating system or application and cannot be opened at the time of the data protection operation. This often occurs with certain system-related files and database application files.
Application files/folders including software installation, magnetic mount path folders, databases, and mount path folders on which backup data resides should not be archived and must be manually filtered out.

Quotas

Do not set a quota for an object (such as a volume, directory, or user) that is lower than the amount already used. Doing so may cause improper results for data protection or recovery operations.

Limitations

Archived files will not get stubbed when the job results path is a UNC path. Therefore, it is recommended to save job results in a local file such as the default path as opposed to specifying the UNC path.

The File Archiver for Windows Agents supports file paths with a maximum of 1000 characters.
For Celerra instances, file names cannot be longer than 242 bytes.
Similarly for Celerra Proxy subclients, file names cannot be longer than 242 bytes as Windows has a 260 byte limitation on file names.

NAS Archiving

When configured for NAS archiving, the client hosting the Agent, must either be in the same domain in which the filer resides or in a different domain from the filer provided that there is a trust relationship between the filer domain and the client domain. Otherwise, migration and/or recall archiving operations will fail.
After installing the File Archiver for Windows Agent and File Share Archiver Client (if applicable) before performing a migration archiving operation of data residing on a NAS file server, you must configure the authentication credentials with administrator privileges to access the file server. For more information, see Configure Filer/Proxy Authentication Credentials.
When configured for NAS archiving, if you perform a migration archiving operation on files added from a Unix share (NFS share), the file names for these files will become corrupted if the file names either include any characters not supported in Windows (including *, ?, “, <,>, |, /, \, or :) or contain more than the maximum number of characters allowed by Windows (255 characters). Files with the same name, but different case, will have migration and/or recall failures. Therefore, after a recovery operation, please carefully examine files if any of the files have been added from a Unix share (NFS share).

Stubs (Recovery, Icons, Recall Failures, Etc.)

Due to limitations inherent in certain file systems, some of the stub icons may not be displayed in Windows Explorer for some of the files after archiving. Refer to File Archiver for Windows Stub Icons for more information.
When a mount point contains stubbed files and it is moved, a reboot is required in order to recall the stubs.

For all instance types, the stubs will not be deleted upon the next On Demand archive using the same directive file in the following scenarios:
- Archived job is pruned
- Archived data is aged and then pruned
- Stubs are aged
To avoid stub recall failures, ensure that your anti-virus software is configured to allow the GXHSM Recaller service and associated driver(s) to function properly without being blocked. For more information, refer to KB article 11369 on the Maintenance Advantage website. This KB provides details for the individual AV Enterprise level Vendors: McAfee^®, Symantec^®, Trend Micro^®, and eTrust^®.
If the stub cache is enabled, and if a stub file is recalled and the ACLs on the file are then modified, the changes to the ACLs are not picked up during the next migration archiving operation unless the file itself is modified. This is true because when a stub file is recalled under this scenario, a copy is put in the stub cache, and the file is copied back from the stub cache during the next migration archiving operation. The agent looks at the modified file time to determine if the file data has changed, and ACLs are not tracked by the modified file time when the stub cache is being used. As a workaround, modify the data in the file itself to pick up the changes made to its ACLs.
Restub logic should be disabled to allow for proper recall in case the Trend Micro AntiVirus is installed on the machine where File Archiver Agent is installed.
The Stubcopy tool may not work with Trend Micro AntiVirus installed on the machine where File Archiver Agent is installed. As a workaround, the File Archiver Services should be stopped while running the Stubcopy tool and must be restarted after running the tool.

Registry Keys for Migration Archiving

Use the following registry keys to modify the default behavior of the Migration Archiver Agent:

Topic

Registry Key(s)

Description

Access and Modified Times

GXHSMSERVICEKEEPTIMES

GXHSMSTUBKEEPTIMES

Migration archiving and stub recovery operations change the access and modified time on files. An enhancement that allows the recovery administrator to preserve the original file access time and modified time during migration archiving and stub recovery. See Registry Keys (GXHSMSERVICEKEEPTIMES and GXHSMSTUBKEEPTIMES) for more information on enabling this feature for all instance types except Celerra.

GXHSMSERVICEKEEPTIMES

GXHSMSTUBKEEPTIMES

Stub pruning looks at the modified time of the file to determine eligibility for pruning stubs. If you use the GXHSMSERVICEKEEPTIMES and GXHSMSTUBKEEPTIMES registry keys, the modified time will be preserved. This means that when you run a migration with these registry keys enabled, the preserved modified time will always be older than the time that the file was stubbed. As such, if you use the Prune stub only after n days option, you should ensure that the modified time is not being preserved. Therefore, be sure to disable the GXHSMSERVICEKEEPTIMES and GXHSMSTUBKEEPTIMES registry keys (which are enabled by default) when you use this option.

GXHSM_PRESERVE_ACCESSTIME_ONMIGRTNS

GXHSM_PRESERVE_ACCESSTIME_ONRECALLS

The access and modified times on files during migrations and recalls are preserved by default. You can stop preserving these times by using the GXHSM_PRESERVE_ACCESSTIME_ONMIGRTNS and GXHSM_PRESERVE_ACCESSTIME_ONRECALLS registry keys.

Access Control Lists (ACLs)

GXHSMSERVICERESTOREACLS

You can determine how to handle ACLs on a stub with regard to migration archiving. You can choose either to replace the original ACLs on the stub after migration archiving or to preserve the original ACLs on the stub. See GXHSMSERVICERESTOREACLS in Registry Keys for more information.

Hidden and System Files

GXHSMIFINDDISABLEHIDDEN

GXHSMSTUBPERSERVEREADONLY

If you want to enable the scanning and archiving of hidden and system files, you can set the value of the GXHSMIFINDDISABLEHIDDEN registry key to N for this purpose. Although scanning and archiving of read-only files is supported without the use of a registry key, if you want to enable stubbing and recall capabilities for read-only files, then the value of the GXHSMSTUBPERSERVEREADONLY registry key must be set to Y.

Log Files

GXHSMSTUBLOGFAILFILESTRUNCATE

You can determine whether the existing log file associated with your job should be truncated or appended to. See GXHSMSTUBLOGFAILFILESTRUNCATE in Registry Keys for more information.

Re-Stubbing

GXHSMMAINTAINSTUBCACHE

In order to speed up migration archiving operations, the software will or can attempt to re-stub files under the following conditions:

The file must have been previously archived and then recalled by a non-browse recovery (i.e., stub recovery).
The stub for this file must exist in the "stub cache directory".
The Archive index must still exist in the system (i.e., was not removed by a data aging operation).
The file must not have been modified after it had been recalled.

In this case, during migration archiving, the system will simply swap the file for the stub in the stub cache, thereby speeding up the operation by not transferring or storing it again. This feature is enabled by default; however, it can be disabled by setting the GXHSMMAINTAINSTUBCACHE registry key value to N.

Stubs as Sparse Files

GXHSMSTUBCREATESPARSE

Stub files are created as sparse files by default so that the file system can utilize space more efficiently. However, if you would like to configure the system to create stub files that are not sparse files, then the value of the the GXHSMSTUBCREATESPARSE registry key must be set to N.

GXHSMIGNORESPARSE

You can determine how to handle file migration archiving with regard to the sparse attribute. You can choose either to ignore the sparse attribute when archiving files or to archive only files without the sparse attribute set. See GXHSMIGNORESPARSE in Registry Keys for more information.

However, if you have drives that are being monitored by VERITAS Storage Exec, ensure that GXHSMIGNORESPARSE is enabled to ensure that subsequent migration archiving jobs complete successfully and not just the initial migration archiving job.

Stub Port Number

EVMGRC_REMOTE_PORT_OVERRIDE

EVMGRC_REMOTE_PORT

You can override the stub file port number by using the EVMGRC_REMOTE_PORT_OVERRIDE registry key. Use this key when the port number changes. Keep in mind that using this key defeats the benefit of being able to recall data using different port numbers for multiple Agents. When the key does not exist, the File Share Archiver client uses the stub content to determine port number. For 7.0 stubs, refer to the EVMGRC_REMOTE_PORT registry key.

Stub Pruning

GXHSMSTUBKEEPTIMES

Stub pruning is unaffected by the status of GXHSMSTUBKEEPTIMES as the system takes the modification time from the stub content.

Delayed Stubbing

GXHSM_Delay_Stub_Enable

Delayed stubbing is a process that can be enabled by creating GXHSM_Delay_Stub_Enable key on the computer where the agent is installed. It helps in optimizing the stubbing and the backup process, particularly resuming the backup phase.