Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Many people forget to open the SSHClient rule in their (c)ESXi servers. Check that you have done so.

Run this in the Synology command line and see if you get the same output

/bin/xsibackup --version

See if you get the same message: [b]cannot execute binary file: Exec format error[/b]..

The most likely cause for this though is that your Synology doesn't have an x86 compatible CPU.

[url=https://kb.synology.com/en-global/DSM/tutorial/What_kind_of_CPU_does_my_NAS_have]LIst of Synology CPUs[/url]

Server function is totally free to use unlimitedly in any number of devices. Only the client feature requires a license.
Your command over IP should work in any case. Try debugging your SSH key trust connection via the ssh client.

ssh -vvv -i /path/to/theRSA/key root@10.100.100.81 "date"

The above command will print the remote date. The -vvv will print all the SSH protocol output on screen. There must be some issue in the SSH tunnel: some wrong permission on the remote xsibackup binary, some missing file...

Please don't make us guess the rest of the relevant information:

- (c)ESXi version.
- (c)XSIBackup version.
- Full output.

The most likely cause of your error is that whether the file has been corrupted somehow or that you have enabled secure boot in your BIOS.

We aren't getting you: replica at one point in past?

The only way to go to some point in the past is by restoring from a backup repository to a restore point in the past.
A replica is just that: a replica, it contains the info of the disks as they were when you performed the replica there isn't any historic set of data associated to it as opposed to backups.

You can't replicate a running VM to a running VM, that is not replication, you are implicitly defining a cluster on shared storage or a distributed file system such as Ceph or Gluster. You can on the other side replicate a VM and switch the remote VM on to check its contents via the --options=R option.

Best way is using CBT.

./xsibackup --replica=cbt "VMs(W702,WXPMKT)" root@1.2.3.4:22:/path/to/your/backup/volume

Or...

./xsibackup --backup=cbt "VMs(W702,WXPMKT)" root@1.2.3.4:22:/path/to/your/backup/repository

It's never a bad idea to do some clean up and remove spurious files from the production VM.
From our experience after some time of a VM in production you can accumulate orphan snapshots, old log files etc...

Keep in mind that once you remove all snapshots, all that you need for a VM to work seamlessly from an stopped state is:

1/ The file descriptors and corresponding -flat.vmdk files
2/ the .vmx file pointing to the right file descriptors.

You can delete the .vmsd file, it will be regenerated. In fact in some cases you do need to do so to fix some inconsistencies in it.

(*) Of course in case you have some more advanced requirements, like keeping snapshots or the memory state, you will need to keep some more files, still to sanitize a VM from an stopped state all you need are the disks and the .vmx file.

Unless you have some previous snapshot, which does not seem to be the case, you don't need the .vmsd file, just delete it, or even better: rename it to avoid irreparable mistakes.

In any case renaming a VM is not only renaming the files. You will need to rename all references in the .vmx file and the file descriptors .vmdk files (the tiny ones not the -flat.vmdk) as well as any other reference to snapshot files in the eventual snapshot file descriptors and .vmsd files.

To avoid innecessary hassle, unless you are used to do this kind of thing, just keep the name.

You must be receiving some error that prevents the .lock file from being removed.
Please share the job syntax + the full output so that we can tell you something based on actual data.

That feature will be added before 1.5.2

--enable-cbt and --reset-cbt make no distinction between disk types. It enables CBT for all disks.
When a disk is not readable it is skipped, having CBT enabled or not for that disk makes no difference, the disk is skipped, everything else is ignored.

Performance overhead of CBT is negligible.

In any case, it's easy: do it and see if it does what you want.

From a test in an old Synology box in our lab:

|---------------------------------------------------------------------------------|
||-------------------------------------------------------------------------------||
|||   (c)XSIBackup-Free 1.5.1.3: 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: Linux, Kernel 3 Major 10 Minor 105 Patch 0
-------------------------------------------------------------------------------------------------------------
PID: 32700, Running job as: root
-------------------------------------------------------------------------------------------------------------
- Pruning '/volume2/backup4/DATACENTER-BACKUP-1M-A/20210211150426'...
- Ordered and unique blocks: 3833, Index depth was set to : 3
- 100.00% | removed 36110 from 36120 blocks in folder | 28.14 GB were liberated
- Deleting blocks from .blocklog file...
- New block count was set to: 3896
- Removed backup folder: /volume2/backup4/DATACENTER-BACKUP-1M-A/20210211150426
The --prune process finished (1)
-------------------------------------------------------------------------------------------------------------
root@NAS01:~# cat /etc/synoinfo.conf | grep -E "(upnpmodelname|udc_check_state)"
upnpmodelname="DS712+"
udc_check_state="6.2.1"

The /temp/xsi dir is configured as the default /tmp dir on (c)XSIBackup, it is sought and created when it doesn't exist on every execution of the software. Thus, it is indeed created on every run when the user that is logged in is root.

Please note that when you login to the DSM command line you don't usually do that as root, thus you must change the user to 'root' to use the software for prunning without any eventual issues.

We'll investigate this issue further and eventually release a bug fix.

We can try to support Synology as far as it's reasonable to do so, still we can't guarantee compatibility for an OS that is designed with the purpose of hindering the functioning of other software not manufactured by Synology or its partners.

tail -f is OK and should work on any system.