Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

This bug will be solved in next version 1.3.0.0, sorry about the inconvenience.

Onediff is included in (c)XSIBackup-Free
It just lacks the checksum comparison after integrating the diff data present in Pro version, which is a must have for enterprise use, but you may use it in Free version as well.

[b](c)XSIBackup-Free[/b] does not include some advanced features. If you can afford to stop the VM for a minute, just perform a [b]--backup-how=warm[/b] backup.

Thank you for your feedback, but if we change the license model to a per VM basis, I believe many of our clients will be mad at you.
We may change the freemium model in the future, but we honestly don't try to please everybody.

We are a small company and need every cent we get out of our work, we believe to offer a good product at an unbeateable price and -over all- our products work in a transparent way: no propietary data models, standard protocols, no hidden "surprises".

You may suffer from disk metadata corruption, this is quite frequent in big NTFS disks which aren't defragmented when needed..

We don’t say so because we heard or read about it somewhere, but because we have some cases like yours per year against not a single file system level data corruption so far since 2013 on ext3, ext4, or XFS file systems (Linux).

Now, what to do?

First run this command on your .vmdk disk:

vmkfstools –t0 /path/to/the/disk.vmdk

Don’t try to look for the command in vmkfstools help, it’s undocumented.
You should get a list of extents. In Linux FSs this list is rather small. On Windows FSs it can become extremely long. This is due to data fragmentation in the Windows guest, especially since many sysadmins don’t defragment there Windows guest’s file systems until they are broken.

Apart from that aligning FSs in the virtualization stack can become rather important too in terms of performance.
[url=https://www.boche.net/blog/2009/03/20/storage-block-size-and-alignment/]A must read post on virtualization storage block alignment[/url]

So, getting back to the matter.
You will probably find lines like this in your extent list.

[ 2174627086336:   536870912] --> [NOMP -- :(           0 -->    536870912)]
[ 2175163957248:   536870912] --> [NOMP -- :(           0 -->    536870912)]
[ 2175700828160:   536870912] --> [NOMP -- :(           0 -->    536870912)]
[ 2176237699072:   536870912] --> [NOMP -- :(           0 -->    536870912)]
[ 2176774569984:   536870912] --> [NOMP -- :(           0 -->    536870912)]
[ 2177311440896:   536870912] --> [NOMP -- :(           0 -->    536870912)]
[ 2177848311808:   536870912] --> [NOMP -- :(           0 -->    536870912)]
[ 2178385182720:   536870912] --> [NOMP -- :(           0 -->    536870912)]
[ 2178922053632:   536870912] --> [NOMP -- :(           0 -->    536870912)]
[ 2179458924544:   536870912] --> [NOMP -- :(           0 -->    536870912)]
[ 2179995795456:   536870912] --> [NOMP -- :(           0 -->    536870912)]
[ 2180532666368:   536870912] --> [NOMP -- :(           0 -->    536870912)]

Those are dead extents pointing nowhere in the physical disk, “dark matter”.
Clone your disk with vmkfstools (all of them), repeat the –t0 command and chek whether the dead extent information disappeared, then reattach them to the VM.

©XSIBackup can’t warn you about that cause it’s one reality level below what it can see. It just believes your disks are O.K. so long as ESXi believes it.

If [b](c)XSIBackup-DC[/b] is installed in the [b]/scratchXSI/XSIBackup-DC[/b] default location, why does your job point to some xsibackup binary in a different place:

/vmfs/volumes/xxx/xsi/xsibackup

The job also points to some xsibackup.log file in a different place.

>> /vmfs/volumes/xxx/xsi/var/log/xsibackup.log 2>&1

Delete the request.key file, let a new one be generated and upload it to get a new license.key file. Then contact support to remove the old license file to free the slot in the user area.

Your problem has nothing to do with XSIBackup, but with the virtual disk. First thing we would do is switching the server off and rebooting it after some seconds off. In case this doesn't help, clone the disk with vmkfstools, be careful not to clone it to thick in case it's thin.

Run

vmkfstools -i /path/to/your/in-disk.vmdk /path/to/your/out-disk.vmdk -d thin

Then use the output disk instead of the original one and see if this helps the problem.

As with any other Linux binary, you may need to clean up memory by using ps command and kill -9 on any eventual ghost process.
This should be exceptional of course, just as long as you set things up in a proper way.

Waiting for a job to finish is the opposite approach that we took, it would generate more uncertainties, as the lag would be propagated forward.

Just as long as you just chain jobs in a classic Linux style, you will be safe from overlapping jobs:

i.e.:
File: /scratch/XSI/XSIBackup-Pro/etc/jobs/700

Content:

[b]Example 1[/b]: you run jobs one after another, no matter what happens

/scratch/XSI/XSIBackup-Pro/etc/jobs/001
/scratch/XSI/XSIBackup-Pro/etc/jobs/002

[b]Example 2[/b]: second job runs in case the first suceeds

/scratch/XSI/XSIBackup-Pro/etc/jobs/001 & \
/scratch/XSI/XSIBackup-Pro/etc/jobs/002

Well, we would be careful and not use XSIBackup on [b]ESXi 7.0.0[/b] ultil we announce compatibility, as per our initial tests ESXi 7.0.0 locks the [b]-flat.vmdk[/b] files.

As per our tests, backups performed by means of the [b]--backup-prog=Vmkfstools[/b] backup program will run just fine. All other backup programs will just not work on [b]ESXi 7.0.0[/b]

Edit the code and enable at your own risk. What ESXi version are you planning to use?.

You should not be using [b]--backup-prog=xsitools[/b] with [b]©XSIBackup-Free[/b], it is a test feature which will not allow to restore backups unless you buy [b]©XSIBackup-Pro[/b], use some other backup program instead, we recommend that you use [b]--backup-prog=Vmkfstools[/b]