Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Please, provide both the full command and its associated output every time.
Just make sure that you have written a well formed job command any run the CBT replica again, you are just reporting a first full copy.

You can run the program with option --verbosity=10, nonetheless the finest level of detail you will find about that error is:

[b]550 5.0.0 SUBJECTBLOCK This mail is a virus or spam or a mail loop[/b].

This is coming from the SMTP protocol conversation and is definitive.

You will always need to enter your password, unless you tell the ssh client to use the exchanged key by using the -i option.

ssh -i xsibackup_id_rsa root@nas

Add the key and run the above code from the (c)XSIBackup-DC installation root. If you are not asked for a password, then your key exchange worked.

If the automatic login does not work either, run the command with the -vvv option to get the detail on the OpenSSH protocol conversation and the detail on why key authentication isn't working.

ssh -vvv -i xsibackup_id_rsa root@nas

When you run --add-key again after a successful key exchange, you should see a confirmation that the key is in the remote system and that key authentication is enabled.

You don't say what version of DSM you are using. Being able to use Synology as a backup device over IP depends on the DSM desing and SSH configuration options. Double check whether [b]/root/.ssh/authorized_keys[/b] is the right place to store your public keys and check whether key authentication is enabled in the [b]/etc/ssh/sshd_config[/b] file.

We haven't tested (c)XSIBackup-DC on BTRFS, it's still under development, you should not use it in production, it will not be the best approach, in special if you have turned on deduplication.

(c)XSIBackup-DC has its own buil-in deduplication engine, you don't need additional deduplication. I believe many users don't realize what deduplicating data in real time with a small block size as BTRFS does means in terms of CPU and memory. If on top of that you add that Synology doesn't ussually have specially powerful CPUs nor much RAM..., you are creating the perfect storm.

Use XFS or ext4, as stated all over (c)XSIBackup-DC posts and manual.

(c)XSIBackup-DC has been designed to run in the (c)ESXi host. Running it in the Synology device is a terrible idea, please, don't do that.

We can always improve the source to try to handle unexpected situations better, that said: many of your issues point at some kind of sluggish behavior from part of your FS. We have had all kind of situations with users, xsibackup will not prevent you from doing something awkward, like backing up to some deduplicated FUSE FS, nonetheless that will not yield anything close to good results, as you would be producing such a load on the target FS that the mere fact that you could end some backup would be a miracle, yet not achieving any productive result.

The same happens when performing backups to VMFS6, we won't even comment on VMFS5, as it can handle just around 130,000 inodes, which is clearly insufficient to host any deduplicated repository.

VMFS6 can host millions of files (the number of inodes is not official, we have benchmarked it though), still VMFS6 has not been conceived to host millions of small files, but a few huge ones, which is right the opposite. Thus, you can't expect a good speed from it, in fact it's slow as hell when compared to some regular FS such as XFS or ext4. So, if you try to force VMFS6 to do something beyond its design principles, you might take it to its limits and start producing awkward results without even noticing you are doing something wrong.

We always take the time to explain this things in most posts covering backup targets.

Don't use the --backup-how option if you want to perform hot backups, it's the default behavior.
11 is the received signal number, that is: a SEGFAULT. Which is caused when trying to access a restricted area of memory. It seems that due to the failed snapshot that condition is generated in your case. We should delve into it to at least handle the error in a nicer way and show some hint along with the error.

We have two general design principles considerations that are colliding and entering a contradiction there, which are: always trying to continue, no matter what happens to, at least, copy as much data as possible, with: control errors and show nice and explanatory responses. We should probably just continue to the next VM in case of some errors like a failed snapshot, as trying to continue with the backup process will just lead to undefined behavior.

The e-mail report is not sent due to the program jumping to the uncontrolled error handling function, namely: the program exists abruptly. We will add e-mail reporting to it in future versions.

This issue is not something obscure. It's a simple system call (mkdir) that creates that dir. You can run some job with strace (just prepend 'strace' to it) to detect the exact reason why the system call fails. It will produce a lot of output though, and will be slower.

Are you using some kind of Async option maybe?

(c)XSIBackup-DC 1.5.0.3 has been published and the REGEXP simulator feature of the --exclude argument has been fixed.

I was still writing when you answered, don't miss the rest of it.

Yes, that assumption is correct.

Most, if not all, software manufacturers don't offer a checksum comparison mechanism on such big files as virtual disks. The reason is that most people won't try to understand how things work, they will just call their support help desks and drive them crazy, assuming that a wrong checksum means the backup failed. Thus, it's probably not feasible to offer such characteristic to the great public, the same way that it would be pointless to try to explain people that things are literally 'not there' when nobody looks at them.

You are probably assuming that DC works exactly the same way as Pro Classic, which is incorrect.
DC works by two main actions: --replica & --backup.

Replica produces replicas, it's not been thought to produce full backups, as replicas (and also backups) are differential and  if you create a new replica every time, you won't be taking advantage of any delta algorithm.

In any case if you still wish to do so, it's very easy, just add some dynamic replica target such as:

./xsibackup --replica "VMs(MyVM)" /vmfs/volumes/backups/replicas/$(date +%Y%m%d)

--rotate in a deduplicated repository is equivalent to pruning as much backups as to satisfy the rotation figure. Use to your discretion.

You would need to script that, e.g.: turn off all VMs to backup, then turn them on when you are done.