Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Just go to line 795 of the main xsibackup file and add the version to the compatibility check.
We haven't still certified XSIBACKUP-PRO to be used with ESXi 6.7, but there's no reason why it shouldn't work.
Give us some feedback on how it worked for you.

The only issues that may show up are related to shell's binaries: sed, grep, awk, etc...
They are pretty buggy and bugs change from one version the the subsequent one, although we will be able to work them around one way or another in case they appear.

And do remember one of our favourite quotes:
"Being the first to use some new version in production, is equivalent to being the first to try the Caesar's food"

UPDATE:

[b]Input/output error[/b] is an NFS error. NFS v3 works in ESXi out of the box, nevertheless, if you use NFS 4.1, ESXi might allow you to mount the NFS share, even though the transport layer may not be working properly. This situation leads some users to think their NFS share is working and blame some other part of their system.

To troubleshoot this:

1. First of all try to copy some file to your NFS share manually. You will then get the same error, this will note that the problem is at the storage protocol level, and has nothing to do with the application level.

2. Read your NAS or NFS server documentation. Most manufacturers publish information on how to configure it properly to be used with VMware ESXi hypervisor.

3. Please, do note that using NFS 4.1 to attach a backup device is useless. There is the common missconception that multipathing and other forms of link aggregation will sum the bandwith of all available NICs, when it does not work that way. A single file is always transmitted through a single path or NIC.

So, use NFS 3 for your backups and leave NFS 4.1 for your production environment, where having multipathing and multiple NICs available will be a great asset.

Event handling (--on-sucess & --on-error arguments) are only available in the Pro version

We'll release a fix for the Pro version first and depending on the load of work apply it to the free version. While this happens, you just need to make sure XSIBackup can work synchronously.

We'll review this point, thank you for your feedback

SOLUTION:

We found where the problem may be
In line 2180 of main xsibackup file (approximately), you'll see this

cp "$NVRAMFILEPATH" "$thedir"

This is valid, not only for the .nvram file, but all the other config and state files: .vmx, vmxf, .vmsd, ...

If the directory [b]$thedir[/b] does not exist, the contents of the config file are copied to a file named after the [b]$thedir[/b], instead of being copied to a file inside this directory.

But that directory is undoubtedly created around 18 lines above.

The only reason why this could happen, is that you are using asynchronous NFS and the directory creation is taking too long, so that when the copy operation takes place, the directory doesn't exist yet. So, switch back to sync NFS. Async NFS is not fully supported by XSIBackup-Free, but can be enabled on your NAS by default or by mistake.

When we say that it's not fully supported, we mean that it may very well work, but the logic of the program does not expect an async operation at that point.

Your server does not seem to support PIPELINING, just try with another server that does, a GMail account per instance

Well, there are some tangled up matters here.

If you talk about a laptop, it's role could only be as an SSH connected device. You were probably running Putty or some other SSH client, is that O.K. (we have to guess). So, if it restarted, it does not matter much, the backup job still continued in the ESXi server, but the output went nowhere.

To see what happened you should reconnect to the ESXi host, but trying to reconnect to the TTY that was holding the session might not be feasible, the apparent structure of TTY files is similar to Linux servers [b]ls -la /dev/tty*[/b], and you even have the stty binary aboard, but it just does not accept common commands as stty < /dev/tty/0

stty < /dev/tty/0
-sh: can't open /dev/tty/0: no such file

So your best bet is to check the VM backups themselves, by per instance checking the last modified file after switching them on. XSIBackup does not log the onscreen output when used as a user program. You should only use it onscreen for testing purposes and then schedule through the crontab (xsibackup-cron).

In regards to the E-mail report, you should be able to fix that easily, you are using XSIBackup with your feet tied up and one hand in your back.

We have been trying to reproduce this error without success so far.
If anybody else is getting it, please provide all details: full log and backup job, otherwise we are just especulating.

The file specified is not a virtual disk (15)

is a generic vmkfstools error that is generally raised when you try to copy a file that is not a .vmdk descriptor.

Getting this error when using XSIBACKUP-FREE could only mean that the parsed file is not a .vmdk descriptor, that the file descriptor is corrupt, that the file is currently open by other process or some lower level cause. This post has many visits, but most of them are just generic searches not having to do with XSIBackup.

We don't know what's the size of your VMs, but if you are getting effective speeds below 50 mb/s, you should think about improving something (maybe the network hardware), or detecting where the bottleneck is, in case you don't already know it.

for j in $( ps -c | grep -v grep | grep xsi | awk '{print $1}' );do kill -9 $j;done

The Pro trial coalesced with the Free version recently.
There aren't any programmed releases of the Free version until, at a minimum 3 weeks, maybe more, depending on how we can take advantage of our time.

Disks exclusions are working normally on the currently available Pro version 10.3.2.
I'm afraid this is one of those moments in which you have to trust somebody's word or keep on waiting.
Sorry about that, but obviously we dedicate our time to give service to our pro users mainly.

Are you disabling vMotion? [b]--disable-vmotion[/b] argument during the backup.
It looks like your VMs are being moved around by DRS.

The argument [b]--options=unreg-xsibak[/b] just unregisters the VM at the host where it was found when performing the backup, it could not cause a VM to become orphaned by itself.