(The displayed item is a product of Microsoft and beyond the control of this agent.)
Topics | How To | Troubleshoot | Related Topics
| This feature/product/platform is deprecated in this release. See Deprecated Features, Products, and Platforms for more information. |
How to Set Up and Run a Recovery Option
Recover a File from a NetWare System Console
Recover a File from Windows Explorer
Recovering Multiple Files from Stubs
Recovery Considerations for NetWare 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 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 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 recall operation from a NetWare System Console. A recall 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.
|
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. |
There are 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 recall operation from a Windows 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. For example, clicking on the stub file from Windows Explorer.
|
For step-by-step instructions, see Recover a File from Windows Explorer.
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 disk 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 disk 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.
When a file is archived with the create stub option enabled, offline attributes are set and the icon for the file will change to a special stub icon in Windows Explorer so that you can easily distinguish archived files. Some examples of commonly used stub icons are below:
|
|
Adobe Acrobat Document |
|
|
JPG File |
|
|
Microsoft Excel Worksheet |
|
|
Microsoft Project Document |
|
|
Microsoft Word Document |
|
|
MP3 File |
|
|
Text File |
|
|
Text File (Windows 2008 or Windows Vista) (The displayed item is a product of Microsoft and beyond the control of this agent.) |
| 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 does not support stub icons.
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 Achiver for NetWare: 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.
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 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:
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.