Clone Freedom

Testing and Optimizing

To discover whether XSIBackup is working, you can run an initial replication with the --test-mode=true option. You can thus verify the functionality of the backup setup without actually initiating a replication:

./xsibackup --backup-point=<path> --backup-type=running --test-mode=true

In addition to any errors and warnings, XSIBackup also shows the space required to replicate the VMs and the free disk space on the target host. If the target is a remote host, a simple path definition as the --backup-point will not work; instead, you need to specify the site like this:

--backup-point="<target_host_IP>:22:/vmfs/volumes/<datastore>"

It is also important to ensure that a connection is set up successfully in advance using

./xsibackup --link-srv=<target_host_IP>

Additionally, you can stipulate that XSIBackup store the various backups in separate subdirectories named for the date of the backup using the --date-dir=yes option. As already mentioned, the backup software can automatically send email with a status message. The settings for this are also configured through command-line options (Listing 1).

./xsibackup --backup-point=/vmfs/volumes/backup --backup-type=running --mail-from=<sender> --mail-to=<receiver, comma-separated_list> --smtp-srv=<email server> --smtp-port=25 --smtp-usr=<login_name_on_server> --smtp-pwd=<password> --subject=<subject>

If the SMTP server requires a TLS connection, the --smtp-sec=TLS option is important. Moreover, you can add the SMART status of the ESXi host disks to the email report. To enabled it, use the --smart-info=yes option. For regular backups, the status should be added to the email report on at least one day of the week.

Backing Up on the Fly

XSIBackup offers several ways to customize the software to suit your individual needs. For example, the solution replicates VMs on the fly from the source to the target host by default; however, you have the option of switching off the virtual machines before the backup with the --backup-how=cold option. If you use this option, XSIBackup sends the command to shut down the VM and waits for 30 seconds. After that, the tool tests to see whether the shutdown was successful. If the VM is still running, XSIBackup waits another 30 seconds. If XSIBackup then determines that the VM has still not shut down, the backup tool kills the VM.

For this multistage process, the VMware tools must be installed on the virtual operating system. If the VMware tools are not available on the VM, XSIBackup will not even attempt a graceful shutdown but will immediately bring the virtual machine to a halt. This procedure is not recommended, because it can lead to data loss.

Conclusions

XSIBackup cannot replace a full backup of your virtual servers, but it can provide valuable assistance for replicating your most critical VMs to other hosts on the network or dumping backup copies on a network-attached server. After a failure of the source host, only minor adjustments are necessary to put the VMs back into operation on the target system.

XSIBackup is flexible in terms of controls, and scheduling helps you implement individual backup plans (Figure 2). The only option XSIBackup does not offer is a complete restore of the previously backed up files in the style of a classic backup tool.

Figure 2: The complete configuration of XSIBackup is handled in a shell on the ESXi host.