You are not logged in.
Backup over IP does not have any issue. However, when I tried to do a restoration with the backup folder, it return Segmentation fault in the console.
/scratch/XSI/XSIBackup-DC/xsibackup --restore xsibackup@host:22:/xsibackup/host/20220328165750/VM1 /vmfs/volumes/datastore1/restore
NUMBER FILE SIZE PROGRESS
-------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------
SIGTERM (11) condition was trapped: check logs for more details
-------------------------------------------------------------------------------------------------------------
Cleaning up...
-------------------------------------------------------------------------------------------------------------
Segmentation fault
There is no other errors in the logs too.
Thanks
Last edited by indieair (2022-03-28 17:30:32)
Offline
Are you using latest version?.
Restore using [b]root[/b] and see if that works.
We recommend that you use CentOS 6/7 or Rocky Linux 8 as your target Linux system. There are hundreds of Linux distros and although most of them share some common principles, we can't guarantee that.
If you use the recommended distros and File Systems (XFS, ext4), you will enjoy the benefit of using some heavy tested scenarios and you will minimize your issues and take maximum advantage of your time.
Your problem broken down into its constituent pieces:
To be able to restore from a remote system you need xsibackup binary present in it. (c)XSIBackup can automatically update your binaries in the remote host, just as long as you use the root user, as the binaries are placed in the /usr/bin folder and you need elevated privileges to do that. You can also install manually but doing it through the regular over IP backup/replica command is much more convenient.
Once the binary is present in the remote system you will be able to use it when running the command with some alternative user, like [b]xsibackup[/b]. Still that user will need to have privileges to create folders inside its home directory /home/xsibackup. You can achieve that by running.
chown -R xsibackup:xsibackup /home/xsibackup/
You have obviously configured your backup server up to this point, as you say that you can indeed backup without issue using the [b]xsibackup[/b] user.
Restoring from the remote folder using the non-privileged user should be rather straight from this point. Just make sure that you are using the latest binary.
Offline
I'm using version 1.5.1.11.
I've tried with root user and got this error when restoring. There were no issues with the backup
NUMBER FILE SIZE PROGRESS
-------------------------------------------------------------------------------------------------------------
2022-03-29T04:41:26 | Error code 226 at file restore.c, line 226 | Error description: can't read file name from SSH tunnel
Offline
Your problem is in the SSH tunnel. Disable any firewalls in between and revise the errors thrown by the SSH layer. Increase verbosity and activate strace:
strace ./xsibackup --restore xsibackup@host:22:/xsibackup/host/20220328165750/VM1 /vmfs/volumes/datastore1/restore --debug-print
We do these type of operations every day on CentOS and Rocky Linux, even on Ubuntu and Debian devices sometimes, although as you know we encourage you to use the former distros.
What is your remote system?, you haven't even told us.
Offline
My apologies, missed out on your question.
We are using CentOS 7 in the remote system
Offline
And your (c)ESXi version?. We can try to reproduce your environment, still it's difficult to do so when we don't know it
Offline
Our EXSI version is 6.7.0 Update 1
Offline
Thank you.
We have conducted some tests using your very same (c)XSIBackup and (c)ESXi version in CentOS 7.0 as an IP backend with no issue.
We'll take the chance to revise the main steps involved in achieving your goal.
As said, using the root user is the recommended procedure, as it will abstract you from having to deal with the permissions of the elements involved in the process. On the other hand a public RSA key authentication over SSH is, by today's standards, the most secure way to access any remote OS.
You start by installing some fresh CentOS 7.0 OS and updating it via yum: [b]yum update -y[/b].
Now you can directly exchange your public (c)XSIBackup RSA key with the just installed host.
From the (c)ESXi box:
./xsibackup --add-key root@a.b.c.d:22
(*) Do make sure to enable SSH port in the (c)ESXi firewall, both in and out.
We start by exchanging the root key, as only the root user will be able to automatically update the remote binaries: xsibackup and base64
We then create the backup user in the remote CentOS 7 backend:
[root@localhost ~]# useradd backup1
[root@localhost ~]# passwd backup1
Changing password for user backup1.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
Create a dir to store your backups and take ownership of the home folder for this user:
mkdir -p /home/backup1/backups
chown -R backup1:backup1 /home/backup1
Add the (c)XSIBackup RSA public key to the [b]backup1[/b] user's authorized_keys file, namely: exchange the key again for this user.
From the (c)ESXi host:
./xsibackup --add-key backup1@a.b.c.d:22
The key contained within the [b]xsibackup_id_rsa.pub[/b] file in the (c)XSIBackup installation dir will be added to the remote OpenSSL file: /home/backup1/.ssh/authorized_keys, that is: the file containing the authorized keys for the [b]backup1[/b] user. You can also do that manually.
Now you should be able to access the remote system passwordlessly using the [b]backup1[/b] user. You can easily check that by running the last --add-key command again.
Still, you won't be able to backup to that host yet, as you still need to install the [b]xsibackup[/b] binary to act as the server side of your backups or replicas. Again, you can install manually or just use the built in automatic process.
To install the binaries to the remote host, just run some --backup or --replica to some folder on the remote CentOS 7 backup server by using the root user
./xsibackup --backup "VMs(YOUR-VM)" root@a.b.c.d:22:/home/backup1/backups
The required binaries will be updated and assigned 0755 permission.
Now run the same backup command again by using the [b]backup1[/b] user.
./xsibackup --backup "VMs(YOUR-VM)" backup1@a.b.c.d:22:/home/backup1/backups
We believe you already got to this point.
Now to restore any of the backup points for [b]YOUR-VM[/b] in the remote CentOS 7 server just create some local folder to host the restores.
mkdir -p /vmfs/volumes/datastore1/restores/YOUR-VM
And then restore the VM to the above generated folder.
./xsibackup --restore backup1@a.b.c.d:22:/home/backup1/backups/20220331122508/YOUR-VM /vm
fs/volumes/datastore1/restores/YOUR-VM
You will see some output like the one below
[root@localhost:/scratch/XSI/XSIBackup-DC] ./xsibackup --restore backup1@a.b.c.d:22:/home/backup1/backups/20220331122508/CRM /vm
fs/volumes/datastore1/restores/YOUR-VM
|---------------------------------------------------------------------------------|
||-------------------------------------------------------------------------------||
||| (c)XSIBackup-Free 1.5.1.11: Backup & Replication Software |||
||| (c)33HOPS, Sistemas de Informacion y Redes, S.L. | All Rights Reserved |||
||-------------------------------------------------------------------------------||
|---------------------------------------------------------------------------------|
(c)Daniel J. Garcia Fidalgo | info@33hops.com
|---------------------------------------------------------------------------------|
System Information: ESXi, Kernel 6 Major 7 Minor 0 Patch 0
-------------------------------------------------------------------------------------------------------------
/!\ Running XSIBackup in a nested host is not supported
-------------------------------------------------------------------------------------------------------------
Remote system: Linux
-------------------------------------------------------------------------------------------------------------
PID: 2102784, Running job as: backup1
-------------------------------------------------------------------------------------------------------------
Run job as 'root' to automatically update the remote binaries
-------------------------------------------------------------------------------------------------------------
The restore directory: /vmfs/volumes/datastore1/restores/YOUR-VM does not exist
Do you wish to create it? (y/n): y
-------------------------------------------------------------------------------------------------------------
Restoring VM CRM from 192.168.3.221
-------------------------------------------------------------------------------------------------------------
NUMBER FILE SIZE PROGRESS
-------------------------------------------------------------------------------------------------------------
1/20 CRM.vmx.tmp 2.45 KB | Done 0.00%
-------------------------------------------------------------------------------------------------------------
2/20 vmware-49.log 189.61 KB | Done 0.00%
-------------------------------------------------------------------------------------------------------------
3/20 CRM.vmdk 500.00 B | Done 0.00%
-------------------------------------------------------------------------------------------------------------
4/20 CRM-flat.vmdk 20.00 GB | Done 99.99%
-------------------------------------------------------------------------------------------------------------
5/20 CRM-aux.xml 13.00 B | Done 99.99%
-------------------------------------------------------------------------------------------------------------
6/20 CRM.vmdk.extents 8.30 KB | Done 99.99%
-------------------------------------------------------------------------------------------------------------
7/20 CRM.vmxf 258.00 B | Done 99.99%
-------------------------------------------------------------------------------------------------------------
8/20 CRM.nvram 8.48 KB | Done 99.99%
-------------------------------------------------------------------------------------------------------------
9/20 CRM.vmsd 46.00 B | Done 99.99%
-------------------------------------------------------------------------------------------------------------
10/20 vmware-51.log 161.16 KB | Done 99.99%
-------------------------------------------------------------------------------------------------------------
11/20 CRM-flat.vmdk___hash 82.00 B | Done 99.99%
-------------------------------------------------------------------------------------------------------------
12/20 CRM.vmx 2.45 KB | Done 99.99%
-------------------------------------------------------------------------------------------------------------
13/20 vmware.log 241.14 KB | Done 99.99%
-------------------------------------------------------------------------------------------------------------
14/20 vmware-47.log 374.03 KB | Done 99.99%
-------------------------------------------------------------------------------------------------------------
15/20 vmware-48.log 325.92 KB | Done 99.99%
-------------------------------------------------------------------------------------------------------------
16/20 CRM.vmsd.tmp 46.00 B | Done 99.99%
-------------------------------------------------------------------------------------------------------------
17/20 vmware-46.log 172.79 KB | Done 99.99%
-------------------------------------------------------------------------------------------------------------
18/20 vmware-50.log 1.45 MB | Done 100.00%
-------------------------------------------------------------------------------------------------------------
19/20 CRM.vmx~ 2.45 KB | Done 100.00%
-------------------------------------------------------------------------------------------------------------
20/20 CRM-Snapshot1470.vmsn 27.37 KB | Done 100.00%
-------------------------------------------------------------------------------------------------------------
Restore end date: 2022-03-31 12:52:38
-------------------------------------------------------------------------------------------------------------
Time taken: 00:08:11 (491 sec.)
-------------------------------------------------------------------------------------------------------------
Speed: 41.72 mb/s
-------------------------------------------------------------------------------------------------------------
Removed host <tmp> dir OK
-------------------------------------------------------------------------------------------------------------
Removed prog <tmp> dir OK
-------------------------------------------------------------------------------------------------------------
Removed PID OK
To be able to restore your VM you just need the [b]backup1[/b] user have:
1/ Execute rights on the remote binaries. This is assigned by default when you use the root user to perform some test backup.
2/ Read access to the backup respository.
Of course, we are posing this example asuming that you are logged in the (c)ESXi server as root. It's not the same the local user than the remote.
To detect any possible issue in the SSH tunnel, you can debug it by adding the --debug-print argument to your restore backup, which will print the details on the remote commands launched:
./xsibackup --restore backup1@a.b.c.d:22:/home/backup1/backups/20220331122508/YOUR-VM /vm
fs/volumes/datastore1/restores/YOUR-VM --debug-print
You can also run some SSH command to verify that you can access the remote files
From the [b]/scratch/XSI/XSIBackup-DC[/b] dir:
ssh -i xsibackup_id_rsa backup1@a.b.c.d "cat /home/backup1/backups/20220331122508/YOUR-VM/YOUR-VM.vmx.map" | cat > /tmp/YOUR_VM.vmx.map
This command should bring your remote [b]YOUR-VM.vmx.map[/b] file to the /tmp dir. It should contain a 40 byte SHA-1 hash.
To increase verbosity in the SSH tunnel and get all the details, in case you are getting some error:
ssh -vvv -i xsibackup_id_rsa backup1@a.b.c.d "cat /home/backup1/backups/20220331122508/YOUR-VM/YOUR-VM.vmx.map" | cat > /tmp/YOUR_VM.vmx.map
Offline