If something happens to the physical infrastructure your production VMs are housed on, this means your VM, including the snapshot, is gone. Also, it is not a standalone copy separate from your production infrastructure.
3 2 1 backup methodology full#
In that case, you can’t rely on the snapshot as a backup since it is not a full copy of the data.
If anything happens to one of the disks in the chain, the VM is toast as well as the snapshot. Consider the fact that a VMware vSphere snapshot is made up of a chain of delta disks that rely on one another to make a complete copy of your data.
This is not the case with a VMware vSphere snapshot. Backups should be a totally standalone copy of your virtual machine that allows restoring that virtual machine with no reliance on the production infrastructure. Let’s think about what a true backup really is. However, like everything else that you have read, snapshots are not backups. I will be the first to tell you that snapshots have their place and can be very valuable to the business in many scenarios. One of the most common scenarios that fits this description is viewing VMware vSphere virtual machine snapshots as backups. There are so many times that I have seen clients I have worked with and IT admins who assume they have what they consider to be a “backup” only to find it was not truly a backup. Understand what constitutes a backup and what does not There is no right or wrong answer for each business and these will most likely be different for every organization. Understanding both of these values in relation to your individual business is absolutely critical when thinking about the best practices to backup VMware vSphere virtual machines. Restore Time Objective defines what the acceptable amount of time your business can go without the data specified in the RPO. However, due to the amount of data, the time it takes to restore that VM might take three hours. If you have your backups configured as hourly backups, you may only lose one hour’s worth of data. This determines how much time it will take to recover your virtual machine. This should be given careful consideration from the business perspective to determine what the acceptable loss should be. Setting VM backup schedules should not be an arbitrary, “stick our finger up to the wind,” and decide how often VMs should be backed up. Following suite a backup scheduled for every six hours would be a potential for 6 hours of data loss, so on and so forth. Businesses must determine if this loss of data is acceptable. In other words, if you set your backups of a particular VM to daily backups, the worst case scenario would be that you could potentially lose 24 hours worth of data. RPO or Restore Point Objective, simply put, determines how much data loss the business is okay with. What are these? I can just about guarantee you, you will not read documentation regarding backup solutions without running into these two terms. Understand RPO and RTO and how these relate to recovery from backupĪll too often organizations configure their backups without any consideration RPO and RTO.
0 kommentar(er)
