Skip to main content


 

 

How can we help you?

 

Druva Documentation

About restoring files and folders

Heads up!

We've transitioned to a new documentation portal to serve you better. Access the latest content by clicking here.

Enterprise Workloads Editions: File:/tick.png Business File:/cross.png Enterprise File:/tick.png Elite

 

This topic describes the following sections:

Restore workflow on the same File server

restore_workflow_same.png 

Restore workflow on a new File server

restore_workflow_new.png

Steps to restore File server

Step Operation

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 serverRestore the File server to a different server.

What you must know about File server restore

Points that you should know 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 Druva 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 and MS-SQL server backup set simultaneously. 
    • 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:

OlderClients.PNG

  • 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.PNG icon.