Registered users
Linkedin Twitter Facebook 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
33HOPS ::: Proveedores de Soluciones Informáticas :: Madrid :+34 91 663 6085Avda. Castilla la Mancha, 95 - local posterior - 28700 S.S. de los Reyes - MADRID33HOPS, Sistemas de Informacion y Redes, S.L.Info

XSIBACKUP-PRO 8.0.0 ::: Support for borg backup as an IP backend

As commented, Borg Backup is a fork of Attic Backup which seems to be a more active project for the time being. XSIBACKUP-PRO offers support for copying VM backups to any IP server equipped with a Borg Backup install. Installing Borg Backup is a trivial task most of the times. Just copy the corresponding binary i386 or x64 to your path at /bin or /usr/bin and that's it. Our reference OS is CentOS 6.8 with an ext4 FS. You are free to use the OS of your choice, but do pay attention to Borg Backup's requirements first, or you might end up with an unstable system. You can store many terabytes of real data in usually less than one tenth of the nominal amount of data and still browse and restore contents nimbly.

Making a backup

To make a backup to a Borg backend, you just need Borg Backup on the other side and full root access through the SSH port (22 is default). XSIBACKUP-PRO pipes data through an SSH tunnel, thus, all transmitted content is encrypted by using the XSIBACKUP-PRO RSA key. Data is "tarred" and sent over a pipe, this means the packed size will be slightly bigger than the sum of the files, due to tar headers and file separators. As in every other "over IP" scenario with any version of XSIBACKUP(FREE|PRO), you must first link to the other server by using the --link-srv=[IP of remote system] argument. This will ensure that transparent encrypted communication is possible from the client to the server side of the pipe.


Where is the address of a fully accessible Borg server. The [z] after the borg program name at --backup-prog=borg:z is recommended as it will not affect efficiency but will improve storage to disk usage ratio.

There's currently no possibility to run a true Borg Backup client on the ESXi family of OSs, thus all data is sent to the other end of the pipe. This won't be a problem in a LAN, but makes backups via Borg almost impossible to be performed over a regular WAN, unless the VM sizes are restrained. To backup data over a WAN use © OneDiff to make sure you only transfer changed blocks, and once you have the consolidated and mirrored VM on the other side, then use a Borg Backup command to store a copy of the current VM. This way you can take advantage of a differential backup and an archive of deduplicated data that will allow you to move back and forth in time to get to the desired state of a given VM in the event of a disaster recovery scenario.

Storage efficiency:

In regards to this topic, nothing better than a real example of what block level deduplication plus compression can do for your storage budget. Below these lines you have an excerpt of a real Borg repository storing one week of VM backups, which are a mix of Windows 2008 Server, Windows 7, Windows XP and different Linux servers. As you can see, 1.39 Tb. are stored in just 86.94 Gb of storage.

Storage format:

As commented, XSIBACKUP-PRO stores data as a tar file. You can use the provided restore function in XSIBACKUP-PRO, or if for whatever reason you whish to manipulate the data manually, you can extract the Borg backup and untar the resulting stdin file right in the Borg server.

Website Map
IT Manager
In Site
Resources & help
Index of Docs
33HOPS Forum

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

            Read our Privacy Policy