Three ways to backup and restore VMware data

Server virtualization, especially in the form of VMware Server virtualization, has made it much more rewarding for IT staff. As far as we can see, server virtualization solves issues related to server sprawl, resource consumption, server sprawl, energy consumption, and high availability. Server virtualization also gives us more time to solve other pressing problems, such as enterprise resource plan upgrades, storage projects repeatedly migrating, or why Star Trek 11 will not be released until 2009.

While we benefit from VMware's provision of encapsulation and abstraction technologies, the fundamental changes in the data protection landscape also pose challenges. Even with VMware virtualization, the backup staff remains the most whiny IT staff. The biggest challenge is to ensure data consistency and solve the problem of over-consumption of VMware's physical resources.

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

But in most cases, that is not the case. Backing up a VM in a running state cannot overwrite all files unless the virtual machine (VM) has been shut down. In other words, this backup method does not guarantee the consistency of the data, and therefore does not guarantee that the recovered VM contains enough accurate information to indicate that the server has been successfully recovered.

As for the problem of excessive resource consumption, this is a side effect of virtualization. One of the key reasons for using VMware to virtualize systems is to focus resource consumption on fewer physical servers, thus reducing the idle cycles that are present in most it server architectures. However, doing so also has a negative impact-the inability to find enough resources to allow data backups to run unhindered.

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

However, there are ways to solve these problems and, in some cases, better than standard physical server backup and recovery methods. However, there are some misconceptions about these methods, and there are misconceptions about the implementation of third-party backup/recovery products. In fact, many administrators still lack the means to effectively implement backup and recovery, and roads are full of setbacks.

Method 1: Install the local Backup program in each VM

How it works: This is a traditional backup method that installs the Backup program in each VM as if it were previously installed on each physical server. As shown, data flows through the LAN to the backup/restore facility, and the data flow is the same when the backup program was previously installed on the local physical server.

The advantages of this approach are as follows:

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

The recovery process has not changed, much like the process of recovering files to a physical server.

In this way, it is possible to recover files, which is even more important when we adopt other methods.

It is also possible to implement full and incremental backups, which is especially important when we discuss other methods.

If you are using a dedicated application-aware backup program, 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:

Because all backups run on the same server, you need to be careful not to consume VMware host resources too much.

Although the server can be encapsulated into a small number of large VMDK files, the backup program is unaware of this and cannot take advantage of this to provide fast backup or recovery capabilities, while disaster recovery requires a fast and comprehensive recovery of the server, which in this way is of little value.

Deployment Tips

In a physical server, it may not be a problem to run data backups at the same time because the physical servers have sufficient idle resources, but for VMware virtual architectures, idle resources are fully utilized and multiple backup operations can block physical servers. Thus, after virtualization, the backup manuals should be modified to avoid excessive duplication of resources through backup windows.

Only one data stream is allowed for a VM. A vmdk file for a VM is usually sent in a VMFS volume, and multiple data flow operations can easily overwrite a VMFS volume. Therefore, unless the vmdk file is isolated in a standalone volume (RDM, Iscsilun, or standalone VMFS volume), the backup should run as a single stream instead of multiple streams.

Method 2:esx Install the Backup program in the Service console

How it works: This method is in the ESX Service console when you install the backup program, by backing up the potential vmdk filegroups in the VM. The service console uses a Red Hat Linux operating system and is therefore able to use the Linux backup program.

Advantages of this approach include:

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

In this way, VM resources can be backed up completely, simply backing up a small number of large vmdk files.

Images can be recovered quickly because you need to recover large images without having to look for large numbers of small images.

Disadvantages of this approach include:

Scripts are required to automatically close, snapshot, and start VMs. This must be done in order to ensure consistency of the application data in the backup process.

It is not possible to recover files, this method can only back up and restore images. In addition, this also means that incremental backups cannot be implemented.

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

Deployment Tips

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

VMDK file is still in the backup window.

Unfortunately, the VM is out of utility during the backup process.

VMDK files are backed up using a backup program in service console.

If you cannot shut down, you can take advantage of the VMware Snapshot feature to capture a running VM for immediate backup.

The backup data stays in the same state, so data consistency is not guaranteed.

Similarly, scripting is required for automation.

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

For backup of application data consistency, use VSS to make the application stop running before the backup. However, this requires a very complex script.

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

Vcbmounter Facilities:

Create a static snapshot of the VM.

Projects a snapshot into a set of files that may be in the local directory of the console 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 initial site or to another site,

If you decide to take the risk of scripting, you'll find that error checksums are one of the hardest aspects of scripting technology and require a lot of code to write.

Method 3:vmware Centralized Backup (vcb-proxy)

How it works: This approach involves a set of VMware facilities, often referred to as a VMware centralized backup. This approach enables non-LAN backups in a centralized Windows 2003 proxy server to be connected to the same SAN volume, called the ESX server. The data is then transferred to the proxy server via third-party backup software as a post-order backup. This approach is more complex than the two methods described above, including the following components:

Backup Proxy Server:

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

Image of the load/output VMDK file in the proxy server.

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

VCB frame:

The sync drivers in the ESX server can refresh the file system and create snapshots.

The Vlun drive in the VCB Proxy Server allows the vmdk file to exist on the server.

With 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 with the backup proxy server.

VMware centralized backup with Backup proxy Server enables non-LAN file backup and non-LAN image backup. However, the two approaches are very different in their implementation path.

VCB file backup/restore is the process of loading a VMDK file in the VCB proxy server, as follows:

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

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

3 The Backup program requires the VCB framework to offload VM snapshots so that VMS no longer have snapshot capabilities.

4 through the Backup program installed in the VM, the files are restored to the initial VM via the LAN.

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

VCB image Backup/restore is the process of exporting a VMDK file to the VCB proxy server, as follows:

1. Backup work requires the VCB framework to take a snapshot of the VM and output the snapshot, including the San, 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 offload VM snapshots so that VMS no longer have snapshot capabilities.

4. Use the Backup program to restore the exported VM image to a staging area that VMware has access to, which may be located in the proxy Server or ESX Service Console, thus 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 workflow for image backup and recovery.

Advantages of this approach include:

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

In this way, VM resources can be backed up completely, simply backing up a small number of large vmdk files.

Images can be recovered quickly because you need to recover large images without having to look for large numbers of small images.

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

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

Disadvantages of this approach include:

The ability to automate and make it easy to use depends on the capabilities of third-party backup software.

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

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

For Windows systems that do not have integrated VSS, the 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 implement full server recovery, but if the system state is disturbed when operating VMS, full recovery is not guaranteed.

Deployment Tips

Keep in mind that VCB is not a backup/recovery program, but a set of facilities that can be integrated into third-party backup applications.

Proxy server is not a virtual machine.

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

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

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

VCB Proxy Server does not support Multipath.

If you need to recover files, but you don't want to install a backup program for each VM, you can create a recovery-only VM that includes a backup and recovery program, restores the files to this VM, and then migrates the files to the correct target VM over a network share.

Three ways to backup and restore VMware data