Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

That is indeed a deprecated version of our software, it's more than two years old and will not be maintained any more.

We don't know the exact reason for your problem, nonetheless there is an argument to explicitly set the remote path: [url=https://33hops.com/xsibackup-help-man-page.html#remotexsipath]--remote-xsipath[/url]

This is all fixed in 1.5.1.8 which will be released in short

Quiescing issues are always relative to the OS, version, running services and many other circumstances. Still, the most important thing is to comprehend what it is and how to deal with it. We have covered this in many posts and articles before, I will offer an excerpt here:

Some services like databases, specially if they are busy systems, require that their pages are fully written to disk to be 100% consistent. Let's say you have a series of SQL statements that add some data to your DB. If the snapshot is taken in the middle of some I/O operation to disk, the cut point may not include the final statements and the closing bytes of the transaction. This would cause that restoring the VM backup would return some corrupted DB message from part of the DB system.

Do not panic. When someone uses the word corruption one tends to think of some fully corrupted data from the beginning to the end. In case of non-quiesced snapshots, what you have is some unclosed page written to the DB. Fixing it is easy, it just requires to run some standard repair tool that will get rid of the partially written data. Still, that is a hassle and in case of big DBs might take some valuable time.

This is where quiescing comes in handy. Quiescing is a concept, it may involve many different pieces of software depending on the OS and DB system you are using. Microsoft OSs are in general trickier to quiesce than Linux. You will usually need the Virtual disk service running plus Volume Shadow Copy service in automatic mode and, off course, the latest version of VMWare Tools correctly installed.

The checklist below will do it most of the times:

Virtual Disk service is started and startup type is Automatic.
VMware snapshot provider service is stopped and disabled.
VMware Tools services are running.
Ensure that Volume Shadow Copy service start up type is Automatic

There exist additional helper services for MS SQL Server and Exchange that may be required in your case.

But the above are just the steps to take to get (c)VMWare (c)ESXi to quiesce your system without errors. You need to comprehend what's behind this, which in the end is very simple and easy to understand.

What the different quiescing mechanisms do is to put the DB system in Read Only mode, flush any pending DB I/O buffers (namely: write any pending data to disk) and take the snapshot. When the snapshot is finally taken the DB system is put back in RW mode. This usually requires just some seconds to complete 3-5 seconds from our own experience. During that time the DB system is still available for reading, thus there's only a short glitch for writes which can easily be addressed from the application layer by just delaaying some write when you get a RO message from the database server (to be continued)...

Now, the thing is how to accomplish the above for every database system and OS.

As said there exist some helper services that will do that for you and may add some more sophisticated logic that will minimize the downtime, still there will always be some minimal downtime. As stated, this can be addressed from the application layer.

What if I have some DB system that does not offer some helper service to accomplish the above?: well you can do it on your own with the help of a script from within (c)VMWare Tools. This script will handle three events: freeze, thaw and freezefail

[b]Windows batch version[/b]:

Create the dir: C:\Program Files\VMware\VMware Tools\backupScripts.d

Create some file inside of it and run the code below adapted to your own DB system, we are using some code suitable to be used with MariaDB or MySQL. The scripts in the above dir will be run in alphabetical order.

FREEZE is the event that will be run just before taking the snapshot
THAW is the event that will be run when finishing to take the snapshot
FREEZEFAIL is the event that will be run when the snapshot fails to be taken.

@echo off

if "%~1" == ""         goto USAGE
if %1    == freeze     goto FREEZE
if %1    == freezeFail goto FREEZEFAIL
if %1    == thaw       goto THAW

:USAGE

echo "Usage: %~nx0 [ freeze | freezeFail | thaw ]"

goto END

:FREEZE

set PATH=C:\Program Files\MariaDB 10.6\bin\
mysql -uroot -p"yourpassword" -e "FLUSH TABLES WITH READ LOCK;SET GLOBAL read_only = 1;"

goto END

:FREEZEFAIL

set PATH=C:\Program Files\MariaDB 10.6\bin\
mysql -uroot -p"yourpassword" -e "SET GLOBAL read_only = 0;UNLOCK TABLES;"

goto END

:THAW

set PATH=C:\Program Files\MariaDB 10.6\bin\
mysql -uroot -p"yourpassword" -e "SET GLOBAL read_only = 0;UNLOCK TABLES;"

goto END

:END

What is explained here is basically the same concept applied to make some consistent backup of a running database server.
There exist some wrapper SQL commands like [b]FLUSH TABLES FOR EXPORT[/b] that will basically join the flush and set to read only operation.

You need to take immediate action. Stop the backup for that VM and solve the issue.
You should see some error in the backup report or log, unless those snapshots where there before you started to run the backups.

Errors taking snapshots usually have to do with some rogue service on the guest not responding to VMWare Tools. I believe your snapshot is with --quiesce, isn't it?

Check the event viewer or VMWare Tools log

Yes, disk names should be unique per VM. Just rename them.

Take a look at <install dir>/etc/xsibackup.conf

# When power on/off request is issued, the VM power state is queried every N seconds

power_query_interval=2

# When power on/off request is issued, the VM power state is queried N times
# Thus the power state will be queried a total of power_query_interval*power_query_times seconds
# Should the query_times limit be reached, a plain power off will be issued

power_query_times=10

As explained there (c)XSIBackup will try to perform a controlled shut down as per the above mentioned variables before issuing a plain power-off.

We like to torture VMs specially VMs hosting DB servers. We have some CentOS 6.0/ MySQL 5.6 here that we have been excruciatingly powering-off in the rudest manner for years and they never suffered from DB corruption, although that will off course depend on how busy the DB is when you commit the crime.

Yes, --quiesce will issue a quiesce request, thus you can use regular pre-freeze/ post-thaw VMWare Tools scripts to prevent DB corruption.

We already fixed that typo, it will show up in some hours.

Please, remove the --verbosity argument and see if you still get the error, it might just be a spurious error coming out of the remove command.

Your (c)XSIBackup installation dir seems to be at some shared DS (0c6d4303-b890de35) instead of a local dir. We strongly recommend not doing so to avoid this kind of problems. Install to /scratch/XSI/XSIBackup-DC

You are getting an error stating that there is a file which is still open

rm: can't remove '/vmfs/volumes/0c6d4303-b890de35/xsibackup_1.5.1.6_olympus2/XSIBackup-DC/tmp/4773327/.vnfs-f000340a0-.blocklog: Device or resource busy

UPDATE:

To keep finer control  once you have some CBT job running for some time use the alternative command line option or edit the files. Per instance to resync some previously synced blocks if you changed some faulty HD per instance. In any case, if you want to make sure that you completely reset the .cbt feature, deleting the .cbt dir is the best way to ensure you clean any related info.

It's some FS timing issue, we'll try to reproduce the error that you are getting, still we do not see it in our daily tasks, nor have we received feedback from other users but very seldomly. See if you are using async NFS, switch to Sync NFS and let us know if the problem is still there.

We could easily remove that error, in the end it's quite spurious, still it's letting you know something is not right, maybe it didn't get to the point where it is critical, still you should delve a bit more into it. We'll revise that part of the code and see if we can improve it somehow.

That is a direct message from the FS. Remove the content of that dir [b]/vmfs/volumes/0c6d4303-b890de35/xsibackup_1.5.1.6_olympus2/XSIBackup-DC/tmp/[/b] and try again.

Also, remove:

--block-size=1M
--compression=true

Those are values by default, your don't need them and they make the job file larger

Please post the job and the significant part of the output, including the initial part (header) which contains fundamental information on your server and remote end: (c)ESXi version, FS, paths, etc...

Hide whatever information you believe to be sensitive.