VMware vSphere Backup Best Practices

There is no question that backing up your VMware vSphere virtual machines is an absolute necessity.  If you aren’t backing up your vSphere environment, you are asking for trouble.  However, even, if you are backing up your environment, there are several basic best practices you want to make sure you are following with VMware vSphere backups.  You want to ensure you are getting the most effective backups possible.  Additionally, you want to ensure your backups are valid, efficient, capturing application data correctly, secure, and automated in such a way that the process is automatic and without human error or mishaps.  Let’s take a look at VMware vSphere Backup Best Practices to see key areas to take note of when architecting your VMware vSphere backup solution.

VMware vSphere Backup Best Practices

Following the recommended best practices when it comes to backing up your VMware vSphere environment is certainly a great way to ensure your data is properly protected.  VMware vSphere best practices include areas where IT admins can ensure that backups are good, and most importantly, restorable.  Let’s take a look at the following:

• VMware snapshots are not backups
• Use Image-Level backups
• Use application-aware backups
• Use Changed Block Tracking CBT
• Encrypt VM backups
• Verify VM backups
• Create Offsite backup copies

Let’s take a closer look at each of these one-by-one and see why they are important.

VMware Snapshots Are Not Backups

You are making a huge mistake if you view snapshots of your VMs as an actual backup of your data.  Snapshots do have their place and are a great mechanism for quickly rolling back to a known good state.  I use snapshots often and they are a great tool to have and make use of.  However, snapshots are not backups.  Why is this the case?

The key reason snapshots are not backups is in the design of how they actually work.  A snapshot is a deltadisk and a memory state file that get created to represent the way a VM looks at a specific point in time.  All writes past the snapshot creation are written to the delta disk.  However, the snapshot disk is dependenton the parent disk and any other previous snapshot disk in the snapshot chain. 

This means if any part of the chain of disks becomes corrupt, the entire chain is corrupt.  Additionally, snapshots are stored in the same environment as the normal VM files (configuration, disk files, etc).  This means if anything happens to the underlying production infrastructure, your snapshots are gone along with the normal VM disk files. 

A backup by its very definition should not be dependent on any part of the production infrastructure to get your data back in a worst-case scenario.  It should be a completely standalone copy of data that can completely recreate your data, including the parent VMs it relies on.

***Note*** Many modern, true backup solutions utilize snapshots as part of each backup iteration to redirect writes so that data can be copied from the base VMDK over to the backup repository.  This is not the same as using snapshots as a form of backup since it is only a temporary mechanism and the data is not permanently stored as a snapshot.

Do not use snapshots as a form of VMware vSphere backup

Use Image-Level Backups

An image-level backup is a backup that is taken of a VMware virtual machine at the vCenter Server or ESXi host level.  It does not require an agent to be installed inside the virtual machine.  The advantage of the image-level backup is that it interacts with the host or vCenter Server to capture the entire VM, including the VM settings, configuration, etc. 

Restoring an image-level backup of a VM means the VM itself will be recreated, along with the configuration so you don’t have to do this manually.  Creating image-level backups saves time, is more efficient, and allows automatically adding VMs that are added to the host or vCenter Server by default. 

There are some corner cases still where you may want to have an in-guest backup agent, however, these are becoming few and far between.  The image-level backup is certainly the way to go when it comes to creating VM backups at scale.

Adding VMs at a vCenter Server (image-level) for backup

Use Application-Aware Backups

Virtual machines are not important in and of themselves.  It is the resources and data they host that are truly valuable.  Virtual machines may host applications served by SQL Server, Exchange Server, Active Directory, or SharePoint.  These applications are database driven applications that rely on the data being and staying consistent. 

Database driven applications present challenges for backing up your data since there could be data remaining in memory or other pending I/O that has not been written to disk when a backup operation takes place.  If a backup captures the data on disk without any knowledge of the pending I/O and in memory data, the database will be in an inconsistent state.

You want to choose a backup solution that is application aware which means it properly interacts with Microsoft’s VSS technology to flush all data to disk as the backup of the data is taken.  This will mean the data is kept consistent for backup purposes.  This also means there are no additional steps required once a restore is performed.  Each restore point will be application consistent. 

Enabling application-aware processing for a VM backup job

Use Changed Block Tracking CBT

Changed block tracking provides tremendous advantages when it comes to backing up data in a vSphere virtual environment.  VMware’s CBT technology allows vSphere to track the changes made at the VMDK block level.  Changed block tracking or CBT can be used by data protection solutions to track changes that have been made with each backup iteration once a full backup has taken place.

You can see how this is extremely beneficial since your backup solution can only copy over the changessince the last backup, not a full backup.  This is vastly more efficient, leading to reduced backup storage and backup time windows.  You want to make sure your backup solution can support VMware vSphere CBT to utilize this feature to greatly improve efficiency of backup operations.

Encrypt VM Backups

Securing your VM backups is extremely important.  When you think about the data that is contained in production backups, it is production data, meaning if someone gains access to your backups, they have access to your production data as well.  Encrypting your VMware vSphere virtual machine backups is a great way to bolster security on your VM backups.

There are two “states” that you want to ensure your backups are encrypted – in-flight and at-rest.  This means data is encrypted as it moves across the network and as it is stored on disk.  Either state can present vulnerabilities for your data, so encryption in both states as your data transitions from being moved to stored is important. 

Vembu BDR Suite allows creating a unique encryption password for each backup job.

Enabling Encryption on a VM backup job in Vembu BDR Suite

Verify VM Backups

Verifying backups is arguably one of the most vital aspects of data protection that often gets skipped by customers in their environments.  When backing up your VMware vSphere environment, you want to make sure your backups are valid and useable.  In other words, when you need your backups most, during a disaster, can you restore the data?  After all, backups that are not restorable are worthless. 

The problem that generally presents itself with backup verification is the time involved and the tedious nature of restoring and testing backups.  Generally, when this is left to manual human-involved processes, it will slip through the cracks every single time. 

Having an automated way to do this is extremely important.  Automation takes the human equation out of the mix and allows having a programmatic way to verify your data contained in backups is valid and is useable. 

Below is an example of an automated way to do this in Vembu BDR Suite. It has a three-step approach to verify mount, boot, and integrity. Then it automatically sends you a verification email with a screenshot of the booted VM.

Performing automated checks on a Vembu BDR Suite Backup

Create Offsite Backup Copies

When looking at the 3-2-1 backup best practice rule, having multiple copies of your backup data stands out as an underlying best practice.  Why is having multiple copies of backup data important?  Multiple copies of your backups help to ensure you will have at least one good backup copy of your production data.

Let’s think about how a data disaster involving ransomware helps to shine light on the benefit of backup copies.  If you fall victim to a ransomware attack that encrypts not only your production data but also your backup data, how would you restore your data? 

Having an offsite copy helps to ensure you have enough data diversity between production and a copy of your backups that it will be unlikely to be affected by the same disaster as in the case of a ransomware attack. 

Create an offsite backup copy to further protect your backup data

Wrapping Up

Following VMware vSphere backup best practices helps to ensure the best possible outcome for protecting your data. As shown, there are many things you can do to create the most efficient and effective backups possible in your VMware vSphere environment.

Using a backup solution that has features that allow easily implementing these best practices is certain worth considering when choosing your data protection platform. Vembu BDR Suite is one such solution that provides you with many great features and capabilities to enforce best practice methdologies.