Three types of VMware data backup and Recovery methods

Server virtualization, especially VMware-style server virtualization, makes it a lot of sense for IT staff. As far as we can see, server virtualization addresses issues related to server expansion, resource consumption, server expansion, energy consumption, and high availability. Server virtualization also gives us more time to address other pressing issues, such as enterprise resource plan upgrades, storage items being relocated, or why Star Trek 11 is not released until 2009.

Despite the fact that VMware offers encapsulation and abstraction technology, we have benefited, but the fundamental changes that have taken place in the field of data protection pose challenges. Even with VMware virtualization, backup people remain the most whiny IT staff. The biggest challenge is to ensure data consistency and to address the problem of excessive consumption of VMware physical resources.

VMware can encapsulate a physical server into a large hard disk image file-the virtual machine disk format (VMDK) file, so we can't help thinking that backing up the entire server should be as simple as backing up these VMDK files (and, of course, related configuration files).

But in most cases, that is not the case. Unless the virtual machine (VM) is turned off, the backup VM cannot overwrite all files in the running state. In other words, this type of backup does not guarantee data consistency, and therefore does not guarantee that the restored VM contains enough precise information to indicate that the server has recovered successfully.

As for the problem of excessive resource consumption, this is the side effect of virtualization. One of the key reasons for using VMware to virtualize systems is to focus resource consumption on fewer physical servers, reducing the idle cycles that exist in most it server architectures. However, doing so also has the undesirable effect of not finding enough resources to keep data backups running unimpeded.

Backup touches the vulnerabilities within VMware: VMware's ability to handle excessive disk and network I/O is weak. In fact, deciding whether to virtualize the physical server depends on the disk density, network I/O in the physical server. Needless to be sure, the backup load is the maximum load that VMware servers assume.

However, there are ways to solve these problems and, in some cases, to be more outstanding than the standard physical server backup and recovery methods. However, there are some misconceptions about these methods, as well as the implementation measures for Third-party backup/recovery products. In fact, many administrators still lack the means to effectively implement backup and recovery, and the road is full of frustration.

Method 1: Install local backup programs in each VM

How it works: This is a traditional backup method that installs the Backup program in each VM, just as it did in each physical server before. As the following illustration shows, data flows through the LAN to the backup/restore facility, and the data flow is the same when the backup program is installed on the local physical server.

The advantages of this approach are as follows:

The installation and configuration of the backup program is very similar to the installation and configuration of the physical server, so there is no need for specialized techniques and program changes.

The recovery process has not changed and is very similar to the process of restoring files to a physical server.

This makes it possible to recover the file, which is even more important when we adopt other methods.

It is also possible to implement full and incremental backups, and this is particularly important as we discuss other approaches.

If you use specialized application-aware backup programs, such as SQL or Exchange, this will help to achieve consistency in application data, and the resulting backups are consistent across applications.

The disadvantages of this approach are as follows:

Since all backups are running on the same server, you need to be very careful not to consume VMware host resources too much.

This approach is of little value, although the server can be encapsulated into a small number of large vmdk files, but the backup program does not have the ability to provide fast backup or recovery capabilities, while disaster recovery requires a quick and comprehensive recovery of the server.

Deployment Tips

In a physical server, running data backups at the same time may not be a problem because physical servers have sufficient idle resources, but for VMware virtual architectures, idle resources are fully exploited and multiple backup operations may block physical servers. Thus, after virtualization, you should modify the backup manual to avoid excessive duplication of resources through the backup window.

A VM allows only one stream of data. The VM's VMDK file is typically shipped in a VMFS volume, and multiple data flow operations can easily overwrite VMFS volumes. Therefore, unless the vmdk file is quarantined in stand-alone volumes (RDM, ISCSI LUNs, or stand-alone VMFS volumes), backups should be run as a single flow rather than as a multiple-stream operation.

method to install the backup program in the 2:esx Service console

How it works: This method is installed in the ESX Service console in the Backup program, the following figure back up the VM potential VMDK filegroup. The service console uses a Red Hat Linux operating system so it can use a Linux backup program.

The advantages of this approach include:

You can back up all the VMS with just one backup program, not a single VM with a backup program.

In this way, VM resources can be fully backed up with a simple backup of a small number of large vmdk files.

Images can recover quickly because you need to recover a large image without having to look up a large number of small images.

Disadvantages of this approach include:

Scripts are required to automatically close, snap, and start VMs. This is necessary to ensure the consistency of application data in the backup process.

It is not possible to recover files, this method only backs up and restores images. In addition, this means that you cannot implement an incremental backup.

Vnware points out that its development process includes the removal of service Console from ESX server. VMware's ESX Server 3i has taken the first step on this point.

Deployment Tips

To ensure application consistency, you should shut down the VM before backing up the VMDK.

The vmdk file is still in the backup window.

Unfortunately, the VM loses its utility during the backup process.

The VMDK file is backed up using the backup program in the service console.

If you can't shut down, take advantage of the VMware Snapshot feature to capture the running VM and get instant backups.

The backup data stays in the same state, and therefore does not guarantee data consistency.

Also, implementing automation requires scripting.

Not all backup programs support this approach, so you need to investigate beforehand.

For backup of application data consistency, use VSS to stop the application before it is backed up. However, this requires a very complex script.

You can take advantage of the VCB facility in the ESX Service Console to obtain a snapshot of the virtual machine in the running state:

Vcbmounter Facilities:

Creates a static snapshot of the VM.

Project a snapshot into a set of files that may be in the console's local directory or in a remote directory on the LAN.

Backup and restore local files with backup software supported by ESX console.

Vcbrestore Facilities:

Restore the VM to the original site or to another site,

If you decide to take the risk of scripting, you'll find that error proofing is one of the hardest aspects of scripting, and you need to write a lot of code.

Method 3:vmware Centralized Backup (vcb-proxy)

How it works: This approach involves a set of VMware facilities, often referred to as VMware centralized backup. This approach enables non-LAN backups in a centralized Windows 2003 proxy server to be connected to the same San volume, known as ESX server. The data is then transmitted to the proxy server through Third-party backup software as a subsequent backup. This method is more complex than the above two methods, including the following components:

Backup Proxy Server:

The server can access the same volume as the VMware host.

Image of Load/output VMDK file in Proxy server.

This load/output image is backed up by a backup program that is hosted in a proxy server.

VCB Framework:

The synchronization actuator in the ESX server refreshes the file system and creates snapshots.

The Vlun actuator in the VCB Proxy Server allows VMDK files to exist in the server.

Using VCB automatic workflow, command line facilities (Vcbmounter/vcbrestore) play a role.

Backup software Integration module:

Modules are integrated into the components of the VCB framework.

Both VMware and backup programs can develop and support this module.

The integration and use of variables between backup programs is relatively straightforward.

Click here to view the VMware centralized backup diagram using the Backup proxy server.

VMware centralized backups with backup proxy servers enable non-LAN file backups and non-LAN image backups to be performed. However, the two approaches are implemented in a very different way.

VCB file backup/restore is to load the vmdk file in the VCB proxy server, as follows:

1 Backup work requires the VCB framework to obtain a VM snapshot, load a VB snapshot on the VCB proxy server, and load paths including Sans, C:\mnt, and so on.

2 Backup (full, incremental, differential Backup) directory/file with Backup program.

The 3 Backup program requires the VCB framework to uninstall VM snapshots so that the VM no longer has snapshot capabilities.

4 through the Backup program installed in the VM, the file is restored to the original VM via LAN.

Click here to view the Vcb-proxy workflows for file backup and recovery.

VCB image Backup/restore is the output of the vmdk file to the VCB proxy server, as follows:

1. Backup requires the VCB framework to obtain a snapshot of the VM and output snapshots, including Sans, C:\mnt, and so on.

2. Image files, such as system files, are backed up by a backup program.

3. The backup software requires the VCB framework to unload the VM snapshots so that the VM no longer has snapshot capabilities.

4. Use the Backup program to restore the output of the VM image to a staging area that VMware can access, which may be in the proxy Server or ESX Service Console, completing the recovery effort.

The 5.VM image is loaded into the ESX host at the specified location.

Click here to view the Vcb-proxy workflows for image backup and recovery.

The advantages of this approach include:

You can use a backup program in VCB Proxy to back up all the VMS without having to have a single program per VM.

In this way, VM resources can be fully backed up with a simple backup of a small number of large vmdk files.

Images can recover quickly because you need to recover a large image without having to look up a large number of small images.

The backup process is transferred to the VCB Proxy server, reducing the overhead of the ESX server.

This backup method is not LAN-capable and can be implemented in a SAN, which in theory is faster than lan-based backup methods.

Disadvantages of this approach include:

Automation and ease of use depend on the ability of third-party backup software.

If no form of backup software is integrated into the backup process, it becomes very complex to deploy this approach.

If you want to restore files directly to the VM, you need to install the backup software in the VM.

For Windows systems that do not have integrated VSS, an image backup provided by VCB causes the data to be in the same state.

VCB does not provide a recovery mechanism for Windows System State, although it is possible to successfully achieve full server recovery, if the system state is disordered while operating the VM, there is no guarantee of full recovery.

Deployment Tips

Keep in mind that VCB is not a backup/restore program but a set of facilities that can be integrated into a Third-party backup application.

Proxy server is not a virtual machine.

VCB cannot be installed on a server in the virtual center, nor can it be registered.

Proxy server needs to install Windows 2003 Server, SP1, or R2.

Proxy server must be installed in the same LUN area as the ESX servers.

VCB Proxy Server does not support multiple paths.

If you need to recover files, but you do not want to install a backup program for each VM, you can create a restore-only VM, which includes backup and recovery programs, restores files to this VM, and then migrates files to the correct target VM over a network share.