To set up the environment, configure the setup source and recovery sites, as
I discussed earlier. Install the supported backup agent on the service console
of each ESX Server host (both source and recovery ESX Server systems). On the
source side, configure your backup server and device (disk or tape) as follows:
- Configure the backup server to use the backup device and install the appropriate
drivers and backup server software of choice.
- Ensure that networking is configured for access between the backup server
and VMs that will be backed up. If both the VM to be backed up and the backup
server are on the same ESX Server host, you should use a private virtual switch
to connect them.
- Create and schedule the backup jobs based on a recommended policy, as you
see in Table 4. The probability that
data disks assigned to each VM will change frequently is high. Therefore,
I recommend a daily incremental backup. The boot disk image of a VM might
not change as frequently and should be backed up at least once a week. Changes
to the
ESX Server service console are minimal, so the backup policy in this case is
totally up to you. If possible, power off the VM prior to the backup. Remember
to back up the folder containing each VM.
Test a sample restore of the virtual disk images from the source VM to the
appropriate VM on the recovery ESX Server machine. Be sure to restore the set
of files in the proper directory location in the recovery ESX Server system.
Next, you'll need to register the VM. Using the VMware VI client, connect to
the recovery ESX Server machine. Select the host, go to the Configuration tab,
and select Storage. In the list, right-lick the data store and choose Browse
Datastore to access the Datastore Browser dialog box. The right side of the
dialog box displays the file system on the datastore. Navigate the datastore's
hierarchy in the Folders tab. To register the VM, you'll need to navigate to
the configuration (.vmx) file, right-click it, and choose Add to inventory.
If necessary, you can modify the VM's network configuration. Now, you're ready
to power up the VM.
Note that from the ESX Server service console, you can view and manipulate
files in the /vmfs/volumes directories of mounted VMFS volumes by using ordinary
file commands, such as ls and cp. Although mounted VMFS volumes might appear
similar to any other file system (e.g., ext3), VMFS is primarily intended to
store large files, such as disk images with sizes as large as 2TB. You can use
ftp, scp, and cp commands to copy files to and from a VMFS volume—as
long as the host file system supports these large files.
Host- or Server-Based Replication
In general, file-based replication mechanisms replicate data asynchronously
over the IP network while maintaining write order. There are two basic implementations
of file-based replication. The first involves loading an agent in the VM. This
method permits file-level changes to the OS, as well as the replication of data
through the IP network to a preconfigured virtual host in the recovery site.
Then, the duplicate files at the target server are updated. Thus, only real-time
byte-level changes travel across the IP connection. The other implementation
is through the replication of the actual set of files that comprise the VM (e.g.,
virtual disk, configuration). With either implementation, remember that if activity
to disk isn't quiesced for replication, the replicated copy will be in a crash-consistent
state. Products such as Double-Take Software's Double-Take and EMC's RepliStor
integrate with Microsoft's Volume Shadow Copy Service (VSS), which makes the
creation of application-consistent snapshots possible on a secondary server—
allowing recovery of Windows data and applications in the event of corruption
or disaster on the source server.
To set up the environment, configure the setup source and recovery sites, as
I discussed earlier. Next, install the replication application and agent on
both the source VM and the corresponding VM in the target ESX Server system.
Create a replication job, specifying the files and directories to be replicated
and the frequency. After initial replication, perform a simple test to confirm
that the selected files and directories and changes are being propagated over,
and that the data is correct.
Testing Is a Must
Initial and regular testing is necessary to ensure that you're indeed prepared
for disaster. Some best practices to keep in mind include testing your documentation
and always keeping it up to date, testing your restore and failover procedures
and determining whether they meet your business objectives, and testing your
fail-back procedures. As requirements and technologies change, you might need
to revisit your current implementation and modify your disaster recovery plan,
architecture, and process.
I've walked you through the various options for applying virtualization technology
to disaster recovery in an environment that uses local SCSI storage. Every environment
is different, and as such your final solution can be a hybrid of the alternatives
I've presented. Even though server virtualization can address a lot of the complexity
and rigidity of a physical infrastructure, proper planning, architecture, and
testing are vital to achieving your business continuity and disaster recovery
objectives.
End of Article
Prev. page
1
2
[3]
next page -->
