Virtual Machine Restore
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 Phoenix provides you with the capability to restore files to CIFS/SMB share and any virtual machine in your vCenter/ESXi. Druva Phoenix also supports file-level restore to the guest virtual machine in the VMC environment. Druva Phoenix 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.
MS-SQL Restore (from application-aware backups)
At the time of configuring virtual machines for backup, you were asked if you wanted to enable application-aware processing. Druva Phoenix supports SQL Server aware backups, it provides the following options to restore databases:
|Database restore: Restore SQL Server databases using snapshots.||When you enable application-aware backup on VMware virtual machines, Druva Phoenix detects the applications inside the virtual machine and takes a backup of the data that the application generates. Since Druva Phoenix supports backup of Microsoft SQL Server databases inside VMs, it takes VSS snapshots of the SQL Server instances and uploads it to the Druva Cloud along with the virtual machine snapshot. Now, when you want to restore the database to a virtual machine, you can choose a snapshot and Druva Phoenix restores the databases to a state that was backed up in the selected snapshot.|
|Point In Time restore: Restore SQL Server databases to a point in time using transaction logs||Transaction logs are a tool to restore databases to a point in time in between database snapshots. Druva Phoenix can back up transaction logs in addition to the database snapshots so that you can get a tighter recovery time objective (RTO). When you enable SQL Server aware backup on VMware VMs, Druva Phoenix provides an option to enable transaction log backups. If you enable it, Druva Phoenix uses the virtual device interface (VDI) to back up and upload the transaction logs to Druva Cloud at specified intervals until the next full SQL Server aware virtual machine snapshot is backed up. Now, you can choose a point in time to restore databases. Druva Phoenix restores the databases to the transaction with a timestamp that is closest to the point in time that you choose.|
|Transaction Mark restore: Restore SQL Server databases using transaction marks||If you enable transaction log backups for databases, Druva Phoenix can utilize transaction marks to identify specific transactions. At the time of restoring databases, you can choose transactions that are marked to restore databases up to the point when these transactions occurred.|
Restore virtual machine workflow
The following diagram illustrates the restore workflow:
Administrator initiates virtual machine restore. Druva Phoenix forwards the restore request to the backup proxy pool.
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.
|Step 4||Backup proxy obtains the virtual machine data from Druva Cloud.|
Restore operations starts.
Druva Phoenix checks if the restore completes successfully.
|Step 6||For Microsoft SQL database (with application-aware backup), the application is restored.|
Types of snapshot
Hot snapshots are point-in-time images of backup data stored on Phoenix CloudCache. Hot snapshots are created only if you have Phoenix CloudCache deployed and configured in your virtual infrastructure.
Typically, hot snapshots 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 snapshots is an on-demand restore of virtual machine data that resides in Phoenix CloudCache. Such a restore operation continues until your data is restored to the location that you specified.
Warm snapshots are point-in-time images of data dating back to 90 days in time that are stored in warm storage.
Typically, warm snapshots are maintained for:
- To reduce the on-premise footprint and save cost.
- Protect backup data against ransomware attacks.
Restores of warm snapshots are on-demand restores of virtual machine data dating back to 90 days in time. Restores of warm snapshots continue till the data is restored to the location that you specified.
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 snapshots are point-in-time copies of backup data older than 15 days. These snapshots are stored in the Amazon Glacier Deep Archive.
Typically, cold snapshots 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.