©XSIBackup new security scheme since v. 1.5.2.0

Using ©XSIBackup in a local and remote security scheme

©XSIBackup was born as a service to be directly executed in some ©ESXi server. Thus it was first though to be run under the root user account in the local hypervisor.

Since it soon offered compatibility with remote file systems over IP/SSH, some users rapidly tried to make it work under some remote user account too. Although it was possible since the beggining, it could become rather cumbersome in some cases, thus we recommended to use the remote root user too to transfer the data to the remote backup server.

Still, this would collide with the security schemes imposed by some enterprises. Some clients have regularly asked for a way to more easily use local and remote alternative users other than root.

In version 1.5.2.0 we have taken the time to rethink everything having to do with using less privileged users in the local ©ESXi and remote Linux backup server environment.

Local ©ESXi environment

To run ©XSIBackup in your ©ESXi box you need a full privileged user. It doesn't necessarily need to be the very root user, still you will need to read and write to configuration files in the VMs. Thus, unless you are ready to go through configuring a user that has the minimal set of permissions (which can become cumbersome), the easiest thing to do is to just create a clone of the root user.

If you want to go through configuring a user from scratch, what you need to know is that the user will need to have full read permissions on the boot volume to read general config files plus full permissions, including creating files on the VM folders that the user must backup.

Remote Linux backup host

This is where we have changed the way things work the most. Before 1.5.2.0 you would need to first run the backup job as root so that the binary files: xsibackup and xsib64 would be copied to the remote backup host. The reason was that those files were stored in the /usr/bin folder.

You could also copy the files there manually, but the aim of ©XSIBackup is to manage its dependencies in an automated way. Also, this would impede non privileged users to backup to a server where they would not have full root access, like some hosting or departmental server.

From v 1.5.2.0 we have redesigned ©XSIBackup so that each user folder (/home/[username]) stores a full copy of all the required files to act as a server inside the .xsi dir. Thus for a user called backupusr you would have a folder structure like the one below:

©XSIBackup will look for it's remote dependencies at the /home/backupusr/.xsi/bin folder. Just as long as the home folder is created appropriately with its set of default permissions, ©XSIBackup will be able to create backup repositories and replica folders just fine.

Be careful, if you create your backupusr user on your own, the process will create the /home/backupusr folder owned by the backupusr user. Still, any folder that you create with the root user will be owned by it and backupusr user will receive permissions errors when trying to backup to any of those folders

To restore the default ownership to the home folder run this code snippet as root

How to prepare a remote backup server user

Creating a remote backup user is extremely simple:

1/ Create some Linux user

2/ Exchange the ©XSIBackup RSA public key with the remote user (from the ©ESXi box):

As always when using the --add-key argument, you will be prompted to enter the remote user's password a number of times. Do so until your receive a confirmation hat the key has been exchanged correctly. If you then run the command again, no password prompt should appear, but just the whole sequence of checks.

3/ Backup or replicate using the remote user:

Needless to say this user will be able to backup to its folder only: /home/backupusr

This way of working will keep a separate set of ©XSIBackup binaries for each user. This is not a problem, as the ©XSIBackup installation is less than 3MB.

You can have many different users backing up to a server, each using its own isolated set of server files and permissions which is ideal for hosting environments where one server will be shared by many users.