Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Then inspect your descriptor files as stated above and find out where those [b]-flat.vmdk[/b] files are, cause if there are no [b]-flat.vmdk[/b] files, there is no data, there are no VM.

We don't support manufacturer builds. They are plainly not ESXi, as they are heavily customized and they frequently contain bugs.

That does not mean that [b](c)XSIBackup[/b] will not work with manufacturer builds but that we can guarantee nothing, as manufacturers frequently do not respect basic principle designs of ESXi.

Your problem seems related to your .vmdk files having been edited by some non UTF-8 text editor or containing bad pointers to -flat.vmdk files.

We know that, we may change that behaviour in future versions, but that shouldn't make a difference in any case.
[b]--options=unreg-xsibak[/b] will unregister the VM in every backup cycle. This is convenient if you are in a [b]vCenter[/b] context, as it might check for virtual MAC addresses duplicates even on switched off VMs.

Register the VM manually if you need to use it and try not to register VMs automatically to prevent MAC duplicates.

Pro users may write to support to request a working version, which basically consists in XSIBackup running on its own shell. Free users should not worry much, just wait for VMWare to fix the issue.

ESXi is still the best hypervisor by far, but this guys at VMWare are going downhill lately, you can tell a "disturbance in the force" at their tech HQ ;-)

VMWare released a patch for this bug.
[url=https://33hops.com/forum/viewtopic.php?pid=2104#p2104](c)VMWare patch for the Bash interpreter[/url]

Nevertheless, for goodness sake!, don't use in production some OS that just came out...
We sometimes use metaphores, gags or funny stories like being the "Caesars food taster", but this is something serious.

Nobody with some minimum experience and know how will put into production some OS that has been released "the day before".
Use some stable and well known version, most stable ESXi version from our experience is 5.5, although 6.0 and 6.5 have been out long enought to have some guaratees about its stability too.

This is a general comment, if you were just testing 6.7.0 U2, then this is obviously not for you.

Well, there isn't really something that could be considered a "complex install". ESXi installs in some minutes. If you have some config backup (XSIBackup does them by default), you just need to reinstall ESXi preserving your datastores, then just unzip the contents of the server config backup and overwrite the /etc directory, that's all.

You can also use the built in commands. Copy the config backup to the temp dir and use the vim-cmd utility to restore it:

vim-cmd hostsvc/firmware/restore_config /tmp/backup-file.tgz

It's a pretty straight procedure that works like a charm. Just as long as you install the same ESXi version that the backup corresponds to, you won't have any problem.

This entry in your [b]root-crontab[/b] is wrong:

58 12 * * * "/vmfs/volumes/Areca_Raid10-04_DEV01/xsi-dir/jobs/010" > /vmfs/volumes/backup/log.log 2>log2.log

It should be:

58 12 * * * "/vmfs/volumes/Areca_Raid10-04_DEV01/xsi-dir/jobs/010"

Use the GUI to generate the contents of your [b]root-crontab[/b] file by going to "Manage backup jobs" => "Schedule"

You can't just download a binary and put it into your ESXi server. Please download latest version to fix your issue.

There's what seems to be a bug in the bash interpreter shipped with ESXi 6.7 U2. We have developed a solution as XSIBackup-Pro 11.3.0, but it's still in validation phase. In this post we treat the matter and offer a workaround.

We recommend that you avoid ESXi 6.7.0 U2 until VMWare releases a patch. If you can't skip this build and you are a Pro user, you can try XSIBACKUP-PRO 11.3.0, it's working quite well for us so far. Write to support to ask for it.

Rename the job:

mv 2 002

And change the name of it in your cron files:
- [b].../xsi-dir/root-crontab[/b]
- [b]/var/spool/cron/crontabs/root[/b]

You may need to change permissions on your ESXi crontab to be able to edit it, if so:

chmod 0700 /var/spool/cron/crontabs/root
vi /var/spool/cron/crontabs/root
chmod 0600 /var/spool/cron/crontabs/root

We can provide an upgrade (v. 11.2.5) that contains a fix for this issue. The fix consists in XSIBackup being shipped with its own bash interpreter, still XSIBackup will depend on the other Busybox utilities present in ESXi PATH variable.

Contact support to get the update, we won't publish it for download ultil it has gone through the regular verification and testing process.

The near future evolution of XSIBackup will be to use its own shell, avoiding this way any incompatibility caused by the ESXi shell utilities. It will then depend on the ESXi's GlibC library mainly.

Yes, job files aren't supposed to hold comments. You have a description argument for that purpose.