Backup and DR
VM Backup Best Practices for MSPs
When it comes to data backup, it can be tempting to skip virtual machines. In many cases, virtual machines are hosted in the cloud or on high-end on-premises servers. These hosting environments have lower failure rates than other types of systems.
But the fact is that no matter how reliable the server that hosts your VMs is, the VMs can still fail. Natural disasters, human errors, malware, and other threats could all erase virtual machines or make them unavailable.
That’s why VM backup should be part and parcel of the data protection service that you offer clients as an MSP. Below, we provide some VM backup best practices.
Don’t use VM snapshots as backups
VM snapshots are a useful tool for saving a VM at a particular point in time and rolling back to it later. But they are not a backup feature.
Snapshots don’t create full copies of a VM or the data stored inside it. Nor do they provide you with an isolated instance of your VM that you can use to restore the VM later if the production environment is lost.
By all means, use snapshots if they are useful to you (which they can be in order to safeguard against issues that might arise when patching, applying updates and so on). But don’t assume that just because you perform snapshots regularly, you don’t need to perform true VM backup.
A true VM backup is a consistent copy of the VM that is stored independently of the production environment (ideally, in an off-premises environment) and that can be used to rebuild the VM from scratch at any point in time.
Use Changed Block Tracking for VMware VM
Changed Block Tracking (CBT) is an incremental backup technology for virtual machines that are managed using VMware. CBT improves the speed, performance, and efficiency of virtual machine backups.
Unless you use raw device mapping for your virtual machines (in which case CBT is not supported), or a legacy virtual machine version that doesn’t support CBT, you should definitely take advantage of this feature for VMware environments. MSP360 Backup for VMware supports CBT.
Further reading How to Restore a Hyper-V Machine with MSP360 Managed Backup
Follow standard backup best practices
It should go without saying that you should adhere to standard backup best practices when working with VM backups. But, as noted above, because VM production environments tend to be more reliable than other types of infrastructure, it can be easy to assume that you don’t need to take standard backup rules as seriously when working with VMs.
But you do. In particular, be sure that you implement these rules to your virtual machine backup best practices:
- Back up VMs to a secondary location by following the 3-2-1 backup rule.
- Keep backups encrypted to provide another line of defense against security breaches.
File-level backup for VMs
In some cases, your clients may not need an entire VM backed up, but instead need to back up just specific files or virtual disks. Backing up data this way can be faster and more efficient in cases where the files that need to be backed up represent only a small portion of the total VM data. If you are in this situation, you can easily configure file-level and disk-level backup for VMs using MSP360 Backup (which also lets you exclude any specific files, disks, or directories).
Application-aware backup in a virtual environment
If your customers’ virtual machines host Exchange or SQL Server, you should use application-aware backup for a consistent backup of databases.
Use the proper edition of MSP360 Backup (Exchange or SQL Server) to separate and manage database files.
Further reading MS Exchange Backup in a Virtual Environment Using MSP360 Backup
VM data recovery
When it comes time to restore a VM backup, there are two main approaches:
- Full restore from image-based backup: You can turn off the VM and restart it based on your image backup. This is often the simplest and fastest restore method. For more information, see this article on how to perform a full VM restore in MSP360 Backup.
- Granular recovery: In some cases, you may wish to restore only certain files, instead of the full VM. Refer to our article on file-level restore for VMware to learn how easily this can be done with MSP360 Backup. If you are working with Hyper-V VMs, see this article on file-level restore for Hyper-V.
Test VM restores
A final VM backup best practice is to ensure that you test VM restores on a regular basis. We recommend keeping a test server on hand for this purpose. Use the server to run through your restore routine in order to determine whether any problems arise in restoring data from your VM backup files (whether they are complete images, or individual files or disks).
Charging your clients for VM backup
One of the biggest questions MSPs have about VM backup is how to charge for this service. There are several approaches: Charging per physical server, per physical and virtual server, or per each server. Learn more in our FAQ:
Further reading FAQ for Managed Backup Pricing
Conclusion
No matter how reliable your production VM environments are, don’t make the mistake of assuming they are failure-proof. Follow the VM backup best practices described above to ensure that your VM backups are ready when failures occur.
Simple. Reliable.
