Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

If you disconnect your TTY you kill the job, unless you append the [b]&[/b] character at the end of it, which will in turn disconnect the running process from the TTY.

Output is redirected to STDOUT when you run a backup manually. If you want the output to be logged, just redirect it to the [b]xsibackup.log[/b] file:

./xsibackup --backup "VMs(RUNNING)" /vmfs/volumes/datastore2/backup-local >> /scratch/XSI/XSIBackup-DC/var/log/xsibackup.log 2>&1

If you have a working job in the command line, you can easily generate the job file by just appending --save-job=NNN to the job arguments

./xsibackup --backup "VMs(RUNNING)" /vmfs/volumes/datastore2/backup-local --use-smtp=1 --mail-to=me@myserver.com --save-job=001

Once you know your backup is working fine,add it to the [b]/scratch/XSI/XSIBackup-DC/var/spool/cron/root-crontab[/b] file, like:

5    2    *    *    *   /scratch/XSI/XSIBackup-DC/etc/jobs/001 > /dev/null 2>&1

And run [b]--update-cron[/b]

./xsibackup --update-cron

To have your schedule added to the ESXi crontab at [b]/var/spool/cron/crontabs/root[/b]

In linux you have tools like [b][url=https://www.gnu.org/software/screen/]Screen[/url][/b] that allow you to reconnect to a disconnected TTY, in ESXi there's no such thing, thus you have to redirect output to a file to achieve the same result.

You may simply watch a running command running by using [b]tail -f[/b] on the [b]xsibackup.log[/b] file, like:

tail -f /scratch/XSI/XSIBackup-DC/var/log/xsibackup.log

Don't worry, just as long as you can workaround the inode overflow your old [b](c)XSITools[/b] repository will still be valid

We have commented that fact in every possible place, including the manual. In any case, even if we had not commented anything, the absence of information around some fact does not imply there is some default answer. Both programs have different names, use different command line syntax and different compression algorithms.

Old [b](c)XSITools[/b] repositories used a big block size (10-50MB). As subsequent backups were aligned with the previous ones, still some nice degree of deduplication compression was achieved. In case of [b](c)XSIBackup-DC[/b], the default block size is 1MB, thus some 150 GB of data would exceed the iNode limit in VMFS, which is around 130.000.

[b](c)VMWare[/b] does not clearly state whether [b]VMFS6[/b] allows a bigger number of iNodes. Some places it is somewhat revelaed a higher number may be present in [b]VMFS6[/b], but it's not clear.

We have indeed checked that limit and it seems to be in the order of millions, still VMFS-6 is very slow when compared to ext4 or XFS. This is not due to VMFS-6 not being good enough. It's due to the fact that it was designed to host a limited number of files: those comprising a virtual machine, and not to host millions of small files in a deduplicated repository.

That is why we recommend to use [b]ext4[/b] or [b]XFS[/b] file systems to hold [b](c)XSIBackup-DC[/b] repositories.

Compression is turned on in the [b]etc/xsibackup.conf[/b] file by default, if you want compression enabled just don't use the [b]--compression[/b] argument.

The error [b]can't open lock file[/b] is letting you know you have some permission issue on your datastore. Even if you are using the [b]root[/b] user you may have some error in your NFS [b]exports[/b] file, should the datastore be NFS.

Could also be some trivial matter like a full disk, provided that: as per your feedback, the backup run for some time and then stopped with that message that's what it looks like.

Create the jobs directory in the root folder and place your jobs there 000-999, i.e.:

/scratch/XSI/XSIBackup/jobs/001

If you run a job and it's working as you expect, i.e:

./xsibackup --backup-prog=Vmkfstools --backup-type=custom --backup-vms="VM1, VM2, VM3" --backup-point=/vmfs/volumes/backup1/my-backups

Just add [b]--save-job=NNN[/b] to the end of the command and it will be saved to [b]/scratch/XSI/XSIBackup/jobs/[/b], the jobs directory will be created should it not exist.

./xsibackup --backup-prog=Vmkfstools --backup-type=custom --backup-vms="VM1, VM2, VM3" --backup-point=/vmfs/volumes/backup1/my-backups --save-job=001

Then edit the [b]conf/root-crontab[/b] file, creating it if it doesn't exist, and place your schedules there, i.e.:

0 2 * * * /scratch/XSI/XSIBackup/jobs/001

The above to run your 001 job everyday at 2:00 in the night, then run

./xsibackup --install-cron

And then

./xsibackup --update-cron

To make your crontab permanent even after a reboot.

Once you have setup your job at [b]/scratch/XSI/XSIBackup/jobs/001[/b], some people add it directly to the [b]/var/spool/cron/crontabs/root[/b] file, which is the file holding the root cron schedules. The caveat in doing that is this file is not persistent across reboots, thus next time you reboot your ESXi server, the schedule will be lost and you will have to re-enter it.

Apart from that the [b]/scratch/XSI/XSIBackup/jobs/001[/b] file has 0600 permissions and in some ESXi versions you can't even edit it, so you have to delete it, create it again assign 0700 permissions, edit it and the change permissions back to 0600.

To avoid all that hassle, keep your cron schedules in the [b]conf/root-crontab[/b] file and run [b]./xsibackup --update-cron[/b] every time you modify it.

Undoubtedly [b](c)XSIBackup-DC[/b] will be your best option. From a conceptual point of view it is the same as [b](c)XSIBackup-Pro[/b], [b]DC[/b] is much faster though. It has been totally redesigned from scratch and reprogrammed in plain [b]C[/b] and [b]Assembler[/b]. Just try the Free version in some spare server, you won't use anything else since you do.

We are taking the time to add some more functionalities. It will be launched soon, a matter of days.

Some VM has some characters that need to be escaped, as you are passing a meta VM definition (ALL), they can't be escaped.
Check your VM names and paths and eliminate bizarre characters such as (, ), !, ', ¨, etc...
Try to limit you names to letters, numbers hyphens and underscores. You may also use spaces and some other characters, but what's the point in doing such thing?

In regards to the naming issue. You don't need to use any tool, just check the files names, the .vmdk names the .vmx file is pointing to, the displayName property in the .vmx file too and check that the .vmdk files point to the right -flat.vmdk files. If you are using snapshots you will need to tweak the .vmsd file content as well. That's all there is to it, keep control with your own eye, or you will just add another layer of uncertainties to your setup.

UPDATE:
It seems that the exit code issue is fixed in v. 1.1.0.7, just visit the change log, we'll add this fix there before we launch 1.1.0.7 in a couple of days at most:
[url=https://33hops.com/xsibackup-datacenter-change-log.html](c)XSIBackup-DC Change Log[/url]

Given the fact that you are using a cold backup, all files should be copied as they are and your VM should start the same way it was doing in its primary location. Any previous snapshot file is left as it was before the backup job, [b](c)XSIBackup[/b] will not consolidate or do anything on them.

If you want to consolidate your snapshots before the backup, just delete them.

Check the .vmx file and arrange the disk paths to point to the right snapshot in case they are wrong.

[b](c)XSIBackup-Pro[/b] offers more options in regards to backup rotation, like [b][https://33hops.com/xsibackup-help-man-page.html#deldirs]--del-dirs[/url][/b]

You have done nothing wrong. When you run

/vmfs/volumes/datastore1/xsi-dir/xsibackup --run-backup=001

The output is printed to screen, whereas when you run this

"/vmfs/volumes/datastore1/xsi-dir/xsibackup" \
--backup-point=/vmfs/volumes/Storage2TB/backup \
--backup-type=custom \
--backup-vms="Pamir_OES" \
--exec=yes >> "/vmfs/volumes/datastore1/xsi-dir/var/logs/xsibackup.log" 2>&1

The output is logged to [b]/vmfs/volumes/datastore1/xsi-dir/var/logs/xsibackup.log[/b]