VMware is one of the most popular choices when it comes to virtualization solutions at the enterprise level. However, using the most well-known option on the market doesn’t mean that you should forget about other important things, namely – data protection and VMware machine backups. You should always have a plan in case something goes wrong with your system or data inside the virtual machine. Accordingly, there are several recommended best practices when it comes to managing VMware backups.
An effective VMware backup is all about:
- Keeping several copies of your VM data;
- Storing your VMware backups in multiple locations;
- Providing complete copies of your systems, down to every last document;
- Being independent and not relying on any single part of your internal infrastructure;
- Having the ability to backup applications inside VM as well, such as databases, ERP, CRM ‘s, etc.
There are also some other, less obvious features, that you should keep in mind when it comes to a proper VMware backup, like data replication, data encryption, automated recovery, automated data verification, data protection on both physical and virtual level and so on.
One of the most common methods for VMware data protection are VM snapshots. Although snapshots are actually quite innovative as a technology and allow an easy rollback to a specific point in time with little downtime, there are many instances where it is being used incorrectly.
The problem with snapshot as a main backup type is that in breaches one of the main principles of an effective backup that we’ve discussed earlier – a backup shouldn’t rely on any specific part of your infrastructure. And snapshots rely heavily on the underlying virtual disk’s structure working properly.
Creating a snapshot means that you’re creating a new delta disk and writing on it everything that happened right up to the point that specific snapshot was taken – making the snapshot itself potentially completely unusable without the virtual disk’s structure to support it. It is useful for specific cases though, like indev or testing environments, to allow rollbacks after some changes have been implemented within a specific VM.
It is important to remember that snapshots are usually treated as a short-term means of backing up, since longer periods can lead to a plethora of problems, such as corruption, performance degradation and so on.
Another option is to use Bacula in tandem with GhettoVCB to back up VMware virtual machines.
The first step of doing that is to turn on the SSH service on ESXi. You can do that using the vSphere client in the configuration tab.
Your next step is the “Security Profile” line, you’ll be able to find and click the “Properties…” link there.
This tab allows you to see all of the “Remote Access” services. Choose SSH and click the “Options” button.
It will open a new window, allowing you several different start/stop options for your VMware ESXi host.
That concludes the process to allow using SSH to access your VMware vSphere. If you have connection problems after that – look at your ESXi server firewall, as shown below.
After that whole process we can begin configuring Ghetto VCB. But first, we need to download it (from https://github.com/lamw/ghettoVCB), we’re looking for a file called master.zip.
Next we’ll have to copy this file – package – to the ESXi server’s root folder (an example of the proper command is this):
scp master.zip firstname.lastname@example.org://
And then we can unzip it via SSH (example below):
Using the same command line we’re accessing the script folder we’ve just created by unpacking the archive:
Script configuration comes next in this process:
An example of the config file’s contents is below. Two lines we’re looking for are: VM_BACKUP_VOLUME part – specifies the target location of an intermediate backup, and VM_BACKUP_ROTATION_COUNT – the number of local backups to be stored.
That same config file allows you to set up backup transfer via NFS (Network file system) or using an e-mail.
You’ll have to give the Ghetto script “execute” permissions, too, if you want everything to actually ‘happen’!:
chmod o+rx ghettoVCB.sh
The last step of this setup process is to perform a test script run. Specifying the exact VM that would be backed up is possible either via -a command (this tells the script to back up all of the VMs) or by specifying the VM’s name:
ghettoVCB.sh -g /ghettoVCB-master/ghettoVCB.conf -m VM-NAME
There’s also some means of automating this process that can be done via Bacula. For example, you can tell the system to run this script after a specific amount of time has passed, or you can set it up to perform before Bacula itself performs the backup.
Since you can’t install Bacula’s client on an ESXi, there’s a way to call the specific script from another server and then copy the backup that was generated. You can even set up another backup script that would delete the Ghetto script file after Bacula is done copying the storage of your choosing.
To remotely call the script you’ll have to install sshpass. Here’s how to do it:
apt-get install sshpass
There’s a command that can be used to configure and set up for a backup job to launch the script at a specific point in time:
Name = “Backup_Esxi_VM-NAME”
JobDefs = “DefaultJob”
Client = srv-backup-fd
FileSet = VM-NAME
ClientRunBeforeJob = “sshpass -p ‘xxxx’ ssh -o StrictHostKeyChecking=no email@example.com /ghettoVCB-master/ghettoVCB.sh -g /ghettoVCB-master/ghettoVCB.conf -m VM-NAME”
ClientRunAfterJob = “sshpass -p ‘xxxx’ ssh -o StrictHostKeyChecking=no firstname.lastname@example.org rm -rf /vmfs/volumes/datastore1/backup/VM-NAME”
Schedule = vms-schedule
Priority = 10
To copy the Ghetto backup script to an another server you can use the same command we used to copy Ghetto’s archive file to an ESXi server – scp command – or you can use Bacula’s bpipe plugin that has the advantage of not occupying additional space on the target server by going straight to data backup. Since we’ve shown how scp command works already, here’s an example with the bpipe script:
Name = “VM-NAME“
signature = MD5
Compression = GZIP1
Plugin = “bpipe:/mnt/bkp_VM-NAME.tar:sshpass -p ‘xxxx’
ssh -o StrictHostKeyChecking=no email@example.com /bin/tar -c /vmfs/volumes/datastore1/backup/VM-NAME:/bin/tar -C /backup/bacula-restores -xvf -“
This command sequence allows Bacula to restore the backup on the same machine that has the client installed (/backup/bacula-restores). The restoration process is somewhat similar, you’ll have to use Ghetto’s restore script (ghettoVCB-restore.sh) and copy the backup files to the ESXi server for the purpose of importing everything back to vSphere.
Your VMware backup needs can be better met with Bacula Community – the main principle behind it being the installation of a Bacula File Daemon on each VM (virtual machine) in the system, in the same way you would do as if they were actual physical servers. To prevent overloading your system and optimize the I/O usage when it comes to your VMware ESX(ESXi) servers, you can use Priority, Schedule and Maximum Concurrent Jobs – this should prevent the system from running all of the backups at the same time. You might run into a situation when your network/disk subsystem would overload – creating a bottleneck of sorts.
By treating your VMs like physical servers and installing bacula-fd on each of them you’ll benefit from a number of especially useful features, such as job verification, individual file restoration, file level compression for your data, and so on.
If you’re also interested in Windows Backup, check out the Bacula’s solution.