©XSIBackup-App, achieving parallelization on multi-server backups

How to perform multiple backups and replicas at the same time to reduce backup windows

In the beginning we created ©XSIBackup as a service running in the very ©ESXi server. This came very handy for many types of setups, but...

If you needed to backup multiple ©ESXi hosts you had to install ©XSIBackup to every box and as soon as you had a few of them management would become cumbersome, as you would need to do so per host.

Then we came up with ©XSIBackup-App, which allows to manage multiple servers from one centralized console. That solves the hassle of having to manage many hosts independently but it still has the drawback that all data has to go through the appliance's NICs.

Those of you having many servers to backup still have a bottleneck caused by the very appliance acting as a hub through which all data has to go through.

Parallelization

The solution to the above problem is allowing some sort of parallelization. Running multiple jobs at the same time can be a solution, adding more NICs to the appliance will offer more throughput, but that will only work if you have 10gbps network hardware, as 1gpps NICs will saturate at 100MB/s, theoretically, usually much less than that.

Thus the most efficient solution poses itself rather evidently: if the appliance delegates the backups to the managed hosts and they manage their backup jobs on their own, then many backups can run at the same time.

This poses other type of issues, like having the kind of network hardware that can handle the load, at least for the first backup cycles, as the subsequent ones will generate little data throughput due to the differential features of ©XSIBackup, both delta algorithm based or CBT based.

On addition the backup server will also need to have a more than decent throughput to handle the avalanche of data that might need to get into it from time to time, specially on first runs of backup jobs that need to copy all the data in the virtual disks.

In any case, it seems rather obvious that using some kind of job delegation to the managed hosts allows a much greater degree of parallelization. You just have to consider the number of CPU cores available to accomplish the task when comparing jobs centralized in the appliance to jobs distributed to the managed nodes.

Job delegation, the --delegate argument

In ©XSIBackup-App 2.1.0.0 we have introduced the --delegate argument, which does just that: it passes on the job to the managed host so that it takes care to perform the backup.

How does the --delegate argument work

When you add the --delegate argument to a job, the appliance will take care to install a copy of ©XSIBackup-DC to it and also copy all the auxiliary files required for ©XSIBackup-DC to work at the host, namely: the license file, RSA key, SMTP config, the accepted EULA file, etc...

This is an almost immediate process as the full package is barely 2 MB in size. Adding the --delegate argument will also add the --oprogress argument, so that a progress file is created for the GUI to track the backup evolution.

So, the main flow of data, namely: the virtual disks being backed up, will be from the managed host to the backup server. If you schedule your backups to be launched at the same time they will be run in parallel.

You can also use some local disk in every managed host as the target for your delegated backups. We don't limit the possibility to create delegated backups that copy data to a local disk.

Since version 1.1.0.1 you can use the GUI to select a local disk on the managed host. Of course you can choose any volume local to the host to be backed up, it can be NFS iSCSI (replicas only).

The backup volumes (light green in the above figure) can be local disks or NFS volumes in some other server. Backups to local disks aren't recommended, as any disaster affecting the host will likely damage any locally attached disks. The advantage of that approach is that you will not saturate your network.

As you can see the --delegate argument will work out of the box for backups made over IP, which are recommended for being faster. Delegation of local backups is also possible. In case of local backups, if you stick to standards, like having some /vmfs/volumes/backup dir in every host, you will obviously make your life easier.

Delegating a job means that the job will be run at the managed ©ESXi host, yet the output will be saved to the appliance's /home/[username]/.xsi/var/log/a.b.c.d._xsibackup.log, only after the backup completes.