Migration Archiving - File Archiver for Unix Agent

How to Setup and Run a Migration Archive Operation

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

Overview

Migration Archiving of data allows preservation, transparent retrieval, and discovery of information held within file system environment. 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 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.

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.
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 Unix Terminal Window.)
- 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.

These stubs are normally included in full backup operations by the Unix file system iDataAgent.

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.

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.
Set the ifindUseMTime registry key value to N in the properties file on the client computer. See Registry Keys for more information on the use of this key.

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.

General

Files whose size is less than or equal to the file system block size will not get migrated (i.e., they will remain in place). Therefore, be sure that the size of these files is greater than the file system block size.
Migration archiving operations with OES Linux data does not retain OES' extended attribute information. Thus, the extended attribute information cannot be recovered.

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

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.
dbStublist.cvf is created during archiving, which contains a list of all the files that needs to be stubbed. The default behavior is that the files are stubbed as soon as they are archived. This stubbing process can be delayed by creating nGXHSM_DELAY_STUB_ENABLE wherein dbStublist.cvf will be created just prior to the start of the stubbing phase.
Use sHLINK to avoid stubbing multiple copies a hard link.