Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

We'll revise that behaviour in next release, thank you for pointing out.

No, that can't be the reason. The most likely reason is that the VM's name is not the one you believe it is.

Please, avoid such naming.

We have taken the time to make ©XSIBackup-DC work with spaces, dashes, hyphens, underscores, at signs, etc.., still we have detected a number of shell component bugs in the past related to space handling.

On top of that there exist a number of different characters that will produce an invisible space. Same applies to hyphens, dashes, etc...

Make your life easier and renounce to using fancy characters in production environments, you will for sure save yourself time and money enough for some days of vacation in the Caribbean after a decade.

(c)XSIBackup Classic is based in scripts, use at your will.

./xsibackup ... && do something || whatever

Well, that's it.

Of course special characters matter. ©XSIBackup-DC has some more strict requirements than ©ESXi in regards to file naming conventions, still they are quite permissive in regards to spaces, hyphens, etc..., special characters like accented ones are not compatible though, at least in case of CBT.

Please, rename your files and/ or VM names and try again.

In general, please do pledge to using ASCII character sets to name your files in (c)ESXi and by extension any Linux FS. You can look at it from a 'reductio ad absurdum' point of view: what's the point in using special characters in virtual disk file names?.

We are obviously more general public oriented and open to all kind of situations, as we now distribute freemium software to people in five continents, using different character sets, keyboards, etc... Nonetheless we have known consultants that would plainly refuse to offer any kind of service to a client with such kind of naming scheme. You are probably thinking that's too radical from part of that person, still we can understand it, as it denotes not having much control on what's going on.

Well, thank you for the precise feedback, some users tend to ommit important information or to exaggerate It in the hope, we guess, that they will receive some extra attention. This only makes things worse and support a matter of guessing.

Knowing that this is a VM specific issue is extremely important to narrow the problem down.

Is there something in the VM disk files (special characters, spaces) that makes it different from the other VMs?

By now you can only select groups of VMs by using the keywords RUNNING or ALL.
REGEXP support for selection of VMs will be added in short, you can nonetheless easily implement this in the very DC job by using this code snippet.
The grep expresssion contains the regular expression that you use to filter the VMs, in this example it is [b]^W.*0[/b]

vim-cmd vmsvc/getallvms | tail -n+2 | awk -F '[' '{print $1}' | awk '{print $2}' | grep -E "^W.*0" | sed ':a;N;$!ba;s/\n/,/g'

This code snippet integrated in a job would look something like this:

/vmfs/volumes/6071af03-9b59286b-5ed6-001517c3fbf5/XSI/XSIBackup-DC/xsibackup \
--backup \
"VMs($(vim-cmd vmsvc/getallvms | tail -n+2 | awk -F '[' '{print $1}' | awk '{print $2}' | grep -E "^W.*0" | sed ':a;N;$!ba;s/\n/,/g'))" \
/xsibackups/xsibackup_default_repository \
--mail-to=mail-from \
>> /vmfs/volumes/6071af03-9b59286b-5ed6-001517c3fbf5/XSI/XSIBackup-DC/var/log/xsibackup.log 2>&1

The code snippet takes  all the VMs in the host, then it filters them by using the regular expression in the grep command to finally remove the new line characters and substitute them by a comma, which is the VM separator in a VM list.

You can test the code in the command line prior to using it in a job.

What you say does make sense. You can actually add the information generated during a backup cycle to let's say some MySQL DB easily, you just have to exchange key with the DB server and run a postbackup script to add this info to the database.

We will dedicate some time to writing some posts and offer some examples that can be reused by (c)XSIBackup users and also some DB triggers to generate alerts on the situation that you describe.

We are actually finishing to test some new features around --rotate to allow setting virtual user space limits and improving the rotation features.

Do not even try to store a deduplicated backup on VMFS-5, we won't comment any further around this issue, we already explained on that.

You are running --info on a datastore, why?. It is meant to be run on a backup repository.
Please read the manual and examples before using the software.
[url=https://33hops.com/xsibackup-dc-full-manual-home.html](c)XSIBackup-DC[/url]

We will modify the info.c module so that it terminates with a clear message when no .blocklog file is detected. Nonetheless we can't detect every possible wrong way that users will be trying to use the software to print a message stating why it shouldn't be used that way.

The job below is conceptually wrong:

./xsibackup --backup "VMs(Black)" "/vmfs/volumes/nas 1 john"

You should not backup to a repository in the root of a datastore.
You should instead run:

./xsibackup --backup "VMs(Black)" "/vmfs/volumes/nas 1 john/some_repository"

And then get information on that repository running

./xsibackup --info "/vmfs/volumes/nas 1 john/some_repository"

We specifically block attempts to backup to the root of a datastore. Maybe the fact that you used some datastore containing spaces managed to work those checks around, we'll check that point.

Needless to say you should avoid spaces in paths as well as special characters or accented ones.

This is due to a limitation in regards to NFS based disks, already fixed in 1.5.0.9

It's currently 100GB

Yes, that could be indeed an issue, as every .vmdk descriptor file will be matched with its hash. Should there not be a hash for some file, the CBT cycle will be reinitialized.

Clean it up whenever you have the chance, leave: active .vmdk and -flat.vmdk files along with the .vmx file. Everything else can be deleted. Make a copy of the VM dir just in case though.

We will reproduce your environment as closely as possible and check the logic.

Use this script to kill any ghost processes. The below script will look for any process containing the string "xsi" and kill it.

P="$( ps -c | grep xsi | awk '{print $1}' )";for p in $P;do kill -9 $p;done

Just discard any backup that you can't trust. If it's a replica delete it or rename the folder.
If it's a backup to a deduplicated repository, you may just delete the backup folder, this will maybe keep some useless blocks (some MB), that's the only side effect.
You may very well just keep it there, the reason for removing the backup folder is to avoid believing it's OK in the future, you may also rename the folder to YYYMMDDhhmmss.bad to mark it as a bad backup.