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.

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

1. 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.

2. From the navigation pane, click Workflows.

3. Right-click the Cloud Storage Archive Recall workflow and then click All Tasks > Execute.

   The Cloud Storage Archive Recall dialog box will be displayed.

4. 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.

5. In the Backup JobId box, type the job ID that was noted down in step 1.

6. 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.)

7. 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.

8. Disable the Auto-archive recalled files on restore job completion option if you are restoring from Microsoft Azure.

9. Enable the Recall only index files option.

10. 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.

11. 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.

What to Do Next

For Azure Archive Storage, modify the Auto-archive recalled files on restore job completion option.

When data is recalled from Microsoft Azure Storage, it will be recalled from archive to hot storage class. Data will be copied from the Archive tier to the Hot tier under the cvshadowcopy-do-not-use-or-delete container, and the original data will be still present on the Archive tier.

• If you execute the workflow with restore job as input, data will be moved back to archive automatically once the restore job completes.

• If you execute the workflow with backup job as input, execute the workflow again and select the Move back data from Hot to Archive option when prompted. Data will be deleted from the cvshadowcopy-do-not-use-or-delete container.

Once the Cloud Storage Recall Workflow job is complete, perform the Browse and Restore operation. Note that the Browse operation may take a few minutes to build the index. Once the contents of the Browse is displayed, you can select the required data and initiate the restore operation.