Requires Free Membership to View
- Do you need file-level restore, or do you have time to restore the entire VM if needed?
- How often will a restore be required?
- How much data is being backed up?
- What type of data is being backed up--flat files, databases, applications?
- How frequently does the data change within the VM's disk(s)?
- What is the value of the application, the data, and the VM to the overall recovery objective of the organization?
- How can you ensure integrity of the data at the point of backup so the restore is valid?
- What type of storage does the VM house (SAN, NAS, iSCSI) and what intrinsic features of the storage array can be integrated with the backup processes?
- What backup software, processes and alternatives are already in place in your organization?
In general, if you need to restore at the file level, take frequent backups, integrate with snap/clone technology from the storage array, and/or are backing up large amounts of data, go with the agent within the VM. If you can live with longer restore times, don't need the granularity of selecting specific files for restore, and/or have a large amount of VMs with smaller footprints, you can back up off of the ESX to offload that from the VM performance, or copy those images from the storage array in their entirety to tape or disk.
This was first published in March 2007
Virtualization Strategies for the CIO

Join the conversationComment
Share
Comments
Results
Contribute to the conversation