Section 12.3. Backing Up Virtual Machines

12.3. Backing Up Virtual Machines

For the purpose of backup, virtual machines can be considered the same as physical machines. The backup software that operates on physical machines works just as well on virtual machines. Generally speaking, whatever tools and processes you currently have in place for your physical machines can be used to back up your virtual machines.

However, in addition to backing up the operating system, application software and data, you can also back up a server's virtual disk files as well. Moreover, you can back up an entire virtual machine (hardware, operating system, applications, and data) as a single entity.

The following subsections detail these two approaches: the physical server approach and the virtual machine approach.

12.3.1. Backing Up Virtual Machines Like Physical Servers

A virtual machine can be backed up using most commercially available backup agents. Similar to backing up physical servers, this backup approach can specify files, directories, shares, and so on. A virtual machine can back up itself and/or other virtual machines using standard backup technologies and approaches. A virtual machine can be backed up locally or across the network. Each virtual machine must be licensed for the appropriate agents used in this approach, however.

This method has several well-served points that follow conventional backup wisdom and requirements. The foremost lies in the ability to perform file-level backups and restores; you back up what you want, when you want, and how you want. This approach is generally considered to be the foundation of any backup environment because you have very finite control points in the backup and it allows for continuous operation of the server/services during the backup.

Always remember that a virtual machine should be considered as another device in your production environment. It may lack in physical occupation, but provides many advantages that would encumber non-virtual machines. Remember that physical devices have physical constraints in terms of power, environmental occupation, hardware management, and tape media resources. The case for virtual machines becomes very attractive when one considers the opportunities to leverage existing technologies for backup media, including SAN, NAS, tape, and DVD approaches that are not limited to one physical datacenter facility or even a facility owned by the client (in terms of outsourcing the backups to an ISP type IDC). Based on the opportunities presented, virtual disks and files can reside on any number of servers, SANs, and NASes at the local or distributed datacenter level. All virtual disks can be recovered to any ESX Server, regardless of the physical hardware or base architecture of the recovery facility or resources. In the following examples, a general comparison is made and the pro and cons of each strategy are listed.

12.3.1.1. Pros

The pros to backing up virtual machines like physical servers include the following:

• General backup approaches apply; allows incremental, differential backup.

• The maintenance windows are extended to include any time allowed by the operational schedule. This approach may be well founded in your daily operations and strategy for intra-day backups as prescribed by regulated or unregulated legal requirements. This approach permits the archiving of applications without virtual machine shutdown.

• Leverages existing backup techniques

• This approach is generally deemed best for application data. Remember that regulations under HIPAA and any credit card data environments may not consider the abilities of virtual technologies in their current state.

12.3.1.2. Cons

The cons to backing up virtual machines like physical servers include the following:

• Cost This approach may require agent software on each virtual machine.

• Archived system data can only be restored onto a running virtual machine. This implies that your facilities are fully operational and that a virtual machine has become operational prior to beginning the recovery process. In times of chaos (disaster recovery), this is a very exposed position in terms of time management and time to recover, assuming you have the full set of recovery tapes available, along with the recovery logs to follow the prescriptive and choreographed recovery procedures.

12.3.2. Backing Up Virtual Disk Files

You have a few options for backing up the virtual disk files of your virtual machines. To back up a virtual disk file, the virtual machine must be powered off or suspended. If you want to back up a running virtual machine, there is a work-around. This process involves adding a redo log file to the base disk you wish to back up. This causes all new writes to go to the redo log and not the base disk. This gives you the opportunity to back up the base disk without corruption. Once the backup is complete, you can commit the changes from the redo log to the base disk. The disk must be in persistent, undoable, or append mode. This option won't work if the disk is in nonpersistent mode. The following sections go into more detail on the methods available to back up virtual disk files.

12.3.2.1. Backing Up Virtual Machines (Virtual Disk) from the Service Console

Virtual machines differ from physical servers in terms of the additional opportunities for consolidation in reference to licenses and physical storage requirements. A virtual machine backed up from the Service Console is considered a file/image (virtual disk). The disadvantage of this consideration is that a virtual machine (virtual disk) must be restored in its entirety, not as a compilation of its components. The advantage is that a separate backup license maynot be necessary for the operation.

VMware has, by default, located specific operating files and "user" files in a manner consistent with the Linux management structure in order to minimize the learning curve. Please note that although some of these directories can be manipulated and changed, this practice is strongly discouraged. Third-party applications will assume the defaults are in place, along with the general virtual machine support elements that will be maintained over time. The following are some examples of native locations and file types that virtual machines use in default operations.

• Files in /home/vmware (if VirtualCenter) or if owning the user's home directory (without VirtualCenter)^[1]

  ^[1] VMware Education Services, Virtual Infrastructure with ESX Server and VirtualCenter, Student Manual, ESX Server 2.5 and VirtualCenter 1.2

  1. vm-config.vmx

  2. Nvram

  3. Vmware.log

• Virtual machine file on each VMFS partition

  1. Virtual-disk-name.vmdk

  2. Virtual-disk-name.vmdk.REDO

  3. Virtual-Disk-name.vmss

When you are backing up virtual machines from the Service Console, it's important to know which files to back up. Encapsulation refers to the fact that a virtual machine is defined by a set of files, making it a self-contained unit that's easy to back up.

This is basically virtual machine Training 101, and for those planning on certification, it's guaranteed to be prerequisite knowledge. Later in the "Creating a Snapshot for Backups" section of this chapter, we'll review what a "snapshot" is and how we can use this approach in our backup strategy. Basically, VMware has created a database approach to backups with rollback logs. A baseline backup can be performed in a live environment. Any delta changes are cached and logged (this addresses the Redo logs), and a process to update the baseline will have been developed to ensure the integrity of the backup. Additionally, we'll mention an approach to building a redo of the redo logs as one of the approaches. All these backup approaches may seem confusing, but think of backups as a recording of elements at some point in time. This recording takes some amount of time to complete. In a production environment, it's likely that some changes will occur during that recording time. A "second" redo file of the initial redo file then makes sense in terms of capturing the delta of the changes that occurred during the initial suspense session of time.

In a nutshell, if you want to have a completely restorable backup of the VM and applications, which can be transported to another ESX Server, use the Service Console to back up the virtual disk files of your VM, including the operating system and applications. This allows for speedy installation and migration of the virtual disk onto another ESX Server, even at your alternative datacenter. These virtual disks should also be saved with rollback elements (redo files) to address any templates developed for lab and new server build-outs. It is best to back up via a backup agent the data and any additional applications or logs that change frequently. This approach allows for selective file recovery and restoration. The primary concern here is the window of recovery time coupled with the library documentation of the tape systems application. Often, tapes must rebuild the entire tape library into memory before a file can be recovered. If a recovery is required, the ability to minimize the efforts to meet the constraints of the maintenance window will become a determining factor to success. Time to recover, size of the backup, and the tape library mechanics are the essential determining factors for planning a backup approach. Later in this chapter, considerations for using a SAN are discussed. Based on current SAN replication and recovery technology, a best-case argument to use multiple technologies of virtual disk and SAN replication approaches can be made to develop a very balanced and well-rounded approach to the daily and offsite/alternative site replication and repository of your backup environment.

This approach includes several well-served consideration points that follow virtual machine backup conventional wisdom and requirements. The foremost lies in the ability to perform virtual disk (virtual image) level backups and restores. You backup what you want, when you want, but it does require some consideration in terms of which steps must be performed in what order. There are conditions that must be met to complete the requirements, but when followed, this approach will yield an image that is completely transportable to any other ESX and possibly GSX virtual machine onsite, or at an alternate site. This approach can address disaster recovery and business continuity requirements in a very economic manner. There are limitations on and considerations regarding how and when you wish to perform this type of backup. This approach is generally considered the foundation of any virtual backup environment because you have very finite control points in the backup and it does not allow for continuous operation of the server/services during the backup process. Additional maintenance windows and rollback considerations, coupled with virtual disk size considerations, must be reviewed and planned in order for this approach to be brought into a production environment.

12.3.2.2. Pros

The pros to backing up virtual machines from the Service Console include the following:

• Well-documented virtual machine backup approaches apply; a bootable or easy-to-boot virtual disk that is transportable is composed

• No additional license requirements for additional virtual machines are required

• No backup agents are required (although several third-party applications can offer a GUI interface to perform these functions on a scheduled basis)

• The windows for maintenance are extended to scheduled events windows

12.3.2.3. Cons

The cons to backing up virtual machines from the Service Console include the following:

• Does not leverage existing backup techniques

• Does not allow for file-level backup and recovery (this is an all or nothing approach to the backed up data/application/operating system environment)

• Can potentially create very large files because more than just the changed data is being backed-up

• Some file systems' storage may not be able to house the resultant files under their native format.

• Requires the virtual machine to be offline or powered down/suspended in order to perform the backup. This restricts the users'/services' ability to access the server and its resources during the maintenance window.

12.3.2.4. Creating a Snapshot for Backups^[2]

^[2] VMware Education Services, Virtual Infrastructure with ESX Server and VirtualCenter, Student Manual, ESX Server 2.5 and VirtualCenter 1.2

This approach is a very powerful tool developed to reduce the maintenance window of backups while allowing for the user population to run without obstruction. Like a shadow copy of a database, this snapshot also creates redo logs that cache the changes occurring during the backup operation. With the virtual machine in an undoable condition, any writes to the virtual machine image are locked, thus allowing a backup to occur. Similar to a record lock or file lock condition, the redo log captures changes in a chronological order and updates the virtual image when the process is committed to the changes. This backup is considered a risk-based process due to the fact that operations remain in a production status. VMware recommends that all applications be suspended or closed in order to facilitate the most stable backup state possible. The crash-consistent statement likens the order of risk to that of a server that crashes and comes back up after recovering. The possibility exists that some files may be in a corrupted state, creating the need to commit the redo logs back to the production recovery state in order to repair the missing changes back to a current state operation.

To back up using the snapshot approach, use vmsnap.pla archiveserverc/home/vmware/name/nme/vmx. To restore, use vmres.pla archiveserverc/home/vmware/name/name.vmxo ownerg groupv VMFS.

12.3.2.5. Pros

Creating a snapshot for backups allows archiving of virtual disks without virtual machine shutdown.

12.3.2.6. Cons

Using the snapshot approach has a few drawbacks, such as the following:

• A snapshot is only crash-consistent.

• A snapshot requires local and remote storage space.

• A snapshot is best when applications quiesce themselves and when a cold backup is also available.

• The snapshot backup script dynamically places all virtual disks of a running virtual machine into undoable mode and then exports those virtual disks. The exported disks are copied over the network using scp, the secure copy command. A snapshot backup is crash-consistent, which means the backup is as good as if the power went off. With this backup, there's no guarantee of the disk being bootable.

• The archive for the server must be a system that can receive the scp file transfers, such as a Linux system.