Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Any cron like schedule:

30 02 * * * /scratch/XSI/XSIBackup-Pro/jobs/001

Then update the general root crontab by running

./xsibackup --update-cron

That's exactly how restore works...

./xsibackup --restore /some/repository/20200623033451/YOURVM /where/to/restore

You can also use bin/xsifs to extract the files, that will be slower though.

You can use any port you want, just as long as it's not used by another service.

Sparseness depends on the OS kernel and FS, nothing to do with (c)XSIBackup-DC.
15 blocks is same as nothing.

All you are describing is really awkward. Please contact support for some personalized help, we would need to reproduce your issue by using the same target OS. This doesn't look like something that could be generalized or help others until we know the details of the target OS.

All functions different than [b]--backup[/b] and [b]--replica[/b] are free and they don't have any limitation, that's why they don't even try to validate the license nor print it out when invoked. We might change this in some future version as we understand it can be puzzling to some users.

You are using a wrong syntax to restore your VMs. You use "VMs(VM1,VM2)" to back them up, that syntax means: look for registered VMs with those names. Nevertheless the restore process follows a different logic. VMs are stored in repositories which have the structure below:

testrepo/
testrepo/data
testrepo/.xsitools
testrepo/20200614103243
testrepo/20200614103243/VM1
testrepo/20200614103243/VM2

To restore a VM, point the source to some VM folder in a timestamped folder, and the target argument to some restore point.
i.e.:

./xsibackup --restore /vmfs/volumes/backup/testrepo/20200614103243/VM1 /vmfs/volumes/datastore1/VM1-restored

We believe that has more to do with your remote OS, FS and du implementation than with DC binary. What it does is to create an empty sparse file, then it fills it with the non-zero data.

Even if you don't host your VM in a VMFS volume, (c)XSIBackup-DC will still jump over zeros in the replica, thus the resulting replicated -flat.vmdk file is always a sparse (thin in (c)VMWare's terminology) file.

Try to run this alternative command and see if that returns the non-zero data on the leftmost column.

ls -lash Radius-flat.vmdk

Please, note that since some recent update in (c)Synology DSM, only root user is allowed to login via SSH.

Apart from other minor details that we see (--compress argument does not exist, it is [b]--compression[/b] and that feature is applied by default, so there's no need for it), you are clearly receiving a message stating all you need to know:

Unknown cipher type 'aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc'

OpenSSH is letting you know it can't negotiate a cipher.

Most people assume things work in a given way, it might be logical that they believe they should be like that, the problem comes when they are viscerally closed to accept they might work in a different way. We aren't stating that it is your case, just uncovering a key general principle.

The thing is that OpenSSH DOES NOT work the way most people assume it does or it should. We won't enter into why OpenSSH developers arrange things in that way, they do some really awkward things, nonetheless that's the way it is, and going against reality is not a good idea.

So, if just a single cipher in the list of user proposed ciphers fails, you will receive that message and the tunnel will drop. Things work differently when ciphers are autonegotiated, (c)XSIBackup-DC allows the user to set ciphers though.

The default set of user ciphers are set in the [b]xsibackup.conf[/b] file into the ./etc directory, you may tweak that to your needs or you may use the [b]--ssh-ciphers[/b] argument, which will allow to set that per backup job.

You can get a list of available ciphers in each side of the SSH tunnel by running

ssh -Q cipher

Now you can use one or more of the commonly available ciphers in your (c)XSIBackup-DC job.

[b]/!\ Keep on reading[/b]. Still the thing does not end there though, as ciphers' use can also be controlled in the /etc/ssh/sshd_config file in your Synology NAS, or eventually any other Linux device, thus you may still be rejected your user cipher even though it is present in the list of available ones. This is general behaviour and, as stated, can be extended to any Linux OpenSSH enabled host.

Even if you see that the output of [b]ssh -Q cipher[/b] is:

3des-cbc
blowfish-cbc
cast128-cbc
arcfour
arcfour128
arcfour256
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc@lysator.liu.se
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com

And the Cipher configuration in your /etc/ssh/sshd_config file is:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,3des-cbc

If you try to use [b]chacha20-poly1305@openssh.com[/b]

You will receive SEGFAULT 13 (broken pipe) and if you increase the level of verbosity in [b](c)XSIBackup-DC[/b] to maximum (--verbosity=10), you will still see this:

SSH Out: unable to negotiate with 192.168.3.90 port 22: no matching cipher found. their offer: aes128-ctr,aes192-ctr,aes256-ctr,3des-cbc

The solution is simple: add [b]chacha20-poly1305@openssh.com[/b] to the list of allowed ciphers in the [b]sshd_config[/b] file

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,3des-cbc,chacha20-poly1305@openssh.com

Our experience is that [b](c)XSIBackup-DC[/b] will work with the default set of ciphers up until our DMS reference version

root@NAS01:~# more /etc.defaults/VERSION
majorversion="6"
minorversion="2"
productversion="6.2.1"
buildphase="GM"
buildnumber="23824"
smallfixnumber="0"
packing="iSCSI"
packing_id="1"
builddate="2018/09/07"
buildtime="16:57:11"

It's a typo, it's only Free version that has been upgraded to 11.2.9

We have no control on what AWS accepts as input and we do not announce compatibility with AWS in any way.

That said (do not forget it).
Make a replica, mount it in ESXi and export it as .ovf. The only drawback you will have is the data written to the production VM while you upload to AWS.

You are missing the --backup-prog argument.
Remove --test-mode=true to run a backup

# ./xsibackup --backup-prog=Vmkfstools --backup-point=/vmfs/volumes/backup --backup-type=running --mail-from=email.sender@yourdomain.com --mail-to=email.recipient@anotherdomain.com --smtp-srv=smtp.33hops.com --smtp-port=25 --smtp-usr=username --smtp-pwd=password