Last updated on Tuesday 11th of July 2023 02:47:00 PM
©VMWare ©ESXi Backup made easy with ©XSIBackup-App
Backup multiple ©ESXi 5.1 to 8.0 servers from one centralized console.
Licenses for ©XSIBackup-DC and ©XSIBackup-App are interchangeable. You can use your license keys in any of the software or in both at the same time. Buy your licenses here
What is ©XSIBackup-App?
©XSIBackup-App is our new appliance designed to replicate and backup multiple ©VMWare ©ESXi servers from one centralized point of management.
It includes ©XSIBackup 2.0, which is our latest and most advanced solution in ©VMWare backup and replication. All arguments and functions remain the same, thus ©XSIBackup-DC Manual is the main document describing the use of ©XSIBackup-App.
As already explained in our previous post "©XSIBackup 2.0, what's new", the appliance introduces one new dimension, namely: the possibility to replicate and backup VMs in multiple ©ESXi servers from one centralized point of management.
To satisfy this new dimension a few new arguments have been added to the repertoire. As you can imagine these arguments are there to point at the server you want to act on. Thus, the most important of the new arguments is the --backup-host argument, which points at some previously linked ©ESXi host where the VMs you want to backup are sitting.
You can download ©XSIBackup-App from Sourceforge.net as a .tar.gz package. Installing is very simple: copy to the desired datastore root, uncompress and register.
You can find some more detailed instructions on how to install the appliance in this especific post.
Managing backup hosts
Hosts can be linked to the appliance by using the --add-host and the --add-key actions. Once they join the appliance's realm the servers linked via --add-host can be accessed via the local file system at /mnt/XSI/srvs, where they are connected in a subfolder by their IP.
The difference between the --add-host and the --add-key actions are that --add-host puts ©XSIBackup's public key into the remote server's authorized_hosts file and uses it to connect it to the appliance's file system under /mnt/XSI/srvs using the SSHFS protocol, while --add-key just copies the public key to the authorized_hosts file but it does not mount the remote server.
Thus, servers connected with the --add-key action can be used as IP targets in the backup job, while servers connected via the --add-host action can be used as a source, they are the servers where the VMs are running. They could eventually be used also as targets, but knowing where things you want to backup are and where you want to put them is something you should have clear at all time.
The --add-host action adds the linked server to the /etc/fstab file too. In case of other file sharing protocols not directly handled by ©XSIBackup, such as NFS or iSCSI, you should take care to make the mounts persistent across reboots. The opposite argument to --add-host is --remove-host. It removes the SSHFS mount point and the associated /etc/fstab entry.
All volumes mounted to the appliance should be mounted under the following hierarchy.
You can create additional subfolders in case you add some other type of volume. Given that ©XSIBackup-App is a full file system (CentOS 7 as of May 2023), you can install any driver you want to access cloud based volumes, such as Google Cloud, S3, Azure Blob Storage, etc...
SSHFS mounts and backup speed
We recommend that you use the appliance as close in network terms to the hosts you want to protect as possible. The lower the latency the better the backup speed, as ©XSIBackup reads data in 1MB chunks by default.
Using a dedicated network segment for the backups is a must as soon as the amount of data you want to backup becomes significant. In SMEs you can make backups at night while the network is iddle, but in some other more complex environments you will have to devise your infrastructure taking backups on account.
There are different things that will affect the backup speed: latency is one of the most important ones. If you enable Jumbo Frames in your network, you will minimize its importance as an effective throughput altering factor though.
Another one is the SSH encription cipher. This is a very important driving factor when it comes to effective throughput. As recent SSH implementations do not allow to not use a cipher and the lightest ones such as arcfour and blowfish have been deprecated, we give preference to firstname.lastname@example.org whenever possible, as it's one of the lightest modern ciphers in use. It is not present in ©VMware ©ESXi 6.7.0 though.
We have optimized the appliance to achieve optimum speed, which in fact improves the average when running ©XSIBackup directly in the hypervisor, mostly due to bigger buffers.
The licensing scheme of ©XSIBackup-App is exactly the same as in the vSphere Hypervisor backup agent version. The only noticeable change is that you need to issue the license keys from a newly generated request.key file and that request.key file has to be generated from the appliance itself.
As in any other action affecting a particular host, the only difference with respect to licensing the hypervisor backup agent is that you need to add the --backup-host=a.b.c.d argument.
xsibackup --request-key --backup-host=192.168.200.233
In the exa,ple above we generate a request.key file for the ©ESXi host with IP 192.168.200.233. The request.key file is stored in the /home/root/.xsi/lic folder.
To license the above host, upload the request.key file to your license panel, download the license key file and place it as it comes out of the backup server in the same ./lic folder.
When ©XSIBackup is run directly in the ©ESXi Hypervisor, the --install-cron and --update-cron actions need to be run to make crontabs persistent across reboots. This is a limitation of the very ©ESXi OS, as crontabs, among other things, are not persistent across reboots. Thus these two actions are a workaround to store your crontabs in persistent files in the [install dir]/var/cron directory and then load them into de /var/spool/cron/crontabs/root file on every reboot.
With the ©XSIBackup-App, this is no longer an issue, thus you can store your crontabs manually in the /etc/crontab file, in the /var/spool/cron/root file, use the crontab -e command, include the crontabs in the [install dir]/var/cron directory, etc...
You can enjoy the advantage of having a complete Linux OS without the limitations of the ©ESXi environment.