Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

We have tried your command in the very same scenario with big files: 50GB and 100GB and we don't get any write error. Debug your network and make sure that it is working properly. XSIDiff will throw those errors when it can't write data to the socket for some reason, the most common one is some network problem.

Would you please post the URL where we advertise that XSIBACKUP-PRO will work as a raw data TCP server?

We never announced such feature, in fact the TCP client/server functionality is only announced in the XSIDiff binary command line help, and that's just a bonus feature, which BTW you could have only seen after purchase.

No, Rsync is NOT loaded as client/server, it is indeed tunneled through SSH.

I would not ignore it for obvious reasons.

XSIDiff, despite its name, is not a differential tool, it just copies data as is. It is zero aware, but it is only differential when used from within Onediff.

When you use it you are copying all data each time. If you get a broken pipe condition in the middle of a copy, restart the job.

That seems to be a simple broken pipe

O.K., so it was the sunday = 0 that was causing the issue apparently.
ESXi components are like Forrest's box of chocolate, you never know what you're going to get.

O.K., we saw where the problem is. It's a bug due to changes in the order of the fields of the ls command. We'll correct this today and publish an update as 11.2.7, it will be available tomorrow the latest.

Remember that you can always split the schedule in multiple lines.

ESXI cron is not equivalent to a Linux crond, it's a more primitive/basic kind of service, it lacks even an init control script to prevent duplicate execution and other such problems. As VMWare modifies Busybox source code, you can't even be sure of what is current ESXi version supported syntax and you can't trust Busybox documentation either, should it exist.

(c)VMWare does not seem to have published any post regarding the use of the crond service, so we can only guess and use a trial/error approach. The minute, hour and DoM seem to work as expected though.

I'm afraid it is not uderstanding the day range with the hyphen in between (1-6). Try to use commas to separate days. Some older busybox implementations took day abbreviations like: sun, mon, tue...

According to this openwrt.org document making reference to Busybox cron, sunday is 0 and using 7 will lead to commands being run every day.

[url=https://openwrt.org/docs/guide-user/base-system/cron]OpenWRT cron service user guide[/url]

-----------------------------------------------------------------

[b]Tip:[/b]

If you find that single days of the week work as expected, split your command into multiple lines, dirty but effective.

Well, we are still lacking some relevant info. What is the remote system you are backing up to?, is it Linux or ESXi.

If the remote System is ESXi you will need to configure a user that has all the appropiate rights on every of the files/folders implied in the backup process at the target, that is: read/write/create permissions on the target folder, which is a full privileged user on the target.

Same will happen on the target system if it's a Linux server.

The way to debug this is to run an SSH command that creates a file at your backup target folder and writes something to it. Enable ssh debugging and inspect the ssh client output.

ssh -vvv -p 22 -o PreferredAuthentications=publickey -o StrictHostKeyChecking=no -i xsibackup_id_rsa <user_backup>@<ip backup> "echo 'HI THERE' > /path/to/backup/directory/test_file.txt"

In any case if you performed this test with the root user and it succeded, then it means that your RSA public key was added to the root user [b]authorized_keys[/b] file, and not to the backup user one. Each user has a separate [b]authorized_keys[/b] file where public keys are stored for that user.

O.K., sorry about the "too quick" answer.

The initial premise is wrong, SSH won't be faster than NFS, unless you are connecting to a distant NFS server with high latency and you have configured NFS as syncronous.

You have no other choice than inspecting the authorized_keys file for that user manually, do so and reach as back.

Your XSIBACKUP public RSA key should appear at the bottom

You pointed out one of the keystones of chained backups. XSIBackup real power starts to unleash when you take advantage of the many different ways it can be used.

The two key facts to keep in mind are:

- Onediff will use a management snapshot to keep differential data. It will just be kept there in between backup cycles.
- All other backup methods will respect any pre-existing snapshots, they will take their own and backup whatever is there at the time to perform the backup. So the Onediff snapshot will still be there at the time the subsequent Onediff cycle takes place. In other words, you can do whatever in between Onediff cycles, just as long as you don't delete the delta snapshot.

From the two main facts above you can derive your conclusion: yes, you will be backing up the delta snapshot when you perform an XSITools backup and thus you will be keeping it as is. Deduplication will not affect the Onediff delta snapshots, so you will be worsening your compression ratio. Nonetheless, there's one advantage to it, as you will be keeping two restore points per XSITools backup, as you can use the snapshot or discard it.

[b](c)XSIBackup Datacenter[/b] is our next generation solution, it employs the same general principles as XSIBackup-Pro, but it's much simpler to use and it deduplicates everything, including small files.

[url=https://33hops.com/xsibackup-vmware-esxi-backup.html#prodchart](c)XSIBackup-DC product page[/url]

Synology and QNap are both excelent NAS devices manufacturers, but you cannot use their OSs as if they were a regular Linux distros. Root access is limited, even for some basic administration tasks, thus if you try to use them as an OS you will most of the times end up banging your head agains the wall.

You can easily gain access to any storage volume by just using a bridge Linux VM. Attach whatever volume you want to this Linux VM and backup to it over IP. You can attach disks via NFS, iSCSI, SSHFS, etc..., you just need the connected volumes to be available over SSH.

If you try to reach the Synology over SSH you will be hitting the fact that you don't have full root access, you will have to configure additional users and eventually fall into a permissions nightmare. Our recommendation is that you use the synology as an iSCSI or NFS volume and mount those volumes directly to the ESXi server or to some bridge Linux box.

Onediff is not a backup method, it is actually a replica method, it just keeps a mirrrored VM. Thus if you need multiple restore points, you should perform a backup on addition to Onediff.

The best part is that as Onediff allows you to keep the VM registered on a remote end, performing a backup on this idle VM will not affect performance in your production environment.

So run a Onediff cycle and then run an XSITools backup on the mirrrored VM, that will allow you to keep a virtually unlimited number of restore points on addition to the ready to use Onediff mirror.