Restore Azure Data Lake Storage data to an alternate location when the recovered data must be written to a different Azure subscription, storage account, filesystem, or tenant instead of its original destination. Alternate-location restore is useful when you need isolation, comparison, testing, migration support, or recovery outside the affected source environment.
When should you restore to an alternate location?
Use this option when restoring into the original storage account could disrupt production data or does not meet the recovery objective.
Typical scenarios include:
Isolated recovery for validation and forensic investigation: Restore backed-up data to a separate location to investigate data loss, corruption, ransomware, or suspicious activity; validate recovered data safely before replacing production data.
Testing and development: Restore to a test environment to verify data before pushing to production or to test database migrations and application upgrades.
Data migration: Restore data from one storage account to another for consolidation, account upgrade, or regional migration.
Cross-subscription recovery: Restore within your Azure tenant to a different subscription.
Cross-tenant recovery: Restore to an isolated recovery tenant after a malware attack or security incident compromises the production tenant.
Do not use an alternate-location restore when:
Recovering deleted files that need to return to their original location
The original storage account must remain unchanged for comparison
Before you begin
Ensure that:
The backup set has a usable recovery point.
The alternate Azure subscription is associated with the tenant and available for selection in Druva (for same-tenant restore) or accessible via cross-tenant trust (for cross-tenant restore).
A suitable destination storage account exists or can be created.
You have decided whether to restore to an existing filesystem or create a new one.
You have decided whether the source hierarchy and original access tiers must be preserved.
You have evaluated the possibility of naming conflicts at the destination.
Procedure
Log in to the Enterprise Workloads Management Console.
From the top menu, select the Organization.
Select Storage Accounts(Blobs)> Backup Sets. Ensure that the backup set displays the ADLS icon next to its name.
Select the backup set containing the data you want to restore and click Restore.
Browse or search the available recovery points and select the files or directories you want to restore.
On the Restore Location tab, select Restore to alternate location and click Next.When selecting target storage accounts during an Original Location or Alternate Location restore, verify that the target storage account displays the ADLS icon next to its name in the selection list or pre-filled location summary. Selecting an account with the ADLS icon confirms that the target is HNS-enabled, preventing cross-protocol restore failures (such as attempting to restore ADLS data to a standard flat-namespace Blob account).
Configure the alternate destination.
Provide the following information:
Subscription: Select a subscription associated with your Azure tenant (same-tenant) or recovery tenant (cross-tenant).
Storage Account: Select the destination storage account.
Region: Druva automatically displays the region of the selected storage account.
Filesystem (Container): Select an existing filesystem or create a new one by entering its name. This field is optional.
š Notes
āIf no filesystem is selected, data is restored to the root of the storage account.
āWhen creating a new filesystem through the restore workflow, standard Azure naming rules apply.
Click Next to proceed.
Configure overwrite behavior
Choose how Druva handles files that already exist at the alternate destination.
Option | Behavior | When to consider it |
Always overwrite | Replaces existing destination files. | Use when the alternate destination is disposable or its existing copies are known to be obsolete. |
Overwrite, if the original is older | Replaces a destination file when its modification time is older than that of the restored file. | Use when the destination contains earlier copies and timestamp comparison is appropriate. |
Always skip | Preserves existing destination files and restores only missing files. | Use when the destination contains data that must not be replaced. |
š” Recommendation
A new, empty filesystem generally reduces the risk of unintentionally overwriting unrelated destination data.
Configure the directory structure
Select Maintain source folder hierarchy when the source directory structure and filesystem properties must be retained.
If you do not select this option, Druva restores the files at the root of the destination filesystem. Flattening the hierarchy can create naming conflicts and may cause existing destination data to be overwritten.
ā ļø Caution
Do not clear this option merely to simplify the restored structure unless you have checked for duplicate filenames across the selected source directories.
Configure the access tier
Restore all objects to Hot tier is enabled by default. When enabled, objects are restored to the Hot tier even if their source tier was Cool or Cold.
Clear this option to restore objects to their original access tiers.
š Notes
Clearing this option restores data to its original access tier.
Restoring objects to Cool or Cold tiers can incur Azure retrieval and read/write charges. Learn more.
Configure access permissions
Use the Restore Access Control Lists (ACLs) option to determine how permissions are handled during the restore process.
Select the checkbox to restore the original source access permissions for the selected files and directories.
Note: This restores only the file and directory ACLs. It does not restore Azure role-based access control (RBAC) assignments.
Clear the checkbox to restore the files and directories without their original ACLs. The restored data will inherit the permissions of the destination location.
Recommendation: Clear this option if you are restoring data to a different tenant.
ā ļø Caution: Do not clear this option if the restored data must retain its original user and group permissions. Clearing it may result in users gaining unauthorized access or losing required access at the destination.
Start the restore
Review the selected subscription, storage account, filesystem, hierarchy, tier, and overwrite settings.
Best Practices for Alternate-Location Restore
To ensure successful alternate-location restores and minimize operational risks, we recommend the following practices:
Test restores monthly on a test account to validate backup quality before a production incident occurs.
Use a new, empty filesystem to reduce the risk of unintentionally overwriting existing data.
Restore representative samples first to validate backup integrity before committing to a full-scale restore.
Maintain the source hierarchy to preserve the original file structure for easier navigation and administration.
Schedule large restores during off-hours to minimize the performance impact on your production workloads.
Document identity mappings for cross-tenant restores to simplify the manual reapplication of Access Control Lists (ACLs) at the destination.
Verify the restored content to confirm data integrity after the restore operation completes.