Recalling Index Data from Archive Cloud Storage On-Demand

Run the Cloud Storage Archive Recall workflow manually to recall the index data from a copy available in the archive cloud storage.

By default, if a restore operation from archive cloud storage fails at index phase, the software automatically recalls the index using the Cloud Storage Archive Recall workflow and resumes the restore operation.

The recall is performed by requesting the relevant index data from the copy in an existing archive cloud library, when all the MediaAgents associated with the primary copy are offline and as a result the index cannot be restored from the primary copy.

This applies to the following cloud storage data:

Backup data stored in archive tiers, such as Glacier.
Backup data stored in combined storage tiers prior to Feature Release 11.23.

Combined storage tier cloud libraries will receive indexes faster from warm tier. Direct to Cloud Archive Storage recalls will incur the archival recall delay, based on the cloud storage service being used.

Note

From Feature Release 11.23 onwards, for combined storage tiers, index data is stored in the warmer tiers. As a result separate index recalls are not required as the data is readily accessible from the warmer tiers.

Prior to Feature Release 11.23, use the CloudTestTool to recall the metadata and the .idx file permanently to the standard tier. To move existing data, see Permanently Moving Data From One Cloud Storage Tier To Another. You can also change the Storage Class from Archive to Combined Tier for future backups. For more information, see Modifying the Storage Class for an Existing Cloud Library.

To recall the index data, the MediaAgent associated with the Cloud Archive Storage libraries must have the same Service Pack level as the CommServe server. For more information on viewing the version information, see Viewing the Service Pack Details for One or More Clients.

Before You Begin

Make sure that the MediaAgent associated with the Cloud Archive Storage libraries have the same Service Pack level as the CommServe server. For more information on viewing the version information, see Viewing the Service Pack Details for One or More Clients.
Install the Workflow Engine on a Windows server, and then deploy the Cloud Storage Archive Recall workflow on the server. The workflow is not supported if the Workflow Engine is hosted on Linux operating system. For more information on deploying the workflow, see Deploying a Workflow.
- This workflow is included in the Commvault software and will be listed under the Workflows node in the CommCell Browser.
- Ensure that the workflow is deployed by an user with the necessary permissions needed to deploy and execute a workflow. For more information on user permissions, see User Security Permissions - Workflow.
- If the workflow is already deployed, verify that the latest version of the workflow is deployed. For more information on the workflow version, see Viewing Workflow Version History.
  
  If the workflow is an older version, re-deploy the workflow. For more information on deploying a workflow, see Deploying a Workflow.
If the Index Server is on a different host, make sure that the MediaAgent associated with the Index Server has access to the Cloud Storage library. For more information about adding the Index Server MediaAgent to an existing cloud storage library, see Adding a MediaAgent to an Existing Cloud Storage.

Procedure

Start a job-based Browse and Restore operation from the Backup Job History window. For more information on starting a job-based browse operation, see Viewing Backup Job History.

If the Browse operation fails, note down the Backup Job ID and then perform the following steps to recall the index data needed for browse.
From the CommCell Browser, go to Workflows.
Right-click the Cloud Storage Archive Recall workflow and then click All Tasks > Execute.

The Cloud Storage Archive Recall dialog box will be displayed.
From the Run workflow on list, select the engine to use to execute the workflow and then provide values for the workflow inputs.

If you select Any, the workflow engine with the latest deployed version of the workflow is used.
In the Backup JobId box, type the job ID that was noted down in step 1.
Optionally, from the Recall Monitoring Interval list, select the monitoring frequency from the list. (For the Default option, the workflow uses an appropriate value based on the storage vendor and storage class.)
Optionally, modify the following options for different storage vendors:

For Amazon S3 Glacier, Deep Archive, and Combined Tier Storage Class:
- Retention Days: No. of days to keep the recalled data in Amazon S3 after the recall.
  
  This option applies to Glacier, Deep Archive, and Combined Tier storage class only.
  
  Note
  
  Amazon S3 Direct Glacier does not honor the Retention Days option. The recalled data will be available for 24 hours, after which it will be moved back to the respective storage class. For more information about the move back option, see https://docs.aws.amazon.com/amazonglacier/latest/dev/downloading-an-archive-two-steps.html.
- Retrieval option: The recall mode that must be used to recall data. Default is set to 0, which is Standard mode. Valid values are:
  
  0 - Standard
  
  1 - Expedited
  
  2 - Bulk
  
  Expedited mode will incur additional costs. If the Expedited mode is selected, the re-hydration request will be prioritized over the Standard requests, and may finish in under 1 hour. Also note that Expedited mode requires provisioned capacity as described in https://docs.aws.amazon.com/amazonglacier/latest/dev/downloading-an-archive-two-steps.html#api-downloading-an-archive-two-steps-retrieval-expedited-capacity.
  
  Note
  
  Deep Archive does not support the Expedited recall mode.
  
  For more information about the recall modes, see http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPOSTrestore.html.
  
  For Azure Archive Storage:
- Retrieval option: The recall mode that must be used to recall data. Default is set to Standard Priority. Valid values are:
  
  Standard Priority
  
  High Priority
  
  Note
  
  If High Priority is selected, the re-hydration request will be prioritized over the Standard requests, and may finish in under 1 hour.
  
  For more information about the recall options, see https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blob-rehydration.
Disable the Auto-archive recalled files on restore job completion option if you are restoring from Microsoft Azure.
Enable the Recall only index files option.
Click OK.

The Note dialog box will be displayed with information on the Total Files to be recalled and the list of MediaAgents used for performing the recall.
Click Yes to continue.

If required, click the Change MediaAgent button to select the MediaAgent from which the recall must be initiated.

A Cloud Storage Recall Workflow job will be started and displayed in the Job Controller window. The job will complete once all the required index files are recalled.

Note

Job may not complete if there is a service restart on the CommServe computer. Make sure to re-submit the job if there is a service restart.

The recall process may take some time, depending on the Archive Cloud Storage platform from which the recall is initiated. For example, Amazon S3 may take 8+ hours, Microsoft Azure 12+ hours, etc. Wait for the requisite number of hours and then restart the Browse and Restore operation.