Last updated on Wednesday 16th of November 2022 08:08:44 PM
First steps with ©XSIBackup
The first tests, create your first jobIf you have read the Installation post, you already have a system that you can start using. It doesn't matter whether you have installed a license or not. By now you should still have some days of use left from the trial time. Once the trial time is over ©XSIBackup will still work to backup VMs up to 100GB locally.
©XSIBackup incorporates an nCurses GUI that you can use to deploy backup jobs rapidly. Still, it is a very powerful command line tool and you must comprehend the command line before using the GUI, unless you just want some very basic type of topology.
We will run the first jobs interactively. Once we know they are working right, we will just save them so that we can use the job files in some cron schedule.
There are two main type of jobs you can run with ©XSIBackup: backups and replicas.
Backups store your VMs in a deduplicated repository with an extreme compression ratio that allows to store hundreds of restore points in some storage volume only 50% bigger than your set of VMs. You can restore full VMs or files from any restore point.
(*) You must store your backups to some fast File System, we do recommend XFS or ext4 in case XFS is not available. That can easily be achieved by attaching some NFS volume as a local datastore, using an RDM disk or just backing up over IP to some remote FS.
Replicas are ready to use exact copies of VMs at some given point in time. Both operations can be performed while the VMs are running with a minimal impact on the resources of your host.
You must decide how to use this actions to deploy your own backup topology.
The simplest job that we can run is replicating one VM from one datastore to another. We can do so while the VM is running, you don't have to do anything, ©XSIBackup will take care to take a snapshot to make the replica be consistent.
The above command will replicate the VM named "YOUR-VM" from its current location to the replicas folder inside the BACKUP-VOL datastore.
On the other side the above command will backup the same VM to a backup repository inside the folder backup-repo1 in the same backup volume. This will create a structure with:
- An .xsitools file containing the main preferences of the repository: block, size number of blocks, etc...
- A data folder containing a hierarchy of hexadecimal folders arranged by the first 5 digits of an SHA-1 hash format containing the blocks that compose your backups.
- Timestamped folders with the format YYYYMMDDhhmmss containing the block manifests for each restore point in the repo.
Backups over IP©XSIBackup allows you to perform the two main actions exposed above: backup & replicas over IP to any ©ESXi or Linux host equipped with some fairly recent version of OpenSSH. Most Linux distros will come with one out of the box. We recommend that you use CentOS 6/7 or Rocky Linux 8 to build your backend backup servers.
Before you can send your backup or replicas to some IP/SSH backend server you need to exchange your ©XSIBackup RSA public key with it. Doing so is extremely simple, you just have to run the --add-key command from the command line and enter the remote host's password a number of times.
(*) You generally always use the root user to exchange keys, as you need maximum privilege escalation to be able to add keys to the authorized_keys files. You can also add your ©XSIBackup RSA public key to the remote authorized_keys file manually.
(**) There is one authorized_keys file per user in the corresponding .ssh folder. The .ssh folder can generally be found at /root/.ssh for the root user and at /home/user/.ssh for other users. Since v. 188.8.131.52 the root .ssh folder is stored at home/root/.ssh, just like the rest of the users
Once your remote host is linked, just change the target argument by some remote path with the format: email@example.com:22:/some/remote/path
We recommend that you use the root user for your tests, otherwise you will add the necessity to handle the permission configuration at the same time than exploring a new feature and you will have more chances to get stuck in the process.
Run your first tests as root, then switch to employing other users as you gain confidence with creating new jobs. There may be cases in which you will only be able to use the root user, such as with closed down environments like Synology or QNap Operating Systems.
At this point you should have run your first replica and backup job locally as well as to some remote host over IP. You have seen how ©XSIBackup allows to easily migrate VMs locally and over IP as well as to keep highly compressed backup repositories.
Recovering dataYou have two main posibilities at the time to recover data. You can recover full Virtual Machines from any of the available restore points at any given repository, or you can recover individual files from any of the VMs in any of the available restore points.
Recovering a full VMs is immediate, you just have to use the --restore action as the first argument, the source or VM restore point as the second argument and the target or directory where you want to restore your VM to.
The source can be any local or remote FS, while the target must always be some locally available file system. The following example illustrates how to recover a VM from a restore point in a repository that is stored in a local datastore called backup.
Thea bove command will restore the full VM my-vm to the directory /vmfs/volumes/datastore1/my-restored-vm. Once the restore process completes, you can just register the restored VM and switch it on.
Restoring from an IP source is also very straight. We will asume that you have already linked the remote FS via the --add-key action to backup the VM that you now want to restore.
A full VM restore is as simple as that, there's nothing more to it but just making sure that you point your source and target paths to the appropriate locations.
Recovering granular dataRecovering files is only a bit more complex than recovering a full VM. In order to do so we need to access the virtual disks where the files are. For that to be possible we need to make use of XSIGR, bundled in the bin folder of the ©XSIBackup package. From the root of the installation folder:
Installing XSIGR to any Rocky Linux server enables it to access any Windows or Linux virtual disk in any of the deduplicated restore points of an ©XSIBackup repository. Doing so is very straight by running the XSIGR installation from the bin/XSIGR folder in the ©XSIBackup installation directory as shown above.
Once the remote preparation is fulfilled you can run xsigr from the command line of the backup Rocky Linux server. Any missing dependencies will be installed after a confirmation prompt. Below the output that you should see.
Once the XSIGR dependency installation finishes you can invoke the xsigr binary from the command line. You must add --interactive to use the TUI interface.
(*) You can see the rest of a granular restore operation in this post.
Any restore operation starts by asking you to enter the path to some ©XSIBackup repository, then comes choosing the restore point to access, the VM and disk/volume to recover the files from.
You can access not only ©XSIBackup repositories stored in local disks, but also over some NFS, iSCSI or SSHFS mount point among others. A Samba/CIFS server is installed along with XSIGR to ease accessing the virtual disks from any other Windows/ Linux desktop. Of course you can also use some SSH/SCP client like WinSCP.
(*) Check Offer details out