Steps to restore File server
Step 1: You or another administrator initiates a restore operation.You can restore the data at the original location or an alternate location. The alternate location can be the same server and different path or different server and different path. You can select the destination server where restore can happen for the selected File server recovery point. For example, Windows server for Windows restore and Linux server for Linux restore.
Step 2: Druva checks if Enterprise Workloads agent is running.
If the agent is running, Druva performs the restore operation.
If the agent is not running, Druva queues the restore request and performs the restore operation after Enterprise Workloads agent starts
Step 3: Druva validates the restore destination.
Step 4: Druva checks the free space available at the restore destination.
Step 5: Druva identifies the file sets for restore.
Step 6: Druva starts the restore operation and sequentially downloads the filesets to the restore destination.
📝 Note
For more information about restoring File servers, see Restore a File server to the same server, Restore the File server to a different server.
Expand to view the restore workflow on the same File server
Expand to view the restore workflow on the same File server
Expand to view the restore workflow on the new File server
Expand to view the restore workflow on the new File server
What you must know about File server restore
Expand to know more about the File server restore.
Expand to know more about the File server restore.
Hot Recovery point reside on CloudCache for a period that you have specified at the time of Configure CloudCache.
If you are a group administrator, you can only restore data to a server that belongs to an administrative group that you manage. Cloud administrators and data protection officers can restore data to servers across administrative groups.
You can only restore data to a server that has the same operating system as the source server.
In the event of a network connection failure at the time of restore, Enterprise Workloads agent attempts to connect to the Druva Cloud. After the network connection is restored, Enterprise Workloads agents restart the restoring from the state where they were interrupted.
If you restart or reboot your servers during a restore, the restore operation restarts.
If you choose to restore data to the same location, the existing data at that location is overwritten.
The recovery point timestamp and the file/ folder timestamp is according to the same time zone. The time zone setting in the registered agent/ proxy machine defines this value.
Long file and folder names are now visible in the Restore Data page. The Date Modified and Size information is visible on the next line.
Restores are not supported to the mapped drives.
For Windows, the following file attributes are supported:
Content Not indexed.
Read-only
These Access Control Lists (ACL's) are backed up and restored
Owner name
Create time (ctime) of a file in nanoseconds
Primary group that the owner of the file belongs to
System Access Control List (SACL)
Discretionary Access Control List (DACL)
For Linux,
File permissions for file owners, groups, and users are restored.
File attributes are not supported.
The following attributes are backed up and restored
Owner name
Modified time (mtime) in nanoseconds
The following special permissions for files and folders is not supported:
Sticky bit
Druva backs up the files and folders on the NTFS and REFS volumes. However, Druva does not support the back up of the extended attributes, such as encryption and compression, on REFS. Therefore, if the files and folders are backed up from an NTFS volume and restored on a ReFS volume, some of the advanced attributes may get lost.
From version 4.6.8 and later, Druva can back up and restore the empty folders. After the upgrade, the Windows File server agent where USN journal is enabled:
The empty folders created before the last backup and before the client upgrade will not be backed up. Contact Support to back up these empty folders.
The empty folders created after the last backup but before the client upgrade will be backed up.
The Windows File server agent where UNC share is configured for backup, empty folders in the UNC share, created before and after the upgrade will be backed up and restored.
After the Linux File server agent upgrade, the empty folders created before and after the upgrade will be backed up and restored.
Backup and restore can run simultaneously on the same agent.
For mixed workloads, you can trigger the restore for File server backup set.
If you trigger a restore request for a File server backup set while another restore is in progress for the same File server backup set, the triggered restore request is queued.
File server agents earlier than version 4.6.9 cannot run a backup and restore request simultaneously. If a restore request is triggered while a backup is in progress, the following message is displayed:
If you select the Cancel Backup and Start Restore option, the backup in progress is canceled and an error PHOENIX247 is displayed on the Jobs page. The triggered restore request is processed.
If you select the Start Restore After Backup is Finished option ,the triggered restore request is queued.
File server agents earlier than version 4.6.9, the backup request triggered while a restore is in progress is queued.
Full scan restores will be marked with the Fullscan icon.