Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

I guess the days of week have 0 base
You should upgrade to 11.1.9 that will be launched today, should you use the GUI to run jobs or check servers per instance. There is a bug that prevents this operations from completing.

This is a bug on the GUI, while we fix it, please just run the job from the command line

./xsibackup --run-backup=001

When you cut and paste it is very common that characters get substitued by some other equivalent in some other page code. Try to input the data manually, or develop your skills as cutpaster. You also seem to be missing some backslashes "\" at some line ends.

You still have mixed content, that is not a very good solution.

Well, that's 85 mb/s on the whole disk including zeros. If you use thin disks and/or a VMFS volume to store your production VMs and your virtual HD is only partially used, you should get much faster speeds. That depends on the load of the server at the time to perform the backup though.

If you use OneDiff to backup, you will loose any preexisting snapshot, if you use XSITools they will be preserved.

This is not content for a forum, we might delete this whole thread.

If you don't know the support e-mail address, which was sent along with the welcome e-mail sent upon purchase, send us a contact form from our website: [url]https://33hops.com/contact-form.html[/url]

Please, identify yourself as the holder of a valid license, the registered e-mail is enough.

Check your [b]conf/smtpsrvs[/b] file and fix it. You have entered the SMTP credentials in a wrong way. The syntax is explained in the file itself.

We already use OpenSSL for hashing, thank you for the feedback.

You cannot switch from [b]--backup-prog=XSITools:z[/b] to [b]--backup-prog=Vmkfstools[/b] without changing the [b]--backup-point[/b] to a different path, or you will be trying to overwrite an XSITools repository with Vmkfstools backups.

The solution to your problem is very simple: change the [b]--backup-point[/b] argument to some other path or delete the old XSITools repository and reuse the same path.

This kind of message:

Input/output error (5) rsync error: error in file IO (code 11) at receiver.c(389)

Is thrown when some sort of lower level problem occurs: hardware or communications error. If I were you I would quickly run some S.M.A.R.T. diagnostic on your disks and check everything regarding the reliability of the network in between. The fact that it's always the same VM that fails may have to do with some particular portion of the disk being damaged. There could also be some recurring network instability happening at about the same time every day, try to delve a bit by changing the VM backup order, although it seems a disk IO error, most probably your disk is starting to fail.

As XSIBackup and XSITools evolve, rotation will be achieved by pruning instead of by creating a new repository. Nevertheless, comprehending what deduplication is, necessarily involves being aware of the risks you assume and covering those risks appropiately, so some sort of redundancy is desirable, whether by keeping a historic archive or by cloning the repository itself.

Keeping some snapshots in your production VM is a good technique to achieve versioning while still using regular backup methods. The only drawbacks I can find is that 5 snapshots will limit performance, maybe not too much, that will mainly depend on your particular circumstances: hardware, load, concurrent users, etc....

On the other side snapshots are unique pieces of data, they can't be deduplicated, at least with a big block size. Even a small block size would not yield better results due to the nature of what a snapshot is. Obviously that will depend on the type of data you store on them. If we are talking about a server in a notary office where snapshots are constitued by thousands of Word documents, then maybe you would be able to achieve some sort of positive result with a small block size, still that's not very common and snapshots tend to be unique in the vast majority of the cases.

Thank you for the feedback, we'll take a look at it, although we are constrained by ESXi, so any piece of software that is not pure C has little chances to run on it.

Well, if you call "crash" to the program "exiting back to the command line", then we are not going to understand each other.
What you are describing so far seems to be normal behavior.