Shulou(Shulou.com)06/03 Report--

It is not an exaggeration to say that server virtualization, especially in the form of VMware, has benefited IT staff immensely. From what we've seen, server virtualization can solve problems related to server expansion, resource consumption, server expansion, energy consumption, high availability, and more. Server virtualization also frees us up to solve other pressing problems, such as enterprise resource plan upgrades, repeated migration of storage projects, or the question of why my frog never comes home.

While VMware provides the benefits of encapsulation and abstraction, fundamental changes in data protection also present challenges. Even with VMware virtualization, backup people are still the IT people who complain the most. The biggest challenge is to ensure data consistency and address VMware physical resource overconsumption.

VMware can encapsulate physical servers into large hard disk image files-Virtual Machine Disk Format (VMDK) files-so we can't help but think that backing up the entire server should be as simple as backing up these VMDK files (and, of course, the associated configuration files).

But in most cases, this is not the case. Backup VMs in the running state cannot overwrite all files unless the virtual machine (VM) has been shut down. In other words, this backup method does not guarantee data consistency 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. A key reason for virtualizing systems with VMware is to concentrate resource consumption on fewer physical servers, thereby reducing idle cycles common to most IT server architectures. However, doing so also has the negative effect of not being able to find enough resources for the data backup to run unimpeded.

Backup hits a vulnerability inside VMware: VMware's ability to handle excess disk and network I/O is weak. In fact, deciding whether to virtualize a physical server depends on disk density, network I/O, in the physical server. Without a doubt, the backup load is the largest load on VMware servers.

However, there are ways to address these issues and, in some cases, outperform standard physical server backup and recovery methods. However, there are some misconceptions about these approaches and about the implementation measures provided by third-party backup/recovery products. In fact, many administrators still lack effective backup and recovery methods, and the road is full of frustrations.

`

Method 1: Install a local backup program in each VM

How it works: This is a traditional backup method, installing backup programs in each VM, just like installing backup programs in each physical server before. As shown in the figure below, data flows into the backup/restore facility through the LAN, as it did when backup programs were installed on local physical servers in the past.

The advantages of this approach are as follows:

The installation and configuration of the backup program is very similar to the installation and configuration on the physical server, so no special skills or program changes are required.

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

This makes it possible to recover files; this is even more important when we use other methods.

Full and incremental backups are also possible, and again, this is especially important when we discuss other approaches.

If you employ a specialized application-aware backup program, such as SQL or Exchange, this will help achieve consistency of application data, resulting in backups that are consistent across applications.

The disadvantages of this approach are as follows:

Since all backups run on the same server, you need to be careful not to consume excessive VMware host resources.

Although servers can be encapsulated into a small number of large VMDK files, backup programs know nothing about this and cannot take advantage of this to provide fast backup or recovery capabilities; disaster recovery requires a fast, comprehensive recovery of the server, and this approach is of little value.

Deployment tips

In physical servers, running simultaneous backups of data may not be a problem because physical servers have plenty of idle resources, but with VMware virtual architectures, idle resources are fully utilized and multiple backup operations can clog physical servers. Therefore, after virtualization, the backup manual should be modified to avoid excessive duplication of resources through backup windows.

A VM allows only one data stream. VMDK files for VMs are usually hosted in a VMFS volume, and multiple streaming operations can easily overwrite VMFS volumes. Therefore, unless VMDK files are isolated in separate volumes (RDM, iSCSI LUN, or separate VMFS volumes), backups should run single-stream rather than multi-stream.

`

Method 2: Install backup programs in ESX Service Console

How it works: This method installs backup programs in ESX Service Console and backs up potential VMDK filegroups in VMs as shown below. The Service Console is powered by the Red Hat Linux operating system, so Linux backup programs can be used.

Advantages of this approach include:

One backup program is needed to back up all VMs, rather than one backup program for each VM.

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

Images can be recovered quickly because only large images need to be recovered instead of having to look for a large number of small images.

Disadvantages of this approach include:

Scripts are required to automatically shut down, snap, and start VMs. This must be done to ensure consistency of application data during backup.

It is impossible to restore files, this method can only backup and restore images. This also means that incremental backups cannot be implemented.

VNware states that its development process includes removing the Service Console from ESX Server. VMware's ESX Server 3i takes the first step at this point.

Deployment tips

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

VMDK files sit still in the backup window.

Unfortunately, VMs lose utility during backup.

VMDK files are backed up using the backup program in Service Console.

If shutdown is not possible, VMware Snapshots can be used to capture running VMs for instant backups.

The backup data stays in the same state and thus cannot guarantee data consistency.

Similarly, scripts are needed to automate.

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

For consistent backups of application data, VSS is utilized to bring the application down before backup. However, this requires a very complex script.

You can take a snapshot of a running VM using the VCB facility in ESX Service Console:

vcbMounter Facilities:

Create static snapshots of VMs.

Project snapshots to a set of files, either in a local directory on the console or in a remote directory on the LAN.

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

vcbRestore Facility:

Restore VM to original site or other site,

If you decide to take a risk with scripting, error checking and correction is one of the hardest aspects of scripting and requires 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 backups. This approach connects non-LAN backups in a centralized Windows 2003 proxy server to the same SAN volume, called ESX Server. The data is then transferred to a proxy server via third-party backup software as a back-up. This method is more complex than the two methods described above and includes the following components:

Backup proxy server:

Servers can access the same volumes as VMware hosts.

Load/export images of VMDK files in proxy servers.

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

VCB Framework:

Sync Drivers in ESX servers refresh file systems and create snapshots.

The "vLUN pusher" in the VCB proxy server allows VMDK files to exist on the server.

Command line facility (vcbMounter/vcbRestore) works with VCB automated workflow.

Backup software integration module:

Modules are integrated into components of the VCB framework.

VMware and backup programs can both develop and support such modules.

Integration between backup programs and the use of variables is relatively simple.

Click here to see a diagram of VMware centralized backup with backup proxy servers.

VMware centralized backup with backup proxy servers can perform non-LAN file backups and non-LAN image backups. However, the two approaches are implemented in very different ways.

`

VCB file backup/restore is to load VMDK files in the VCB proxy server. The specific steps are as follows:

1 Backup work requires VCB framework to obtain VM snapshot, load VB snapshot in VCB proxy server, load path includes SAN, C:mnt, etc.

2 Backup directories/files using backup programs (full, incremental, differential).

3 The backup program requires the VCB framework to offload VM snapshots so that VMs no longer have snapshot functionality.

4 Files are restored to the original VM via LAN by a backup program installed in the VM.

`

Click here to view the VCB-Proxy workflow for file backup and recovery.

VCB image backup/recovery is to output VMDK files to VCB proxy server. The specific steps are as follows:

1. The backup job requires the VCB framework to take a snapshot of the VM and output the snapshot along output paths including SAN, C:mnt, and so on.

2. Output image files such as system files are backed up by a backup program.

3. Backup software requires the VCB framework to offload VM snapshots so that VMs no longer have snapshot functionality.

4. The backup program restores the exported VM image to a temporary area VMware can access, which may be located on Proxy Server or ESX Service Console.

5. VM images are loaded into the ESX host at specified locations.

Click here to view the VCB-Proxy workflow for image backup and recovery.

Advantages of this approach include:

Instead of having a program for each VM, you can use a backup program in VCB Proxy to back up all VMs.

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

Images can be recovered quickly because only large images need to be recovered instead of having to look for a large number of small images.

Offloading the backup process to the VCB proxy server reduces ESX server overhead.

This backup method does not require a LAN and can be implemented in a SAN, theoretically 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.

Without some form of backup software integrated into the backup process, deploying this approach becomes very complex.

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

For Windows systems without VSS integration, image backups provided by VCB leave the data in the same state.

VCB does not provide a Windows system state recovery mechanism, although it is possible to successfully achieve a complete recovery of the server, but if the system state is disturbed while operating the VM, complete recovery is not guaranteed.

Deployment tips

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

Proxy Server is not a virtual machine.

VCBs cannot be installed on servers in virtual centers, nor can they be registered.

Proxy Server requires Windows 2003 Server, SP1 or R2.

Proxy Server must be installed in the same LUN zone as ESX Servers.

VCB Proxy Server does not support multipath.

If you need to restore files but you don't want to install backup programs for every VM, you can create a recovery-only VM that contains backup and restore programs, restore files to that VM, and then migrate files to the correct target VM via network shares.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.