Virtual machine restore types
If you have taken a VMware backup, you can restore:
Full virtual machine: Restores the entire VM.
Data restore: Restores VMDKs, files and folders
Druva provides you with the capability to restore files to CIFS/SMB share and any virtual machine in your vCenter/ESXi. Druva also supports file-level restore to the guest virtual machine in the VMC environment. Druva supports file-level restore to a CIFS/SMB share in the VMC environment. This CIFS/SMB share also could belong to a virtual machine and needs to be accessible from the backup proxy.Instant Restore: Instantly restores the virtual machines that are mapped to CloudCache (Linux version).
MS SQL Restore: Restores MS SQL databases from virtual machines where application-aware backup was done successfully.
Sandbox Restore: Recovers a specific recovery point followed by an antivirus scan in a sandbox environment.
Restore virtual machine workflow
The following diagram illustrates the restore workflow:
Click to view the workflow
Administrator initiates virtual machine restore. Druva forwards the restore request to the backup proxy pool.
Based on the load balancing algorithm, Druva automatically identifies the backup proxy that will fulfill the restore request.
If the identified backup proxy is busy, the restore request is queued and initiated when the backup proxy becomes free.
Druva performs a check to ensure that the restore location is not a Network-attached Storage (NAS).
In an environment where virtual machines are deployed on ESXi hosts managed by vCenter Server, backup proxy contacts vCenter server to locate the virtual machine.
In an environment where virtual machines are deployed on standalone ESXi hosts, backup proxy contacts ESXi host and locate the virtual machine.
VDDK connection is established with the virtual machine with SSL transport mode.
Backup proxy checks if it is a full virtual machine restore or a VMDK file restore. Backup proxy contacts the virtual machine and establishes a write connection to restore virtual machine data.
For a full virtual machine restore:
Druva deletes the virtual disks (VMDKs) of the existing virtual machine
Druva creates a new virtual machine with an identical configuration (that is, the configuration of the virtual machine at the time of backup)
📝 Note
If new virtual disks (VMDKs) are present during the current restore operation but were not present during the backup operation, Druva detaches these virtual disks (VMDKs).Druva restores the virtual disks (VMDKs) of the virtual machine
Druva does not change the name or any other configuration of the virtual machine
📝 Note
For disk restore, create a minimum configuration virtual machine because VMware does not allow to create a disk without creating the virtual machine.
For a disk restore, Druva creates a new virtual machine with minimum configuration (100 MB RAM, 1 CPU, 1 video card, and the disk to be restored) at the location specified, with the following syntax:
<Name of the original virtual machine>_<counter>.
Backup proxy obtains the virtual machine data from Druva Cloud.
Restore operations starts. Druva checks if the restore completes successfully.
If the restore completes successfully, a new virtual machine is available.
If the restore fails, Druva deletes the newly-created virtual machine.
For Microsoft SQL database (with application-aware backup), the application is restored.
Types of recovery point
Hot recovery point
Hot recovery points are point-in-time images of backup data stored on CloudCache. Hot recovery points are created only if you have CloudCache deployed and configured in your virtual infrastructure.
Typically, hot recovery points are maintained for:
Data proximity - Keep a local copy of data on-premises
Faster RTO - Enabling quicker restore time in event of a failure.
A restore of hot recovery points is an on-demand restore of virtual machine data that resides in CloudCache. Such a restore operation continues until your data is restored to the location that you specified.
Warm recovery point
Warm recovery points are point-in-time images of data dating back to 90 days in time that are stored in warm storage.
Typically, warm recovery points are maintained for:
To reduce the on-premise footprint and save cost.
Protect backup data against ransomware attacks.
Restores of warm recovery points are on-demand restores of virtual machine data dating back to 90 days in time. Restores of warm recovery points continue till the data is restored to the location that you specified.
Cold recovery point
❗ Important
The availability of this feature is limited based on the license type, region, and other criteria. To access this feature, contact your Druva Account Manager or Druva Support. This content is subject to change based on the continuous improvements to this feature.
Cold recovery points are point-in-time copies of backup data older than 15 days. These recovery points are stored in the Amazon Glacier Deep Archive.
Typically, cold recovery points are maintained for:
Long term data which over a period is hardly accessed or restored.
Need to store this data for compliance and audit purposes.
Cheaper storage and cost savings.
At the time of restore, data from the cold tier is retrieved, moved temporarily to the warm tier, and then restored.
Once you click Restore and initiate the restoration process, the data retrieval from cold tier and its restore from the warm tier happen automatically. Warmed up data is deleted from the warm tier after 10 days.