Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »


Overview

When a failure happens, it is not just data that needs restoring, but the full working environment; in other words, disaster recovery.
Backup is an aspect of disaster recovery but not the full story; backups are a component of a disaster recovery plan. The overall goal of disaster recovery is to be able to get systems restored and running as quickly as possible, including the associated data.
The increasing use of virtualization has changed the way disaster recovery is carried out because, in a virtual world, a system can be recovered by duplicating images of virtual machines (VM) and recreating them elsewhere. In a VM environment snapshots now for an integral part of any disaster recovery plan.
Part of the planning is determining your RPO tolerance (how much, if any data or recent configuration changes you are prepared to lose)
The amount of resources that one puts into the disaster recovery program will depend on your RTO.

Server configuration changes are usually planned, are possibly under change management procedures, and the timing and predictability can likely be mostly controlled. A snapshot(s) are good for:
Scheduled (ad hoc):

  • Times when an application is being deployed and there is the possibility of development damaging my installed infrastructure.

  • Demos (Dev or Test Environment): There is a requirement to initially change and test with simulated "junk" the data during a demo and later go back to original version immediately after the demo/upgrades/updates is completed. This would occur when waiting for a regularly scheduled refresh of the environment is not acceptable.

  • Times of a scheduled change of the infrastructure (operating system upgrades/updates, hardware upgrades, etc )

Scheduled (ongoing basis)

  • Disaster recovery of the server build/infrastructure; Once a day or slightly less frequent would likely be sufficient since the environment should not change often outside of scheduled change periods above.

The retention period of Snapshots should also be considered. Following is an article from VMWARE on the use of snapshots:

Purpose

This article provides best practice information on using virtual machine snapshots.

Resolution

Follow these best practices when using snapshots in the vSphere environment:

  1. Do not use snapshots as backups. The snapshot file is only a change log of the original virtual disk, it creates a place holder disk, virtual_machine-00000x-delta.vmdk, to store data changes since the time the snapshot was created. If the base disks are deleted, the snapshot files are not sufficient to restore a virtual machine.

  2. VMware recommends only a maximum of 32 snapshots in a chain. However, for a better performance, use only 2 to 3 snapshots.

  3. Do not use a single snapshot for more than 24-72 hours. The snapshot file continues to grow in size when it is retained for a longer period. This can cause the snapshot storage location to run out of space and impact the system performance.

For long term snapshots of server(s), it is better to copy the entire VMWARE server and then document it (name, purpose, date) and save it off to a storage location.

  • No labels