Restore Azure Data Lake Storage data to its original storage account when you want to recover deleted, corrupted, or incorrectly modified files without changing their destination. An original-location restore sends the selected data back to the source storage account and preserves its directory structure.
When should you restore to the original location?
Use this restore option when the original storage account remains available and the recovered data must return to its previous location.
Typical scenarios include:
Accidental deletion: A user, application, or automated process deletes a file or folder that is still required.
Unintended modification: An application overwrites valid data with incorrect or incomplete content.
Application recovery: An application expects data at its original path and cannot be easily redirected to another storage account or filesystem.
Limited recovery from an operational error: Only a specific set of files must be recovered instead of restoring the complete storage account.
Recovery from logical corruption: The storage account is accessible, but some backed-up files contain unwanted changes in the current production environment.
Do not use an original-location restore when:
You need to test recovered data in isolation
You must preserve the current production copy for comparison
You need to restore into a different storage account or cross-tenant (use alternate-location restore instead)
Before you begin
Ensure that:
The Azure Data Lake Storage backup set has at least one usable recovery point.
You know which files, directories, or filesystems must be recovered.
You have determined whether existing files at the destination can be overwritten.
You understand the Azure access-tier implications of the restore.
đ Note
If you select a directory, Druva restores the initial version of that directory rather than its latest or a specifically selected version.
Procedure
Log in to the Enterprise Workloads Management Console.
From the top menu, select the Organization.
Select Protect > Go to Azure > All Subscriptions. Select your subscription.
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 recover and click Restore.
Browse or search the available recovery points and select the required files or directories.
Search tip: Use filename, path prefix, file extension, file size, or date modified filters to locate specific files
Example: Search for sales-q4-2025.csv to find a specific deleted file
On the Restore Location tab, select Restore to original 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 Advanced Settings.
Configure overwrite behavior
Select one of the following options to determine what happens when a file with the same name already exists at the destination.
Option | Behavior | When to consider it |
Always overwrite | Replaces an existing destination file with the restored copy. | Use when the current copy is known to be corrupted or incorrect. |
Overwrite, if the original is older | Replaces the destination file only when its modification time is older than that of the restored file. | Use cautiously when modification time is an appropriate measure of which copy should be retained. |
Always skip | Leaves existing files unchanged and restores only files that do not already exist. | Use when recovering deleted data without replacing surviving production objects. |
â ď¸ Caution
Always overwrite can replace valid current data with an older backed-up version. Confirm the selected recovery point and affected objects before starting the restore.
Configure the directory structure
Maintain source folder hierarchy is enabled by default to retain the source directory structure and associated filesystem properties.
If you do not maintain the hierarchy, Druva restores the selected files at the root of the filesystem, which can create naming conflicts or cause existing data to be overwritten depending on the selected overwrite rule.
đ Note
If this option is not selected, files are restored to the root level of the destination, which may cause data to be overwritten.
Configure the access tier
Restore all objects to Hot tier is enabled by default. When enabled, Druva restores all selected objects to the Hot tier even if their source tier was Cool or Cold.
Clear this option if the objects must be restored to their original access tiers.
đ Notes
Clearing this option restores data to its original access tier.
Restoring objects to Cool or Cold tiers will incur Azure retrieval and read/write charges. Learn more.
Start the restore
Review the destination and advanced settings, then select Finish to start the restore job.
Monitor the job progress in the Jobs tab. You can view:
Restore job status and progress percentage
Number of files completed vs. total files
Failed objects (if any) with error details
Estimated time to completion
Best Practices for In-Place Recovery
Use "Always skip" for deleted file recovery: Prevents overwriting live production files modified since the last backup point.
Maintain folder hierarchy: Prevents file collisions and root container data overwrites.
Match target access tiers: Clear Restore all objects to Hot tier when recovering cold data to avoid unexpected re-hydration charges.
Quiesce active pipelines: Pause ingestion jobs to target paths to prevent write race conditions, silent file overwrites, or broken analytics runs.
Verify post-restore POSIX ACLs: Confirm restored file ownership (UID/GID) matches current user permissions.