Registered users
Linkedin Twitter Google+

In order to improve user's experience and to enable some functionalities by tracking the user accross the website, this website uses its own cookies and from third parties, like Google Analytics and other similar activity tracking software. Read the Privacy Policy
33HOPS, IT Consultants Download XSIBackup
33HOPS ::: Proveedores de Soluciones Informáticas :: Madrid :+34 91 930 98 66Avda. Castilla la Mancha, 95 - local posterior - 28700 S.S. de los Reyes - MADRID33HOPS, Sistemas de Informacion y Redes, S.L.Info
Alert icon This post applies to ©XSIBackup Free & Pro Classic, which have been deprecated. Consider changing to use ©XSIBackup-DC, which also offers a Pro version as an intermediate product.


Backup Job Management

This is the core of the GUI as well as the XSIBackup command line program. Here you will be able to create backup jobs, modify, schedule, run, watch or delete them. Let's see what each one of these options will allow us to do.

Backup Job Management Menu

- Add or create a new backup job. This part of the jobs' management section will guide you through a chain of forms that will allow you to enter all the program arguments that will build your backup job up. The arguments are the very same you would use in any XSIBackup job launched from the command line. Once all those input options have been collected, a backup job file will be created in the xsi-dir/jobs directory. That file is directly executable, you can call it with an absolute or relative path and it will execute the backup job stored in it. It contains the redirection to xsibackup-cron.log, so, in case you prefer to run the job file manually from the command line, instead of using the Run option in the GUI's Job Management section, you can do so this way: Execute the backup job and leave it in the background, then tail -f the log file. You will see the output in your console.

# /vmfs/volumes/datastore1/xsi-dir/jobs/001 &
# tail -f /vmfs/volumes/datastore1/xsi-dir/xsibackup-cron.log

Adding a backup job

The first step in the backup job creation process is to choose the backup program we want to use, which is the same as setting the --backup-prog argument. There are six available backup programs as described in the Man Page. Each one of these backup programs has been designed to offer different functionalities: replication, deduplication, copy over IP, etc...

XSIBackup Backup Programs

Choose where to execute the backup job

You can execute backup jobs to the host where XSIBACKUP-PRO is installed or to any other ESXi host that is reachable over IP. You do need to have previously linked your master host to that other remote server where you want your remote backup to be executed to.

Where to execute the backup job

In case you choose to execute the backup job you have just started to create to a remote host, you will be asked to provide the remote host's IP and SSH port.

Where to execute the backup job

Once you choose the backup program you want to use and where to use it, you'll be asked to select some backup options. Some of them are general, some other may be particular to your chosen program. Be careful not to select options frivolously, some of them can severely hurt your backup job's speed, like selecting SSH compression when working inside a LAN or including the guest's memory in the snapshot when it's useless most of the times.

Backup Options

XSIBackup Job Options

Depending on the backup program you choose, you will see different options available.

XSIBackup Job Options selected

Next paragraphs will delve into the different options available:

- GZIP comp on SSH tunnel: this option will only be useful when backing up over slow WANs, don't use it unless you have carried out comparative tests and you have come to the concussion that it will help you. Most of the times it will not, only in those cases like using Rsync over slow WAN to transfer a big sparse file with a lot of zeros.

- Certify backup: this is one of the most useful options in XSIBackup. Depending on the backup program you are using, it will perform different actions, which in any case, will in the end certify that your backup is correct. When used with Vmkfstools, ©OneDiff, ©XSIDiff or Rsync, it will perform a full SHA1 checksum on every backup -flat.vmdk disk, to make sure it is an exact copy of the original. When used with ©XSITools, it will perform a full check on each one of the backed up chunks of data to make sure thay are O.K.. Finally, when used with Borg, it will perform an internal Borg check of the backup, which consists mainly in the same operation, verifying individual checksums of data.

- Include the guests's memory in the snapshot: this will be useless most of the times. XSIBackup uses the backup snapshot to hold new data generated by the OS while the backup is taking place, so adding the memory to the snapshot will be useless, as it will be deleted (committed back to disks), once the backup finishes. It can be useful under some very particular conditions, but you should avoid its use unless you know the exact implications.

- Do not quiesce the VM when taking the snapshot: it is highly recommended to quiesce VMs when performing hot backups, otherwise, some of the data that programs or services may be holding at the moment of taking the snapshot could be lost. In case of DDBB services or e-mail servers, you could end up with a DDBB file in an inconsistent state. So this would only be useful when you are performing a hot backup on a file server that doesn't have any load during the backup window, or when you really don't care much if you lost some data, and you find no way to make VMWare Tools and quiescing work in that OS.

- Use a timestamped folder to store the backup: when you use this option backups will be stored in a timestamped folder YYYYMMDDhhmmss under the backup point path. This option will be ignored if the backup program stores data in a repository, like Borg or ©XSITools, or in the case of ©OneDiff, which algorithm is not compatible with subfolders. So it applies to using Vmkfstools, Rsync and ©XSIDiff.

- Force Rsync usage: when you are backing up over IP and you are transferring the VM for the first time ©XSIDiff takes over Rsync role, as the copy is much faster when using this program. In some cases, it could be useful to force Rsync usage, like when transferring data to an internet server through a narrow and/or unreliable WAN.

- Disable/reenable vMotion interface: when your ESXi host is included into a vCenter host and you use ESXi backup, you don't want vCenter to move your VMs around if the host is engaged into a DRS scheme. You can always set policies at the vCenter level to avoid this during the backup windows. In any case XSIBackup allows you to use the --disable-vmotion argument (which is set by this option in the menu). This will simply disable the vMotion service at the beginning of the backup and re-enable it once the backup finishes.

- Override _XSIBAK filter: this option allows to backup VMs with the _XSIBAK string appended, which denotes VMs that are ©OneDiff mirror copies of production VMS. This is useful to backup the just mirrored VM for archival purposes. It's normally used with the ©XSITools deduplication engine.
This page was last modified on 2018-06-12

Website Map
Resources & help
33HOPS Forum
Index of Docs

©33HOPS site relies on the following technologies and partners:
SSL Protocol PayPal Payment Gateway Stripe Payment Gateway

©33HOPS Sistemas de Información y Redes, S.L. | VAT No: ESB83583716 | Avda. Castilla la Mancha, 95, local posterior, 28701 San Sebastián e los Reyes (Madrid) Spain

Fill in to download
The download link will be sent to your e-mail.

            Read our Privacy Policy

(*) DC & Pro users, please login to your user area to download