Topics | How To | Related Topics
How to Set Up and Run a Recovery Option
Recover a File from a Unix Terminal Window
Recovering Multiple Files from Stubs
Recover Data Through NFS Clients
Recovery Considerations for Unix Agent
The File Archiver Agents support the following types of recoveries:
Recoveries can be performed in-place or out-of-place, and in certain scenarios cross-application recoveries and recoveries to a network drive or NFS-mounted file systems are also supported. (See Recovery Destinations below for comprehensive information.)
Recoveries using file paths for the File Archiver Agents can be performed from the archive set level in the CommCell Browser. Depending on the agent, browse and recovery operations for these agents can be performed from the client, agent, and subclient levels in the CommCell Browser.
When there is a problem with the file system, and/or operating system of the client computer full system restores may be required. The File Archiver Agents rely upon the corresponding File System iDataAgent to perform a full system restore of client data. See Disaster Recovery for more information.
The following section provides the steps to set up and run a Recovery Operation:
The File Archiver for Unix Agent provides several methods for recovering an archived file. Users can provide a path to the archived files to be recovered from the CommCell Console, perform a browse recovery for archived files from the CommCell Console or, if the subclient is configured to create stubs, perform a recall operation from a Unix workstation. A recall is any action that causes an open and read to be executed for the archived file, which automatically initiates a recovery operation. Two such examples include, but are not limited to, entering either the vi or cat commands from a Unix Terminal or Console window.
For step-by-step instructions, see Recover a File from a Unix Terminal Window.
|
If a subclient is configured with the Archive files only, do not create stub archiving rule option enabled, the archived files will be removed from the computer and a stub recovery is not possible. To recover files that were archived using this option, perform the procedure to Recover a File from the CommCell Console. |
More than one archived file can be recovered at a time from stubs via a third-party application (e.g., Windows Explorer, Unix Terminal or Console window).
Multiple stub recoveries from magnetic media or tape are submitted to the Job Controller as one job. For such stub recoveries, only one job (i.e., called a Persistent Recovery job) will display in the Job Controller. However, the Event Viewer and Job History log will treat the jobs as separate jobs (using the same Job ID associated with the common open pipeline). Also, the job will wait for approximately 5 seconds in order to allow other stub recovery requests being submitted on the same client to be batched into the same job. It is worth noting that stub recoveries from magnetic media are faster than tape, because the pipeline remains open for up to 20 minutes of idle time, allowing quicker recovery and avoiding the time needed to find and load tapes.
For step-by-step instructions, see Recover a File / Multiple Files from a Unix Terminal Window.
The number of stub recovery requests that can be run on an agent can be limited within a specified timeframe. Limits can be established that not only optimize performance but can also prevent the inadvertent recovery of a large number of files. Setting the recall throttling parameters involves configuring the maximum number of recalls, interval, and cool-down period for the agent. These parameters are entered on the Agent Properties dialog box.
See Set Stub Recovery Parameters for step-by-step instructions.
Examples are provided below to illustrate how this feature functions.
For the examples below, we will assume that the recovery administrator has established the following recall throttling parameters:
- Maximum Stub Recovery (i.e., limit) is set to 10
- Time Between Recall to Count as Successive in Seconds (i.e., interval) is set to 30 seconds
- Time to Wait after Maximum Successive Recalls Limit is Reached in Seconds
(i.e., cool-down) is set to 60 seconds
Action: A user submits 4 stub recovery requests at the same time on a given client, and no other stub recovery requests are submitted on that client during the 30 second interval that follows.
Result: As each stub recovery request is received, it will begin processing immediately and the 30 second interval countdown will begin where the system will wait to see if any more stub recovery requests are submitted. There is no cool-down period since the limit was not reached, and all 4 files will be recovered.
Action: A user submits 20 stub recovery requests at the same time on a given client, and no other stub recovery requests are submitted on that client during the 30 second interval that follows.
Result: The first 9 stub recoveries will begin immediately, the 30 second waiting interval does not apply here since the limit has been reached, and the 60 second cool-down period begins where no other stub recovery requests will be accepted. Note that 11 stub recovery requests (out of 20) that were over the limit will not be processed, and an event will be issued in the CommCell Console's Event Viewer and the Windows Event Viewer indicating that the limit has been reached. The first 9 files will be recovered, and depending on the agent the user will see one of the following results for the 11 stub recovery requests that were over the limit:
File Archiver for Unix: Assuming that cat filename was used to perform the read recovery from individual windows, the following error message will be displayed in each window where the recall failed: cat: input error on filename I/O error
Action: A user submits 4 stub recovery requests at the same time on a given client, and 4 other stub recovery requests are submitted on that client by another user during the 30 second interval that follows.
Result: As each stub recovery request is received from the user, it will begin processing immediately and the 30 second interval countdown will begin where the system will wait to see if any more stub recovery requests are submitted. After 20 seconds have elapsed, the 4 additional stub recovery requests are received so the 30 second interval countdown will begin again (i.e., the count is initialized to zero) to allow one more request to be submitted. Since the limit has not been reached, the cool-down period does not apply, and all 8 files will be recovered on a first-in first-out basis.
Action: A user submits 4 stub recovery requests at the same time on a given client, and 8 additional stub recovery requests are submitted on that client by another user 35 seconds later.
Result: As each stub recovery request is received from the user, it will begin processing immediately and the 30 second interval countdown will begin where the system will wait to see if any more stub recovery requests are submitted. After 35 seconds have elapsed, 8 additional stub recovery requests are received and the 30 second interval countdown will begin again (i.e., the count is initialized to zero) to allow one more request to be submitted. Since the limit was never reached during the first or second interval, the cool-down period does not apply, and all 12 files will be recovered on a first-in first-out basis.
NFS sharing of archived data is not available on Red Hat Linux AS 3.0. NFS sharing of archived data on SuSE 9.0 Enterprise Server (with Service Pack 2) can be accomplished using the standard Linux utilities. The remainder of this section pertains only to File Archiver for Unix on Solaris platforms.
File Archiver for Unix supports the ability to recover data from Network File System (NFS) mount points, through the use of CXFS (which is a special file system type for File Archiver on Unix) and the "cxfstab" file. Once you have configured a subclient and run a migration archiving operation, the directories and mount points specified in the subclient content become CXFS partitions or mount points. Like any other locally mounted file system, CXFS must be explicitly exported in order to become available to remote NFS clients.
This section pertains only to File Archiver for Unix on Solaris platforms.
In order to allow recovery from remote NFS clients, two operations need to be performed:
share [-F fstype] [-o options] [-d "<text>"] <pathname>where:
-F File system type. In this case it will be nfs. -o Options. Examples: ro (read only), or rw (read/write). -d Description. For Example: -d "CXFS share". <pathname> Path to share. It will be exactly as listed in the File Archiver for Unix Subclient Properties (Content) tab.
A simple example CXFS entry is provided below. If the installation directory is /opt, the cxfstab file should be created in the /opt/FSDM directory. Assuming that the Subclient Properties (Content) tab has one entry, "/export/home/engineer/docs", the entry in the /opt/FSDM/cxfstab file would appear as follows:
share -F nfs -o rw -d "description" /export/home/engineer/docs
This section pertains only to File Archiver for Unix on Solaris platforms.
Keep in mind the following considerations when using NFS mount points for migration archiving and recovery:
mount -o timeo=600 /cxfs_share /local_dir
By default, data is recovered to the client computer from which it originated; this is referred to as an in-place recovery. You can also recover the data to another Client computer in the CommCell. Keep in mind the following considerations when performing such recoveries:
The following sections enumerate the types of recovery destinations that are supported. See Recover Options - Recover Destinations - Support for a list of Agents supporting each restore/recovery destination type.
When performing a recall of archived data from a stub, keep in mind that the data can only be recovered in-place to the same path/destination on the same client from which the data was archived.
When performing an In-Place Recovery for Recovery-by-Job the user has to provide the login credentials for FPolicy and Network File Share Instance.
Consider the following when performing out-of-place recoveries:
When performing a cross-platform recovery of archived data from a newer version of an operating system to an older version, keep in mind that some file attributes/properties native to the newer version may not be recovered to the older version.
Consider the following when performing cross-platform recoveries:
Besides recovering data to a client computer’s local drive, you can also recover data to a NFS-mounted file system. (See Restore to Network Drive/NFS-Mounted File System for comprehensive information.)
Consider the following when recovering archived data:
If a stub has been moved to a new location, recall operations will recover the data to the new location and not the originating one.
Before performing any recovery procedures for these agents, review the following information.
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.
To change the default value of how long the persistent pipeline of this Archiver Agent will stay open during idle periods of a recovery operation, you can use the nDMRSIDLETIMEOUT registry key to accomplish this task. The pipeline stays persistent for 1200 seconds (20 minutes) by default.