Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Well, lets split thing up, there are many questions on top of the table:

1 - XSIBACKUP-PRO 10.2.1 addresses size mismatch errors when backing up to NFS, upgrade if you have not already done so. There are three builds of this release, so having the same version number does not mean you have the latest. If you use thick disks vs thin virtual disks, AKA sparse files, you will always get a size mismatch if you backup locally, new upcoming version 10.2.2 will address this. The easiest workaround by now, until we release 10.2.2 is to use the [b]--certify-backup[/b] argument.

2 - _XSIBAK VMs are ignored, to avoid backing them up by default. You can nevertheless make XSIBackup aware of those VMs by using the [b]--override=xsibakfilter[/b]. This is in the Man Page: [url]https://33hops.com/xsibackup-help-man-page.html#override[/url]

3 - The last screenshot is showing a "broken pipe" error, which is undoubtedly informing you of a transmission error, which could be, in turn, due to a hardware problem, faulty cable, or be just a derivate error due to a timeout or some other problem. Apart from that, the program output is telling you it's not finding the --backup-point you have set, which is definitive on its own.

4 - I see you are focusing very much on [b]XSINAS[/b], which can be a great tool. Many people try it and they like it so much that they try to use it for almost everything. As any other tool has its pros and cons.

XSINAS was the first deduplication method we released along with XSIBackup, then support for Borg backup was added and in the end we released [b][https://33hops.com/xsitools-vmfs-deduplication.html]XSITools[/url][/b], which is the newest deduplication program available in XSIBackup. In fact XSITools is the recommended method to archive VMs, as it's faster and much more powerful than the other two. Borg is a great deduplication program, but as XSIBackup cannot run a true Borg client, due to ESXi not being compatible with compiled Python binaries, you are limited to sending all data over the network, which is a serious inconvenient.

XSINAS is an inline deduplication FS based on FUSE, this means that the data stored there is directly accesible through the file system. Inline deduplication file systems have their own disadvantages though: they need to do the hash search plus the eventual compression on the fly as data is written to disk. This leads to making them extremely resource hungry, and this literally means that they will use as much memory and CPU as you can add, and that they will clogg as you add more data into them, as they will need to look for chunk's hashes in a growing database.

This makes inline deduplication filesystems not so ideal to store huge volumes of data, as you will be using most resources in a feature that is not so interesting at the time to archive data, being real time or inline is not something fundamental to storing data. What is then XSINAS useful for?: well, you can use it to store limited amounts of deduplicated data, to serve as a file server, to store VM system disks, which don't change much over time and are basically read devices, etc...

On the contrary, [b]XSITools[/b] has been designed with a single purpose in mind, namely to store or archive VMs. The block size is very big, default is 50M, and the database is the very same FS. It just uses the amount of memory to manage the deduplicated chunks, one at a time, this makes XSITools extremely lightweight and fast.

We have used a proxy in the States to make some tests and the results are O.K., we can login into the user area and access all entries in the menu. The CDN asked us to verify we were human, but nothing out of usual apart from that. We still have some small and annoying JS bugs related to HTML entities, but I don't thinbk that is what is causing your issue. Again, if you need something you can't perform on the website, just write to us.

We have moved the topic to XSIBACKUP-PRO general matters, it was on XSIBACKUP-FREE section.

We made some changes to our website taking the chance that there are less users in Christmas time. It's working well for us, but depending on your browser and its configuration, you may need to remove cache manually, they (browsers) sometimes tend to cache content very aggresively, even though the user section is marked as "don't cache anything".

If you are using Chrome, just go to advanced configuration and remove all files and images.

Not with the free version.
You can nevertheless program those backups at different times.

You may encounter different problems when backing up to a lower ESXi version. From a pure copy and data transfer point of view, everything is O.K., but OneDiff uses some ESXi functions to generate the cloned VM. So if you are using a hardware version which is only compatible with ESXi 6.5.0, then the copied data will not be regarded as a compatible VM set of files.

The key to your issue is this error:

info: the backup mirror VM [Debian_desktop_XSIBAK] Id (vim.fault.AlreadyExists)
...
The specified key, name, or identifier '17' already exists.

This is a very obvious error, the host is letting you know that a VM by the same name is already registered to the host.
So, delete any [b]Debian_desktop_XSIBAK[/b] VM, remove any folder named Debian_desktop, corresponding to the previously removed VM, that may still be there, and start again.

If, on the other side, you still have problems due to Hardware Version incompatibility, you can use [b]XSIDiff[/b] for the backup, which will still be very fast over a network, or [b]vmkfstool[/b]s if copying locally.

In any case, you won't be able to use the backed up VM in the ESXi 6.0.0, if HW versions are incompatible. You would be using the ESXi 6.0.0 box as a mere container to store your data. You would need to copy the data back to an ESXi 6.5.0 host to be able to switch it on.

There is a small bug with grep and some ESXi version that we have already solved in v. 10.2.0, nevertheless that bug should not affect you if the needed files are already in place. Please note that you cannot copy the bin folder striping it from the rest of the program files.

Stick to 10.1.0 until we release next version or write to support to get a working preview of 10.2.0

You have removed the output header, so we don't know which version you're using, maybe 10.0.4?
We'll check this in case it's a bug, in any case, have you tried copying the xsibackup-rsync binary to the remote's machine dir

/vmfs/volumes/595249eb-79426204-9f2d-c81f66c63f4b/xsi-dir/bin/xsibackup-rsync

There's a security and maneuver margin of some gigabytes, you need more room to be able to store multiple backups, maybe even a single one.

You have a number of different options to accomplish what you want:

1 - You can edit XSIBackup to accept whatever time mask you want.
2 - You can use ESXi's crontab to launch your jobs.
3 - You can use any external crontab to lauch your jobs via SSH.

[url]https://33hops.com/xsibackup-help-man-page.html#mailto[/url]