WIXLIB

4959 Ch07 CMP34/20/055:30 PMCHAPTERPage 2237 Backing Up and RecoveringVirtual MachinesFor virtual machines running in a production environment, backup and recovery is just asserious as for all the other servers on the network. When running servers inside VMs, you’ll befaced with several new challenges, as well as advantages, when planning and implementing abackup strategy.In this chapter, you’ll explore the process of planning for and administering backup andrecovery operations on VMs and VM hosts. Along the way, you’ll see the different approachesyou can take to secure VM data, which include the following: Traditional agent-based backups Non-agent-based backups Flat-file backupsAlso, many organizations have embraced the idea of maintaining a warm standby VMserver that can be brought online if a primary server fails. This approach, for many organizations, may mean that data is unavailable for a few minutes following the loss of a server. If youcan’t afford to cluster all your systems, or if some of your applications don’t support clustering,then you may find this approach to be a perfect fit. Since the focus of this chapter is purely onVM backup and recovery, we’ll walk you through the process of maintaining a standby VMserver in Chapter 14.Optimizing your backup strategy often means much more than simply installing softwareand letting it do its magic. Oftentimes, custom scripting is required to get the backup resultsyou desire. Because of the importance of getting your virtual infrastructure to work aroundyour needs (instead of the other way around), we’ll also show you several scripting ideas toboth enhance and automate the backup, recovery, and availability of your VMs. Let’s startwith the most common production backup method today—running agent-based backups.223

4959 Ch07 CMP32244/20/055:30 PMPage 224CHAPTER 7 BACKING UP AND RECOVERING VIRTUAL MACHINESPerforming Traditional Agent-Based BackupsAs VMs perform write operations, some data winds up in the host system’s physical memorybefore it’s passed to a virtual disk file on the hard disk. This architecture is common in boththe VMware and Microsoft products, and as a result, neither vendor supports online backupsof virtual disk files. Instead, both strongly recommend you install backup agent software onthe VMs in order to back them up, as opposed to running a single backup agent on the hostsystem.Installing backup agents on your VMs is the only surefire way to guarantee the reliabilityof backing up their virtual disk files. Keep in mind, however, that there’s more to a VM thanjust its disk files. Each VM has configuration files too, and these files should be backed up bya backup agent running on the VM’s host system. Note All the major backup vendors, including EMC (Legato), Veritas, CommVault, and Computer Associates, have performed testing at some level with their backup agents and virtual machine software. Youshould find that the backup agent will behave as if it’s running on a physical system, with no awarenessof the VM software that’s hosting the virtual machine.If you don’t have an enterprise-class backup software suite but still need to run VMs 24/7,then you could use the backup tool included with each OS to back up your running VMs. Forexample, you could use Windows Backup to back up Windows VMs and could use the dumpcommand to back up Linux VMs. Each of these scenarios is described later in the “PerformingNon-Agent-Based Backups” section, but first let’s take a look at agent-based backups.Running Backup Agents on VMsRunning backup agents on VMs is the preferred method for backing up virtual disks, accordingto both Microsoft and EMC. A backup agent is software that runs as part of a backup softwareapplication, allowing you to back up a system either over the LAN or through a storage networkto backup media.When backing up VMs, several considerations will directly affect backup and recoveryperformance. When planning your backup infrastructure to include VMs, you have three primary architectural choices: Backing up over the LAN Backing up to the host Backing up directly to storage (local or SAN-attached storage)Let’s first look at the traditional LAN backup configuration.

4959 Ch07 CMP34/20/055:30 PMPage 225CHAPTER 7 BACKING UP AND RECOVERING VIRTUAL MACHINESBacking Up over the LANMost organizations today employ LAN-based backups. With this technique, backup data issent over a network from the system being backed up to a system acting as a media server. Themedia server provides a physical interface between the systems being backed up and the storage hardware, such as a tape library. Figure 7-1 shows this configuration.VM HostVirtual MachinesLANMedia ServerVirtual NetworkLibraryBackup DataFigure 7-1. Backing up a VM over the LANWith a LAN-based backup architecture, you could either network the VMs directly to themedia server using bridged networking or have the VMs connect using a host-only networkand route through the host to the media server. If the VMs are routing through a host system,remember that the media server will also need a static route present (or have the LAN router’sroute table updated) so that the media server can route back to the virtual machine. If routingisn’t one of your strengths, then we recommend going with bridged networking to connectyour VMs to the media server since this is the easiest scenario to configure. Caution You can’t use NAT to connect VMs on a private network to a media server. While the VMs couldcommunicate to the media server through NAT, the media server wouldn’t be able to directly communicatewith a VM on its private IP address.225

4959 Ch07 CMP32264/20/055:30 PMPage 226CHAPTER 7 BACKING UP AND RECOVERING VIRTUAL MACHINESFor those of you who want to have their VMs on a private host-only network, then let’s consider a sample configuration. Assume the VM being backed up in Figure 7-1 has an IP address of192.168.2.11/24. Now consider that the VM’s host system has IP addresses of 192.168.2.1/24 (virtual interface) and 172.16.1.20/24 (production LAN interface). Finally, let’s assume the mediaserver has an IP address of 172.16.1.19/24. For the backups to work between the VM and mediaserver, both systems will need to know how to route to each other. With the VM, this should beeasy since you could just assign it the gateway address of 192.168.2.1. However, the media servermay already have a default gateway on the production LAN with no knowledge of your privatehost-only network. If this is the case, you can assign a static route to the media server so that itknows how to reach the VM’s host-only network. For the VM to reach the private network, itsdata will need to go through the production LAN interface of the VM’s host system. So, at thispoint, you have all the information needed for creating a static route on the media server, whichincludes the following: Destination network: 192.168.2.0 Subnet mask: 255.255.255.0 Gateway address: 172.16.1.20If you need a quick refresher on classless interdomain routing (CIDR) notation, remember that it’s a means to represent a subnet mask as a single decimal value. So, the /24 thatfollows each IP address represents the number of consecutive binary 1s in the subnet mask.Since there are 8 bits in an IP address octet and since there are twenty-four 1s, you have threesets of eight consecutive 1s. If you convert eight consecutive 1s (1111111) from binary to decimal, you get 255. Note If you’re still craving more information on binary numbering, routing, and TCP/IP subnetting, pointyour Web browser to http://www.learntosubnet.com.With this information now in hand, you can configure static routes on the media server.You do this using the route add command on either Windows or Linux systems. Here are sample commands to run if the media server is running on either a Windows box or a Linux box: Windows: route add – p 192.168.2.0 mask 255.255.255.0 172.16.1.20 Linux: route add –net 192.168.2.0 netmask 255.255.255.0 gw 172.16.1.20With the potential routing issues now behind you, you should have connectivity betweenyour VM and the media server. If both systems allow ICMP requests, you should be able to runping commands to test for the network connectivity between the two systems (for example,run ping mediaserver from the VM).

4959 Ch07 CMP34/20/055:30 PMPage 227CHAPTER 7 BACKING UP AND RECOVERING VIRTUAL MACHINES Tip If your backup software’s architecture includes a central management server that initiates andmanages all backup and recovery operations, ensure that network connectivity also exists between eachVM and the management server.At this point, you should be ready to install backup agents from your backup softwarevendor inside the VMs and to perform backups. With this architecture, it’s likely that the LANmay become a bottleneck for backup data streams. For example, a 100Mb/sec LAN providesfor 12.5MB/sec (100Mb 8) of bandwidth, which translates to 45GB per hour (12.5MB 60seconds 60 minutes). Although this may seem like a pretty large number, it can be significantly reduced if multiple backups are running simultaneously and having to share thebandwidth of the media server’s network interface. One alternative to solve a network bottleneck is to upgrade the network to 1Gb/sec or higher bandwidth. Another alternative is toconfigure the VM host system as a media server. We’ll cover that option next.Backing Up to the HostWhen VMs are configured to back up directly to the host, no backup data has to traverse theproduction LAN. Figure 7-2 illustrates this configuration.Virtual MachinesLibraryLANVirtual NetworkBackup DataFigure 7-2. Backing up a VM through the VM host227