This best practice guide goes through the VM Backup features explaining their use and the optimal way to configure them in order to make the best use out of the software.
You will need to adapt this to your specific environment, especially depending on how much resources you have available, however this guide takes you through the most important configurations that are often overlooked too.
Setting up the VM Backup Management Console
The VM Backup Management Console can be utilised to add and manage multiple hosts in one console. However these hosts must be in the same LAN and at the same physical site (same building). Setups with multiple physical sites must have an instance of VM Backup at each site.
To manage these multiple installations, you can utilise the 'Central Monitoring Console' where you'll be able to monitor as well as manage these VM Backup installations remotely.
A single VM Backup instance can manage both Hyper-V & VMware hosts.
For optimal results, VM Backup runs some maintenance specific tasks using (multiple) single threaded operations. For this reason installing on a machine which has a CPU with a higher single thread performance would yield better results than installing on a machine which has a CPU with more cores and lower single thread performance.
Thus for the fastest results, installing VM Backup on a machine with a higher single thread CPU speed would be best.
Backup Locations
Make sure Opportunity Locks (Oplocks) are disabled if the backup location is a NAS.
If your backup location is a Windows machine, the equivalent to Oplocks is: Set-SmbServerConfiguration -EnableLeasing 0
Run the above command via Powershell.
Offsite Copies
With VM Backup, you are provided with the functionality of an Offsite Copy Location, which is a redundant/secondary copy of your backups. You can even backup your VMs to 2 different offsite copy locations for further redundancy of your data, so you can pick a cloud location as well as an Offsite Backup Server for instance.
There are multiple options for setting this up:
- You can choose a Physical Drive connected to the management console
- Drive Rotation/Swap which allows you to set up a pool of drives/network paths
- A Network Path (LAN Only) or else to an offsite location via a WAN/VPN/Internet connection, which is an ideal tool for Disaster Recovery purposes. Please note that the latter situation (non-LAN) requires use of the Offsite Backup Server
- Backup to Microsoft Azure, Amazon S3 or Wasabi.
Setting up an offsite copy location is as crucial as setting up backups to a primary location. Apart from the obvious reason that you'll have a redundant set of backups to restore from, should the local backups become unusable due to disk corruption or other disk failures. Having a secondary copy of your backup sets also allows you to keep a broader history for your VM backups on your secondary location and you'll be able to go further back when restoring if required.
Protecting against Ransomware (Immutable backups)
It is highly recommended to take proper measures to avoid getting affected by ransomware attacks, which can potentially encrypt also any backup sets you have. VM Backup v9 offers the ability to take offsite backups and set them as Immutable for a specified amount of time, this will ensure your offsite backups cannot in any way be modified/encrypted by an attacker or automated ransomware attack.
Deduplication
VM Backup makes use of Augmented In-line Deduplication. This is automatically enabled as this will essentially ensure that any common data blocks across virtual machines are only written to the backup location once. This helps by saving a considerable amount of space and also makes backups much quicker since common information is only transferred once.
Boot From Backup
The Boot From Backup drive feature comes along with 2 options, either 'Verification Mode' or 'Recovery Mode'. This is a very good option for getting your RTO down since you're able to boot up the VM immediately from a backup location and start a restore in the background as well.
However it's very important that if you are planning to do this, you'll need a fast backup location that can handle the I/O of a booted VM that's essentially going into production. Please note that when the VM has finished restoring, it's suggested to restart the restored VM as soon as you get a chance in order to switch to the restored drives, which would have faster I/O throughput.
Notifications
E-mail notifications are a simple and effective method of monitoring the backup status, yet it’s often overlooked. Setting up these notifications will provide you with a quick overview of the status of your backup jobs, hence – you won’t need to login into the Management console every day to confirm the backup status.
This way you’ll be alerted of any backup failures, allowing you to address said issues before the next backup schedule. Thereby ensuring that you always have a restorable backup point; so as a general best practice, always monitor your backup notifications.
Master Encryption Key
The Master Encryption Key in VM Backup is utilised to encrypt the backups using AES 256-bit. It's used if you choose to encrypt the local backups from the 'Advanced Settings' screen, while if you're configuring offsite copies it must be used as offsite copies must be encrypted.
VM Backup will require the encryption key upon restoring, so it's critical that you either remember it or take note of it in a secure password manager as there is no method of recovery for the master encryption key.
Scheduled Test Drills
VM Backup has the ability to run manual or automated verification of your backup data. This allows you to run scheduled verification jobs that will check the integrity of your backups on your backup location, or schedule full VM restores so that you can actually boot up the VM and confirm that everything works as expected. The VM will be restored with the NIC disabled so as to avoid IP conflicts with the production machine as well.
Failure of storage devices is not uncommon, therefore scheduling test drills is strongly advised for added peace-of-mind. Full instructions on configuring test drills.
Other General Best Practices
- Backups and production VMs should not be placed on the same drive
- Make sure Opportunity Locks (Oplocks) are disabled if the backup location is a NAS
- Backups should not be placed on a drive where an OS is running
- VM Backup uses the drive it’s installed on as temporary storage and will require a small amount of free space (varying according to the size of the VMs being backed up)
- Keep at least 10% of the backup location free
- The main VM Backup installation cannot be installed on a machine that is also a domain controller (DC)
- Directories/files inside the VM Backup backup folder should not be tampered with, deleted or moved
- Do not take snapshots DFSR databases: "Snapshots aren't supported by the DFSR database or any other Windows multi-master databases. This lack of snapshot support includes all virtualization vendors and products. DFSR doesn't implement USN rollback quarantine protection like Active Directory Domain Services." Source.
Best Practices for Replication
Exclude Page File from Backup
As you're aware VM Backup will take note of all changes since the last backup and transfer over all of the blocks that changed to the backup location. The page file will be changing very often and potentially causing your replication jobs to take longer.
Therefore, excluding the page file from backup equals, less transferred changes and as a result the replication jobs take less time. This can be done by placing the page file onto a separate VHDX/VMDK file from the VM itself and then you can follow the steps here, in order to exclude the VHDX/VMDK file.
High Disk IO and Hypervisor Performance
Replication needs to make use of CDP (Continuous Data Protection), in order to take a backup every couple of minutes/hours, which makes Replication possible.
It's important to note however that you should only enable high-frequency CDP (15 minutes or less) on VMs that you really need to. This will ensure that the VMs you really need to will be able to achieve the selected maximum frequency and in order not to have an impact your Hypervisor's performance.