Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

What is this?: "> 1"
Why is the --mail-to argument missing the first "--"?

You are most probably generating your own errors by using a malformed job syntax.
In fact we believe it's quite remarkable that the job took place in the end.

Please, run this and post the output

./xsibackup --replica=cbt "VMs(Lecturas)" root@REDACTED:22:/vmfs/volumes/Backups/backups_ctec

The best way to save in offsite storage is to upload the deduplicated repository using Rsync. Turn the Rsync flags to avoid a full cheksum and only compare by size and date and you will have an extremely fast sync to the offsite server while keeping a compression ratio close to 99%, thus 1TB could easily host some 90TB of real data.

We don't know what type of OS you are using as the offsite backend, a Linux distro would be the perfect match though, we still recommend CentOS/ RHEL 7

XSIFS performance depends on the resources you have. You should be able to make it work over NFS with a more than decent throughput for big files: 20-30MB/s, that's what we get on commodity hardware. Using SSD would drastically improve that.

No, there isn't.
Use a replica and upload the replica or upload the repository instead of the rebuilt VMs.

[url]https://33hops.com/user-login.html[/url]

Just use some sequence number above 1, that should do it. If you had performed many CBT syncs, the closer to the failing sequence, the lower the amount of data to transfer. It might not be significant in your case, we don't know the amount of data generated in between CBT cycles.

SSH compression is disabled by default in both --replica and --backup, it's redundant and useless. In case of --backup because the data chunks themselves are already compressed by default. In case of --replica because zero blocks are filtered out and compression is only really significant when many zeros are present.

Compressing binary data where most zeros have already been stripped off makes no sense.

Great!, they block basic system calls. This must be the ultimate in security. Wait until they discover that blocking all of them is even more secure.

Our recommended distro is CentOS. Now that they took the turn of eliminating the stable CentOS releases we will switch to some other stable distro, most probably based in Debian.

We meant that you share the output of the --replica job that failed.

--check argument just checks that the blocks in the manifest exist in the replica and their hashes are correct. If you use the --replica=cbt plus --options=R, your remote VM will be registered and you can switch it on to check its contents.

If you receive some error in the middle of a backup, you should investigate where that error came from and whether that corrupted your mirror disks. As you seem to be quite confident, we guesss you received the error after 100% of the blocks had already been copied.

Can you share the output?, otherwise we can just especulate.
--check command is local, run from the remote Linux server.

We will add new features in this direction in future releases. You can nonetheless design your own e-mail templates.

[url]https://33hops.com/xsibackup-dc-full-manual-home.html#email-reports[/url]

You are right, taking the user's hand and walking him through all the learning curve is the way to go.

Still, given our current size we can't afford to do so, thus, by now we will have to treat our users as Linux sys admins with a mid knowledge of the Linux command line environment.

Once we reach our goals we can move up the commercial line towards the end user, or at least power users. Take on account that given the nature of the software's purpose, we may never reach end users, it might even be couterproductive.

It is indeed working for us

 ./xsibackup --replica "VMs(WS2012)" "root@192.168.133.23:22:/volume1/backup/replicas/$(date +%Y%m%d%H%M%S)" --rotate=3

|---------------------------------------------------------------------------------|
||-------------------------------------------------------------------------------||
|||   (c)XSIBackup-DC 1.5.0.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 5 Minor 0 Patch 0
-------------------------------------------------------------------------------------------------------------

...
...
...
...
...
...
...
Total size:                                                                    100.02 GB    | Done 100.00%
-------------------------------------------------------------------------------------------------------------
*** Snapshot was removed ***
-------------------------------------------------------------------------------------------------------------
Backup end date: 2021-07-23T12:38:10
-------------------------------------------------------------------------------------------------------------
Time taken: 00:06:58 (418 sec.)
-------------------------------------------------------------------------------------------------------------
Total time:      418 sec.
-------------------------------------------------------------------------------------------------------------
Full file speed:                                                                           245.01 mb/s
-------------------------------------------------------------------------------------------------------------
Real data speed:                                                                            33.42 mb/s
-------------------------------------------------------------------------------------------------------------
Item backup completed without errors
-------------------------------------------------------------------------------------------------------------
Final checksum: 10095909563 bytes were sent and confirmed to have been written remotely
-------------------------------------------------------------------------------------------------------------
Data processing completed successfully
-------------------------------------------------------------------------------------------------------------
--rotate option was detected, retrieving backups to prune...
-------------------------------------------------------------------------------------------------------------
- Deleting replica at '/volume1/backup/replicas/20210723091155'
-------------------------------------------------------------------------------------------------------------
Removed host <tmp> dir        OK
-------------------------------------------------------------------------------------------------------------
Removed prog <tmp> dir        OK
-------------------------------------------------------------------------------------------------------------
Unlocked backup               OK
-------------------------------------------------------------------------------------------------------------

We have indeed embraced that type of usage as explained in the above post.

[url=https://33hops.com/xsibackup-extended-rotation-features.html]Extended rotation features[/url]

I believe that the key matter here is that you probably have not perceived the radical difference between a simple timestamp and a Julian + Mod rotation.

When you use [b]$(( $(date +%j) % N ))[/b], the rotation is implicit to the date algorithm. You don't need to use argument --rotate, the date will always produce a fixed rotation from 0 to N-1, thus it will revisit each folder each (N-1) times and produce a differential copy. The first time for each of the integers produced the copy will be full.

When you use the plain time stamp pattern, each folder is new every time and so your VM is fully copied every time, there isn't any kind of differential feature.

Of course it's not possible to generate the data out of thin air. If there isn't any seed data in the target folder, no differential copy can be performed.