Uh-oh. A virtual machine is down. Or a user accidentally deleted a project they’ve been working on for weeks. Or an application has become corrupted. Or…you get the picture. Good thing you have virtual machine images ready to go in storage (you can create backups using the VMware Consolidated Backup tools, which takes your latest snapshot as a basis for the full image backup). Now all you need to do is decide on a restoration method.
For a full VM restore, you’ll use VMware Converter, while for file-level restoration you’ll use VMware Consolidated Backup (VCB), which also has the choice for centralized, per-group, and self-service restoration.
To restore your backup image of an entire virtual machine, launch VMware Converter. You don’t need to buy a license to use Converter for restore. This tool can also be used to provision new machines from a VCB backup. VCB backups with Converter make for a simple disaster recovery method.
Select a location from the Hosts and Clusters menu and right click, then choose “Import Machine…” You can import VMware Workstation Files, VMware Consolidated Backup, Microsoft Virtual Server Files, Symantec Backup Exec System Recovery Images, StorageCraft ShadowProtect Files, or Acronis Ture Image Files. If you were indeed using VCB to create your backup images, you will specify the disk location of the image you wish to restore, then customize the name, datastore location, and networking. The machine can then be restored immediately or scheduled for a future time.
One disadvantage of full machine restoration is that it requires a full backup located somewhere in disk storage—there is no partial recovery available. If your backups are on tape, you’ll have to move them to a network-accessible disk first.
VCB can restore backups at a file-level, too. This is often desirable when files are unavailable due to user error, corruption, or media failures. There are three main types of file-level restore: centralized, per-group, and self-service. The main differences are the location and number of backup agents on each VM, plus the administration of the restore process.
This diagram from VMware illustrates the VCB backup process; a centralized restore works in reverse.
A centralized restore has a backup agent on a proxy server installed on a VM that will be used to restore data. VCB is used to copy the backup data, selecting the necessary files, to a central server. From the central server, data is copied to the VM using the CIFS sharing protocol.
The main advantage of centralized restore is that you do not have to install and configure backup agents on every individual VM, or pay for as many licenses.
In a per-group restore, each department or grouped VM (like a group of VMs for sales applications, another group for development, etc) has its own backup agent on a single virtual machine. Administrators restore to a host that is also assigned to each group. CIFS is also used in this case to copy individual files to the new virtual machine.
This is essentially the same as a centralized restore, but broken out into several “restore nodes” for each group. If you have a larger organization this helps with workflow as sysadmins assigned to each department can perform backup restore from tape to a disk on the restore node.
A self-service restore process requires backup agents to be installed on every VM. Users can do their own restoration by running the agent and configuring both their own backup to tape and restore to disk.
Users have to be trained to use backup software to find the necessary files and restore them. Access control is almost certainly needed to segment user access to other data.
The main decision admins have to make when setting up a VCB restore process is which end they want their time and effort to go into. With the backup agent on a proxy or nodes, there is less upfront setup, but an admin must be involved with every restore. With agents on every machine, there is more licensing and initial setup involved, but users can then perform their own restorations.