Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Contact support and have your case examined, we cannot offer general answers to particular issues.

[b](c)OneDiff[/b] generates a mirror image and leaves a snapshot called [b]xsibackupdiff[/b] hanging off the base disks
You can then configure a second [b]Vmkfstools[/b] backup that backs up the same VM fully, cloning the VM from the hanging snapshot [b]xsibackupdiff[/b], which will in turn generate a new VM which will encompass the before mentioned snapshot.

Once the [b]Vmkfstools[/b] finishes, the Virtual Machine is left at the point where the subsequent [b]OneDiff[/b] cycle can re-take the job where the previous OneDiff cycle left it, namely with a snapshot called [b]xsibackupdiff[/b] that includes al writes since the previous OneDiff backup.

Once you have configured such Vmkfstools backup, just chain it to the first one by using the --on-error and --on-success arguments on the first [b]OneDiff[/b] backup.

If you backup to different paths, the VM folder, which never includes the suffix _XSIBAK, this is something that only appears in the VM name inside the .vmx file, will not be overwritten.

Support will contact you.
To know why your OneDiff backup is always reinstantiated, we need the full log, anything else from our part would be magic.

Try not to use any custom build especially from Fujitsu.
In fact, XSIBackup plainly does not support any custom builds.
We have detected some really nasty bugs on some of Fujistsu's ESXi builds:

[url]https://33hops.com/xsibackup-most-common-issues.html#kex-protocol-error-type-7[/url]

We aren't really fully comprehending what you try to represent in the code box.

Of course XSIBackup is able to backup your VMs to your QNap, but you must meet some conditions, one of which is to use an official VMWare build. Custom manufacturer builds aren't ESXi but plain commercial tools, most of the times just aimed at forcing you to buy hardware from some brand.

Second, but not less important: do not use NFS 4.1, it's simply useless for backup purposes and it just does not work in the shell environment. Switch to NFS 3 if you are using some other version. iSCSI and local disks will not give you any problem.

Yes, the option is still valid of course. You should accomodate the portion in bold characters to what you have in conf/xsitopts, in case you have tweaked the CHKMB variable.

--options=no-[b]500[/b]M-check

The size and first 500M check AKA [b]Trivial Check[/b] is extremely usefull 99% of the times. There are nevertheless some weird workarounds in VMWare snapshotting system related to Windows OSs, especially when quiescing them.

You cannot create a ghost partition on the fly, leave it there and state that is [b]by design[/b]. Well, you can, but you are then renouncing to being taken seriously. We all know the [b]by design[/b] and [b]we have still not come to a conclussion[/b] are common out there.

Using a Linux OS within ESXi is something seamless and will work like a charm when quiescing the OS.

Windows OSs are something apart. It's obvious that this two monster companies are having an open commercial war, as Microsoft tries to force their users to use Hyper-V. There are bugs, especially in everything related to quiescing, that have plainly not been resolved. That is most probably due to MS putting efforts in making their OSs not fully compatible with VMWare.

It's not a coincidence that quiescing MS Operating Systems be the battle ground, as this operation is critical to properly backing up mission critical servers, like Exchange or SQL Server, which are some of the MS flagships.

First of all, if you want to run mission critical services, use Unix or Linux. If you already have MS in place and still need to back them up, follow our guide to quiescing Microsoft OSs [url=https://33hops.com/esxi-snapshot-errors-and-solutions.html]Troubleshooting Windows Snapshots In Esxi[/url]

Be prepared to still receive some quiescing errors from time to time. You can use the --options=no-[b]500[/b]M-check argument at your own risk, but take the following on account:

If you take your time to quiesce some Microsoft Operating System in a mission critical 24x7 service, you might still find yourself fighting in the mud against some invisible bugs that cause quiescing operations to time out or raise errors in the MS Event Viewer, which are in turn catalogued as "ignorable" by the Microsoft Knowledge base articles.

Thus, it's probably wiser to use one of two approaches:

1 - Plainly run a [b]--backup-type=warm[/b] backup with no quiescing. This will imply not even 30 s. of downtime vs a nightmare that in the end will cause more downtime.

2 - Take a VSS snapshot prior to backing the VM up and delete it afterwards, also without quiescing in the virtual machine backup operation. This will ensure that you can discard the VSS snapshot and return to a stable configuration, should some I/O operation get trapped during the VM snapshot process.

You seem to be using XSIDiff with XSIBackup-Free, which is not supported nor licensed.
If you are a Pro user, contact support to request help for your particular case.

It's obviously far easier to attach the QNap as a datastore than to try to backup over IP to a locked down appliance.

For anybody of you willing to perform over IP backups:

If you can't control the device where you are suppoused to copy the data, you don't have much chances to get it rolling. Use regular OSs (CentOS, Ubuntu, Debian, etc...) as the target of backups over IP, otherwise, it's like trying to ride a horse in a cabin.

The key matter here is: what version is the remote ESXi server?, not the one where the VMs are.
If you copy some VM with HW version 14 to an ESXi 6.5.0, which only supports up to HW version 13, then you will get that error, as you will obviously not be able to use that VM in the ESXi 6.5.0 host.

You can do whatever you want.
"More than tested" means that if you follow our advice there's a 100% chance that your GUI works.
Messages such as [b]"unexpected redirection"[/b] are gross bash errors which aren't even indicating a problem with the program, but with the installation itself.
You can contact support to solve your problem, or stick to your older version, that's up to you.

1 - [b]--use-smtp=Y[/b] is wrong, you can't parse a letter to --use-smtp, it only allows integers.
2 - Do not use physical paths as the backup point, but the human readable hardlinkls, i.e.: --backup-point="/vmfs/volumes/backup"
3 - Do not use compression with OneDiff ([b]--backup-prog=onediff:z[/b]), 99% of the times it will be counterproductive.
4 - You have duplicated the [b]--backup-prog[/b] argument.
5 - You are missing a hyphen in the [b]-certify-backup=sha1[/b] argument.
6 - You do not need --certify-backup=sha1, as SHA1 is default, so just use --certify-backup=yes

Yes, of course you can just create your jobs manually, just follow this instructions here:

[url=https://33hops.com/xsibackup-free-11-things-that-have-changed.html](c)XSIBackup Classic: changes in version 11.0.0[/url]

You must have mixed some older files with new ones. What you should do is:

1 - Totally remove the xsi-dir and all traces of any previous installation

rm –rf /vmfs/volumes/datastore1/xsi-dir;chmod 0700 /var/spool/cron/crontabs/root;sed -i '/-dir\/jobs/d' /var/spool/cron/crontabs/root;sed -i '/cron-init/d' /etc/rc.local.d/local.sh

2 - Kill any eventual zombie processes related to XSIBackup

OLDIFS=$IFS;IFS=";";for job in $(ps -c | grep xsi | awk '{print $1}' | \
sed -e ':a;N;$!ba;s/\n/;/g');do kill -9 $job 2>/dev/null;done;IFS=$OLDIFS

3 - Install from the user area by using the script.

Please, note that if you want to install to some other path than the default one "/vmfs/volumes/datastore1/xsi-dir", you will have to tweak the example scripts to your needs.

Please, follow this troubleshooting guide. ESXi's cron can be picky to configure, nevertheless once you have set it up it won't fail, do not worry about that.

[url=https://33hops.com/xsibackup-cron-troubleshooting.html](c)XSIBackup Classic: troubleshooting the (c)ESXi cron[/url]