12.4. Best Practices Best practices are developed from the review of many installations and implementations. They are not construed as the only approach to any situation, but rather a culmination of general approaches for most situations. 12.4.1. General Recommendations for Backups[3][3] VMware Education Services, Virtual Infrastructure with ESX Server and VirtualCenter, Student Manual, ESX Server 2.5 and VirtualCenter 1.2
The following approaches are based on the foundational applications of the VMware toolset. Some of the recommendations summarized in this list are based on requirements of VMware, and others are based on experience within the backup technology and planning methodology. Care should be taken to construct your own deployment and use of these recommendations based on the particular and specific needs and requirements of your operating environment. Separate a virtual machine's system data from its application data, control the location of frequently changing data on a separate file system of media (such as SAN, separate directory structure, and so on). Maintain a backup environment of these data sets using your normal backup or SAN's repository strategy. Back up the virtual machine's systems disks via the Service Console while in a suspended or powered down mode of operation. Back up the virtual machine's data disks via backup agents in those virtual machines. This approach is accomplished by using media backup technology or a combination of SANs replication technology. A snapshot approach can be administered but should be done only after considering the risk exposure introduced by this approach. Use snapshot backups with care. Remember that these snapshots impose risk due to the open file conditions. Snapshots require that redo logs be maintained at all times. Based on the type of snapshot dynamics, multiple redo logs may be implemented. Restoration of a snapshot requires that the redo logs be committed in a chronological order. Although the advantages of snapshots allow for minimal downtime opportunities, a long-term plan that evaluates the risk versus the reward should be considered before deploying this approach. Applications and services should be quiesced, suspended, or shut down if possible during the snapshot events. There should always be a cold backup performed and maintained on a regular basis in order to support a recovery in case of unplanned events. Store data on physically separate disks. This approach not only makes backups more flexible but also allows for more flexible deployment from templates. You can configure the applications in your templates to keep their data on separate disk drives, and then provide a new blank disk for data whenever the virtual machine is deployed. Store application data on virtual disks that are separate from those containing system images. Use backup agents inside guest operating systems for application data. Use Service Consolebased backups for system images, or plan to redeploy from a template.
VMware has compiled the results of many approaches to backing up virtual machines, as well as the associated pros and cons attached to each particular process. The preceding listing basically consolidates all approaches into a general best practice. Additionally, as a particular production environment changes, we may recognize the need, or acquired ability to change the backup environment based on evolving conditions. The previous recommendation appears to hold merit regardless of the current technology evolution stage. "If the data is changing, economics dictate to back it up relative to the dynamics of the frequency and volume of change." This adage also applies to the virtual machine construction. As the applications or operating systems change, make backups to reflect the dynamics and frequency of those changes. Keep in mind that someday you'll be called upon to restore those recovery images and, as always, time and technology will be your enemy. In order to reduce the effects of time and technology, minimize the risk of exposure to both. Maintain virtual disks of your operating virtual machines on multiple media at multiple sites. With the multiple Ms in place, your likelihood of success increases as your risk exposure declines. Due to the nature of virtual machine images, transportability equals mobility to unlike technology on disparate facilities in a very small timeframe. VMware produces an excellent backup guide for ESX Server that addresses many detailed levels and corresponding backup strategies. In addition, additional documentation and support resources can be found at the following links: www.vmware.com/pdf/ESXBackup.pdf www.vmware.com/support/resources/esx_resources.html www.vmware.com/support/esx25/doc/esx25admin_backupvm.html
12.4.2. Planning Backup planning should include the following consideration points:[4] [4] VMware Education Services, Virtual Infrastructure with ESX Server and VirtualCenter, Student Manual, ESX Server 2.5 and VirtualCenter 1.2
Planning What needs to be backed up and how often? This planning must include consideration of physical restoration, environmental capabilities, backup technology limitations and capabilities, and any regulatory requirements based on your operational industry and types of data. Installation of backup agents into the Service Console and virtual machines Are backup agents going to reside in the Service Console, the virtual machine, or both? Costs in terms of technology, and operational efficiency must be considered in each installation opportunity. Can the server (physical or virtual) support the hardware or additional service load? Can the backup application and transport medium support the VMFS file structure? Can the backup operations be completed within the maintenance window based on the technology used and the size of the files being backed up, coupled with the frequency of the backups and the availability of the server in the production environment? Restore Where will backup data reside? Are the local backup path, online storage device, or offline remote media identified? What technology is used to store the data? Are the tapes' capacities capable of unbroken data backups? Does the SAN technology support virtual machine deployments? Can the SAN technology support remote site replication and does this replication support VMFS file support?
12.4.3. Boot Disk Contents Store the operating system of a virtual machine in a dedicated VMFS partition, separate from all other data and application data. This enables the following: A smaller VMFS operating system partition for faster cloning, exporting, and backing up Separate backup policies for the VMFS operating system partition and the VMFS data disks Increased reliability and scaling of backups
12.4.4. Backup Schedule There are four major components of ESX Server that should be backed up regularly using an agent in the Service Console. There is an additional, optional component to back up if you require backup and recovery at the file level. All are listed in priority order in Table 12.2, with recommended backup and archive policies. Table 12-2. Backup Schedule Considerations[5]A Backup Agent | What to Back Up (in Priority Order) | Recommended Backup Policy | Recommended Archive Policy |
|---|
Service Console | 1. Data disk image [6] .vmdk of each virtual machine (.vmdk file containing application and other data) | Daily backup with real-time data replication | Weekly full backup | Service Console | 2. Boot disk image of each virtual machine (.vmdk file with the boot image of each virtual machine) | Weekly differential backup | Weekly full backup | Service Console | 3. Directory for virtual machine's configuration files, such as /root/vmware or /vpx/vms | Weekly differential backup | Monthly full backup | Virtual Machines | 4. Data files in a virtual machine | Daily incremental backup | Weekly full backup |
[5] VMware Education Services, Virtual Infrastructure with ESX Server and VirtualCenter, Student Manual, ESX Server 2.5 and VirtualCenter 1.2
[6] VMware Education Services, Virtual Infrastructure with ESX Server and VirtualCenter, Student Manual, ESX Server 2.5 and VirtualCenter 1.2
|
