Skip to main content
Druva Documentation

About VMware restores

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

Virtual Machine Restore

If you have taken a VMware backup, you can restore: 

Restore Type Description
Full virtual machine Restores the entire VM.
Data Restore Restores VMDKs, files and folders
Phoenix provides you with the capability to restore files to CIFS/SMB share and any virtual machine in your vCenter/ESXi.  Phoenix also supports file-level restore to the guest virtual machine in the VMC environment. 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. Phoenix supports SQL Server aware backups, it provides the following options to restore databases:

Restore Type Description
Database restore: Restore SQL Server databases using snapshots. When you enable application-aware backup on VMware virtual machines, Phoenix detects the applications inside the virtual machine and takes a backup of the data that the application generates. Since Phoenix supports backup of Microsoft SQL Server databases inside VMs, it takes VSS snapshots of the SQL Server instances and uploads it to the Phoenix 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 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. 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, Phoenix provides an option to enable transaction log backups. If you enable it, Phoenix uses the virtual device interface (VDI) to back up and upload the transaction logs to Phoenix 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. 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, 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:

Restore_worflow.png

Step Operations
Step 1

Phoenix administrator initiates virtual machine restore. Phoenix forwards the restore request to the backup proxy pool.

  • Based on the load balancing algorithm, Phoenix 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.
Step 2
  • Phoenix 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.
Step 3

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:
    • Phoenix deletes the virtual disks (VMDKs) of the existing virtual machine
    • Phoenix 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, Phoenix detaches these virtual disks (VMDKs). 

    • Phoenix restores the virtual disks (VMDKs) of the virtual machine
    • Phoenix does not change the name or any other configuration of the virtual machine
  • For a disk restore, Phoenix 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>.

Note: For disk restore, create a minimum configuration virtual machine because VMware does not allow to create a disk without creating the virtual machine.

Step 4 Backup proxy obtains the virtual machine data from Phoenix Cloud.
Step 5

Restore operations starts.

Phoenix checks if the restore completes successfully. 

  • If the restore completes successfully, a new virtual machine is available.

  • If the restore fails, Phoenix deletes the newly-created virtual machine.

Step 6 For Microsoft SQL database (with application-aware backup), the application is restored.

Types of snapshot 

Hot 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 snapshot 

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. 

Cold snapshot 

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.  

  • Was this article helpful?