Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Contact us to get some older version.

We will revise the code to try to identify your issue, nonetheless it's not a generalized problem and must probably affect some particular condition that you share.

JoJo: you never provided any details on your issue in this forum. Please, do not assume or make others think that you share some common problem when you have not provided details that demonstrate that, it's misleading.

Wowbagger's issue is not even about backup, the segfault is raised when processing information on the VMs, not when backing them up. It's probably something quite trivial, still it will need to be identified to offer a solution.

Please, try to give as much information as you can: whether you are using NFS or VMFS, the size of your VMs, the jobs and output. This goes for JoJo, Wowbagger has already provided enough info.

UPDATE:

Contact us on support and we will provide some special debug version/s with some extra messages that will detect where exactly things are going wrong in your case. Once we detect where the issue is we'll publish the conclusions, otherwise we are going to make this post grow with speculations on the possible cause.

[quote=wowbagger]Splitting did not really work for some reason, perhaps it has to do with the VM name characters. I'm looping over the list so there is just a single xsibackup invocation each time as opposed to providing a long list of VM's.
I noticed in /scratch/downloads/ the exported configs .tgz files accumulate, maybe also a candidate for cleaning after a backup run.[/quote]

Version 1.4.2.8 will include a [b]/scratch/downloads[/b] folder clean up.

Just another seemingly silly question.
Did you exchange keys with the remote host to be able to access the remote FS?.

There is also some clarifying message:

[b]Illegal seek[/b]

We would need to debug your particular set up to find out the exact cause, but we can't do that if you go your own way.
The thing is that DC has some dependencies that we cannot guarantee to be met by any Linux distro, thus we recommend CentOS/RHEL because we have tested them thoroughly. We have also tested it on Ubuntu and some other distros.

If you use some distro out of the recommended ones, you are entering unknown territories.

A good way to minimize incompatibilities is to just copy the public key to the remote server's [b]authorized_keys[/b] file, that is: exchange keys manually and then retry. Again, we don't know what that distro might have installed by default or whether even if xsibackup can run there.

Try at least to login to the remote host and run:

# xsibackup --help

To see if the binary can execute in the server side.

Nothing around variables length seems to be the issue. The fact that your VM list is so long made us pointed our investigation in that direction.

We found this message in your log:

[b]Could not retrieve disk metadata all blocks will be scanned[/b]

That indicates that some of your VMs reside in an NFS host or that the metadata for that VM is corrupt, as it could not be retrieved.

If you have mixed datastore types VMFS & NFS, try to group VMs by datastore type into two different jobs. We will check that posibility in search of an eventual bug.

If you don't have NFS datastores, then clone that VM with vmkfstools to regenerate the associated metadata.

[b]JoJo[/b], your problem should be fixed by now, if not contact us for a remote session.
That kind of errors happen when something goes out of control e.g.: a full FS.
There were some circumstances in which the /tmp folders could fill up, we are working to fix that on 1.4.2.8
Please remove the /tmp folder and the local tmp folder at installation root:

rm -rf /tmp/*
rm -rf /scratch/XSIBackup-DC/tmp/*

If the problem persists, just contact our support e-mail to appoint a session too.

UPDATE:

We believe it could just be some variable holding the VM names overflowing, still it halts the backup.
Try to split the VMs in two groups until we find the exact cause. We were about to release 1.4.2.8, we'll wait a bit to check all those implied vars.

Set the remote location of the xsibackup installation path using the
[b][url=https://33hops.com/xsibackup-help-man-page.html#remotexsipath]--remote-xsipath[/url][/b] argument.

Thank you for your feedback.

It looks like you already have some dir by that name at: /scratch/XSI
Delete it manually.

If you took the time to trace this error down to its primary cause, you would probably find it has to do with the MySQL service, could also be any other service running in the VM which refuses to be quiesced or is not playing well with VMWare Tools.

In case this is not caused by some incompatibility or lack of some piece of software, a reboot will help it. If, on the contrary, this is caused by some sort of incompatibiity, you will need to contact the vendor

You only have one issue: not being able to delete the snapshot. The rest of errors are just derived from that fact.
Not being able to delete a snapshot is one of the most common errors in (c)ESXi, it can be due to a number of reasons.

(c)XSIBackup-Pro is just the postman, it forwards the message thrown by the (c)ESXi shell, which we agree is not very verbose.

To delve into the details on why that error was raised you will have to search in the VM and host logs. You will find the VM logs in the same dir where the .vmx file is kept, the host logs are at /scratch/logs, we would take a look at [b]/scratch/log/hostd.log[/b]

Most common reasons are:

- You are trying to quiesce a service, but (c)VMWare tools are not installed or they are not working properly with the service to be quiesced.
- There isn't room enough to perform the operation.
- Some disk is damaged.
- Some ESXi service is not working properly.

Before going any further, just reboot the host. If the problem persists, you can read our posts on how to deal with snapshot errors:

[url=https://33hops.com/esxi-snapshot-errors-and-solutions.html](c)ESXi most frequent snapshot errrors and solutions[/url]
[url=https://33hops.com/troubleshooting-windows-snapshots-in-esxi.html]Windows specific post on snapshots[/url]

Then you have a different kind of problem.
Why are you focusing on trying to fix a problem that you don't have while ignoring the key matter?.
Sorry for being that clear, but it doesn't make sense to offer support without being cruelly sincere.