Topics | How To | Troubleshoot | Related Topics
Unconditional Overwrite Recovery Options
Recover a File from a NetWare System Console
Recover a File from a Unix Terminal Window
Recover a File from Windows Explorer
Recovering Multiple Files from Stubs
Recover Data Through NFS Clients
Recovery Considerations for these Agents
The File Archiver and File Share 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 and File Share 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, NAS device and/or operating system of the client computer full system restores may be required. The File Archiver and File Share 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 File Archiver Agents offer two recovery options for performing an unconditional overwrite of a file or stub upon recovery from the CommCell Console. These options are available in the Recovery Options dialog box in the CommCell Console and their descriptions are provided below.
Unconditional Overwrite
When this option is selected, the system will recover the data and unconditionally overwrite any data object, such as files/folders/directories, whose names are the same as those in the recovery path.
When this option is not selected, the system will not unconditionally overwrite data but will follow these rules instead:
The Unconditional Overwrite option is also supported by the File Share Archiver Agent.
Unconditionally overwrite only if target is a DataArchiver stub
When this option is selected, the system will only overwrite stub files and will not overwrite other files with the same name. This feature is useful for avoiding the overwriting of a file with the same name that was previously recalled or which may be a more recent version than the file being recovered. Note that this option is currently unavailable for the File Share Archiver Agent.
The File Archiver for NetWare 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 non-browse recovery from a NetWare System Console. A non-browse recovery is any action that causes an open and read to be executed for the archived file, which automatically initiates a recovery operation. One such example includes entering the EDIT command from the NetWare System Console.
For step-by-step instructions, see Recover a File from the NetWare System Console.
NOTES
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.
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 non-browse recovery from a Unix workstation. A non-browse recovery 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.
NOTES
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.
The File Archiver for Windows/NetWare Agents and the File Share Archiver Agent provide several common methods for recovering an archived file. Users can provide a path to the archived files to be recovered from the CommCell Console, browse and recover archived files from the CommCell Console or, if the subclient is configured to create stubs, perform a non-browse recovery from a Windows workstation. A non-browse recovery is any action that causes an open and read to be executed for the archived file, which automatically initiates a recovery operation. For example, clicking on the stub file from Windows Explorer.
For step-by-step instructions, see Recover a File from Windows Explorer.
NOTES
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.
The File Archiver and File Share Archiver Agents provide the capability to recover more than one archived file at a time from stubs via a third-party application (e.g., Windows Explorer, Unix Terminal 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 Multiple Files from Windows Explorer.
NOTES
You can use the nDMRSendFileStatus registry key to reduce the frequency at which File Archiver for Windows/Unix stub recovery job statistics are sent to Job Manager for updating the Recovery Job History views and reports. This is useful for increasing the efficiency of system resources in cases where there are frequent stub recalls and there is no need to update the Job History immediately after each stub recall.
When a file is archived using the File Archiver for Windows Agent with the create stub option enabled, the icon for the file will change to a special stub icon in Windows Explorer so that you can easily distinguish archived files. Depicted below are examples of commonly used stub icons.
|
|
Adobe Acrobat Document |
|
|
JPG File |
|
|
Microsoft Excel Worksheet |
|
|
Microsoft Project Document |
|
|
Microsoft Word Document |
|
|
MP3 File |
|
|
Text File |
| no image | Due to limitations inherent in certain file types, including but not limited to *.html and *.ttf files, no icons will be displayed in Windows Explorer for those files after archiving. This is normal for some files, and the stubs can still be recovered by clicking on the filename from Windows Explorer. |
After a stub has been recovered, the icon will change back to the normal icon for the respective file type. Keep in mind that the File Archiver for Unix Agent and the File Share Archiver Agent do not support stub icons.
DataArchiver provides a valuable recovery tool for administrators to limit the number of stub recovery requests that can be run on an agent 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 can be entered on the agent properties for the File Archiver for Windows/NetWare/Unix Agents, and can be configured in the registry for the File Share Archiver Agent.
See Set Stub Recovery Parameters for step-by-step instructions (File Archiver for Windows/NetWare/Unix Agents); or see Registry Keys (File Share Archiver Agent).
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 Windows: Assuming they were text files, 11 blank Notepad sessions appear on the desktop.
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
File Achiver for NetWare and File Share Archiver: Assuming they were text files, 11 Notepad sessions appear on the desktop with each containing a message indicating that this is a stub file.
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.
NOTES:
The Application Filtering feature for File Archiver for Windows provides a means for the recovery administrator to prevent specified applications from initiating recalls of archived files. Certain applications will perform an open and read on files as part of their normal functioning, such as virus scanning software, but when a stub is opened and read the system initiates a recall (i.e., stub recovery) that in such cases would be an unintended consequence of running the application. To prevent this from happening, the recovery administrator can add a registry key on the client computer that contains the name of the executable that is denied recall rights when accessing files of that application type. Once the registry key has been set up, if a user attempts stub recovery for a archived file associated with the application type specified in the registry key, the recall will be denied and an event will be issued in the CommCell Console's Event Viewer and the Windows Event Viewer indicating that the recall was denied due to application filtering. See NoRecallPrivileges for more information on the use of this registry key.
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 archive and 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, the File Archiver Agents and the File Share Archiver Agent recover data 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 section enumerates the types of recovery destinations that are supported by the File Archiver and File Share Archiver Agents. See Recover Options - Recover Destinations - Support for a list of Agents supporting each restore/recovery destination type.
When performing a non-browse recovery 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.
Consider the following when performing out-of-place recoveries:
When using the File Archiver for Windows agent to perform a cross-platform recovery of archived data from a newer version of Windows to an older version of Windows, keep in mind that some file attributes/properties native to the newer version of Windows may not be recovered to the older version.
Besides recovering data to a client computer’s local drive, you can also recover data to a UNC path (Windows) or NFS-mounted file system (Unix) depending on your agent. (See Restore to Network Drive/NFS-Mounted File System for comprehensive information.)
Consider the following when recovering archived data:
Before performing any recovery procedures for these agents, review the following information.
Common Considerations
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.
File Archiver for NetWare Agent
File Share Archiver Agent
File Archiver for Unix Agents
File Archiver for Windows Agents
Net Send Requirements:
The successful delivery of the pop-up message for stub recoveries initiated on a remote workstation that has mapped drive to the client is reliant on the Windows Messenger Service and the Net Send command to provide a broadcast message to the appropriate remote user. Therefore, certain Net Send requirements must be met in order for the pop-up message to be successfully delivered to the target user, including:
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.