Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

We will publish pricing in a couple of days. It's the same concept, but [b](c)XSIBackup Datacenter[/b] doesn't share a single line of code with [b]XSIBackup-Pro[/b]. Nevertheless enterprise users will get:

1 Free license, in case of [b]Unlimited One Site License[/b] holders
2 Free licenses in the case of [b]Unlimited Global License[/b] holders.
Regular licensed users will get a discount equivalent to the price they paid for their XSIBackup-Pro license.

The final price for a regular license will be somewhere in between 150 and 180 EUR or the equivalent price in USD.
General rules for licensing will be:

- Per server
- No limit in the number of VMs
- No CPU limits
- Ulimited target systems for backups or replicas: ESXi or Linux.

Do not use ESXi 6.7.0 U2 in production. This is the best advice we can offer you.

[b]Input/output error[/b] is usually thrown by NFS when it can't access some file system.
That error is indicating some gross I/O error, your datastore is not accessible or usable, it has nothing to do with XSIBackup, it just can't work if it can't access data.

You can already download XSIBackup DC at this link, please read the manual, the concept is similar but the command line options and the way they are used change a bit. It is in fact a lot simpler to use than Classic XSIBackup.

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

We are finishing the test phase of a new product: XSIBackup-Datacenter, which has been programmed in C+Assembly, it will be much more powerful than XSIBackup-Pro, both in terms of compression ratio and backup and replication speed, while keeping the same XSIBackup principles. All Pro users will have an upgrade path which will deduce the amount they paid for their Pro versions.

I'm afraid that ESXi's crond daemon is not just like any other regular Linux daemon, it is in fact the one shipped with [url=https://busybox.net/]Busybox[/url], which is in turn the set of command line tools used by ESXi.

There's not much order in how functionalities are offered by ESXi, the SSH server is a customized independent binary, The LibC library is GLibC, but it has been stripped off some of it's functions and the crond binary is Busybox, which contains random bugs that change from one ESXi version to the next. Some other services are modified Open Source packages and you can find a lot of bugs (intentional or not) in all shell related functionalities.

Try to start with something simpler, i.e.:

* 20 * * * "/vmfs/volumes/OS/xsi-dir/jobs/001" > /dev/null 2>&1

And once you have it working add more options. Try with weekday abbreviations (mon,tue,wed,...) if the numeric values don't work. Also remove the leading zero from 06.

Check your busybox version in ESXi and find the related documentation, that might help you find your answers.

 # /usr/lib/vmware/busybox/bin/busybox
BusyBox v1.20.2 (2012-12-11 11:54:28 PST) multi-call binary.
Copyright (C) 1998-2011 Erik Andersen, Rob Landley, Denys Vlasenko
and others. Licensed under GPLv2.
See source distribution for full notice.

Usage: busybox [function] [arguments]...
   or: busybox --list
   or: function [arguments]...

        BusyBox is a multi-call binary that combines many common Unix
        utilities into a single executable.  Most people will create a
        link to busybox for each function they wish to use and BusyBox
        will act like whatever it was invoked as.

Currently defined functions:
        [, [[, addgroup, adduser, ash, awk, basename, cat, chgrp, chmod, chown, chvt, cksum, clear, cp, crond, cut, date, dd, delgroup, deluser, diff, dirname, dnsdomainname, du, echo,
        egrep, eject, env, expr, false, fdisk, fgrep, find, getty, grep, groups, gunzip, gzip, halt, head, hexdump, hostname, inetd, init, kill, ln, logger, login, ls, lzop, lzopcat,
        md5sum, mkdir, mkfifo, mknod, mktemp, more, mv, nohup, nslookup, od, passwd, poweroff, printf, readlink, reboot, reset, resize, rm, rmdir, sed, seq, setsid, sh, sha1sum,
        sha256sum, sha512sum, sleep, sort, stat, stty, sum, sync, tail, tar, tee, test, time, timeout, touch, true, uname, uniq, unlzop, unzip, usleep, vi, watch, wc, wget, which, who,
        xargs, zcat

Snapshots contain data that is not prone to be reduced by using deduplication. They normally contain new data generated by users or applications which is quite random. It could be compressed though and still save some space.

On the other hand some people like to keep snapshots at hand, so that they can use them in case they need to.

First of all, the Man Page clearly states that backup jobs must be three digit strings from 000 to 999
You have an error that you must pay attention to:

ERROR: there are some ongoing rsync process/es loaded into memory. Clean them manually

Use [b]ps -c | grep xsi[/b] to identify what zombie rsync processes you have in memory and kill them, i.e: [b]kill -9 12345[/b]

On the other side, if you don't want to differentiate between --on-error and --on-success actions, you can just add the jobs to a file

001
002
003

And invoke that file from the crontab.

That is virtually impossible, you can check the code if you will. The XSITools module reads the pre-existing .xsitools file in the root of the repository to know whether it is compressed or not, otherwise it creates a new one. Something like a quick non compressed try followed by a new attempt must have occurred.

In any case, just delete the repo and start again, the solution is simple.

You can't prune VMs alone, just backup folders. Create a new repository without that VM or prune the backup folders containing that VM once you have accumulated a number of backups that don't contain the VM.

No, XSIBackup has nothing to do with VMWare propietary APIs. It simply copies data from one share to another, I believe in your case by means of the [b]vmkfstools[/b] utility.

You have not commented any of the possible causes that we mentioned in our first response. We can't help you if communication is not bidirectional. Don't even try to use NFS 4.1, use NFS 3. NFS 4 does not work on the ESXi shell, this is not a guess, it just does not work.
Can you confirm that you are using NFS 3?

AFAIK you are mixing a Windows server acting as an NFS device and mounted on an ESXi box. Excuse our little sarcasm, but this is like the recipe for a poisson. It does not mean that it can't work, in fact it should work, what I mean is that you have chosen a dangerous combination.

You will need to debug the NFS protocol to find out the exact cause. if you are not willing to do so, just change your NFS server by something that will offer more guarantees.

VMWare and MS just hate each other, they have had all sort of incompatibilities affecting users. Some of them haven't been addressed by any of the parts for years. MS is now investing insane amounts of money in promoting Azure (Hyper-V) which is VMWare's most direct competitor...

Yes, we will have no other choice than releasing a new version with some older version of the very ESXi Hypervisor shell interpreter. We have tested it for quite a long time now and it works well with ESXi 6.7.0 U2.

Nevertheless using a version with a patch for an underlying bug is not something that we'll recommend our users doing. Not because XSIBackup won't work well, which we have tested quite thoroughly so far, but because that bug may be the source of other problems.

Taking on account that v. 6.7.0 U2 has accumulated a number of critical bugs and a high number of patches so far and that some are still pending, anybody using this version in production is playing russian roulette.

Previous versions from 5.5 are quite stable, especially 5.5, and more recommendable than 6.7.0 U2, it makes no sense using 6.7.0 U2 in production