Help CenterClumio Terraform ProviderClumio Python SDKClumio GO SDK
User Guide
BlogChangelogLogin

VMware restores

Suggest Edits

The primary purpose for any backup application is to allow restores in the event of a disaster and must allow for testing recoveries. Clumio allows you to restore a VM from the backups that have been created and stored in the cloud. You can restore an entire VM as a copy, overwrite the source VM to roll it back to an earlier point in time, restore a folder on a VM, or restore an individual file.

As part of the backup/restore process, you need to select the file systems you want to back up. In order to restore a single file, you can use a file prefix based search to find all the backups for a given file. You can also do a prefix search within a single backup.

In case you don’t know specific names or even prefixes, you can browse all the file systems for a specific backup and restore multiple directories or files. Browsing is available across multiple regions and provides the following features:

  • A list of all filesystems, including sub-directories with browsing capabilities
  • Browsing and restore via the Clumio UI
  • Restore of multiple directories and multiple files from multiple filesystems
  • File level restore (FLR) to restore a single file from a backup

Your assigned role determines the actions you can do in the Clumio UI. For example, users who are assigned to the "Backup Admin" role can do all restores except for granular record retrieval. To learn more about roles, see Roles.

Rapid recovery

Rapid recovery is enabled by default for VM restores. With Rapid Recovery enabled, Clumio tracks the differentials in the VMware blocks as backups are completed. You can use rapid recovery to restore only the blocks that have changed to recover a VM to an earlier state without performing a full restore.

For example: On August 29th, you want to restore the VM to its state on August 19th. Between those two dates 10GB of data has changed of the 1TB of data stored. Only those 10GB would be restored, allowing the restore to complete more quickly than it would if you created a full clone of the VM.

If you prefer to perform a full clone of a VM when doing a restore, switch to advanced mode in the Restore Virtual Machine dialog to switch the Rapid Recovery toggle off.

VM restore options

There are two ways to restore a VM. You can restore a VM to create a copy, or you can overwrite a VM and restore the data to an earlier date.

  • Restore a VM to create a copy of the VM from the date you select. The restored VM will be created in the same VM Folder as the original protected VM and will be kept powered off to allow you to make appropriate changes to networking configurations before you power on the VM.
    The VM restore described above results in the backup being restored to its original location. You can use the Advanced mode to change the location and customize other components of the restore process, such as restoring to an alternate vCenter or Cluster, or restoring from an on-premises vCenter into VMware Cloud on AWS.

Note: For VMware Cloud on AWS, you cannot restore into the management resource pool or the management datastores. You must always restore into the compute resource pool and compute datastores.

For VMs with virtual Raw Device Mapping (RDM) disks, performing a full VM restore converts the virtual RDM disk to a regular disk. After the full VM restore, you can convert the regular disk to a virtual RDM disk. To keep the disk as a virtual RDM, use the Overwrite Source VM option to restore the VM.

  • Overwrite a source VM to overwrite the data on a VM while preserving its current configuration. Since this operation does not replace the configuration, it effectively retains the data and rolls the entire VM operationally back to a previous point in time in production. This feature does the following:
    Ensures that all VMware enterprise applications that rely on uniquely identifiable VMs can still function properly after recovery.

Preserves System Management BIOS universally unique identifiers (SMBIOS UUIDs) to ensure applications continue to run after VM recovery and contribute to rapid recovery efforts in the production environment.

Overwrites in production environments require important considerations. Be aware that an overwrite may change the data of the existing VM, since it removes associated files from the VM.

Note: Only one source VM overwrite can occur at a time. Scheduled backups for the VM being restored may fail until the overwrite is complete or may get blocked behind the restore operation, depending on how long it takes to complete the overwrite.

Updated 4 months ago