Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

You have the --on-sucess and --on-error event handlers that will allow to add that info to a text file very easily. Please read the man page.

Of course, just make sure that the user you employ has permissions to read data and create/ delete snapshots on the VMs being backed up, as well as full write permissions on the directories where you are writing to

Some people tend to think setting permissions up for this kind of taks is somewhat trivial, when it's not. (c)XSIBackup interacts with vim-cmd as well as other ESXi binaries and utilities that will require different permissions. If this is mandatory for you, instead of using root, it's the perfect excuse to delve into ESXi users and groups and how permissions interact with the system.

The message is clear, you ran out of memory

This will only work with --backup-prog=Vmkfstools

You are just commenting your issue without providing any detail on it.
Please paste the job and output any time you request support.

Please, contact support on your issue.
If you want a straight way to perform your backups, stick to recommended procedures. If you use your own Linux distros as the backup servers other than: RHEL, CentOS, Fedora, you will need to comprehend the different pieces implied to getting it to work, namely: ciphers on each side, permissions, etc...

Then you are not backing up where you believe to be doing it, as that error can only be raised when some previous backup exists in place.

We have discovered a bug that affects backups with a block size bigger than default (10M, 20M, 50M). Please switch to using 1MB blocks (default) and wait until we release a fix in v. 1.4.0.0 before using bigger block sizes

[url=https://33hops.com/forum/viewtopic.php?id=783]Non default --block-size bug[/url]

You are mixing things that sound similar but are not the same:

[b]--update-cron[/b] copies the contents of your local crontab at [b]<installation-dir>/var/spool/cron/root-crontab[/b] to the ESXi crontab at [b]/var/spool/cron/crontabs/root[/b]

[b]--uninstall-cron[/b] removes the entry in [b]/etc/rc.local.d/local.sh[/b] that allows to repopulate the ESXi crontab when you reboot the host. Your output is just letting you know that there isn't any entry installed for user root. For --uninstall-cron to work, you have to previously run --install-cron

Both commands contain the string cron, but are not related. Your output is perfectly right.

That speed that you see there is an average, it includes the time it takes to do some basic checks and to take and delete snapshots. It's true that it's not spectacular to put it that way. You should take on account when and how you performed the speed tests previous to the backup: was the server iddle? are there some VM running now that you are performing backups?

Your disks seem to be thick, this may add some extra time. You don't say what backup program/method you are using, this can also affect the effective speed.

When it comes to backup disks between local storage, the fact that will affect the most is how fragmented the disks are, both from a guest perspective and from the VMFS point of view. It's not the same to have a few extents of data in a virtual disk than thousands of them. That is: it's not the same jumping over a 1GB zeroed zone than having to detect one thousand 1MB zeroed extents.

Run this command:

vmkfstools -t0 /path/to/your/disk.vmdk

And check what is the number of reported extents. It should not exceed a few hundred in case of your smaller VM or a few thousand in case of the bigger one.

In case you observe a lot of small chunks of data scattered across the virtual disk, do the fllowing:

- Make sure that the guest OS is defragmented. You don't generally have to worry about that on Linux journaled systems, but you may have to program some defragmentation schedule on Windows systems, especially if they are fragmented above 5%

- Clone the virtual disks to thin format, unless you have some very good reason to keep them thick and you know exactly why they should remain thick. This will compact extents to a lower number and make data be stored in bigger extents.

On top of the above. The way the physical layer is aligned to the logical storage layers can affect performance A LOT.
Run this command:

esxcli storage core device partition list

Check where do your storage partitions start in each disk. They should start at 2048 if the disks have been partitioned with a relatively new ESXi system. If they are not aligned to this sector number, then the hardware storage may be misaligned and this may cause an extra load on the hardware that is by no means negligible.

This post explains the issue in a very graphical and visually explicit way.
[url=https://neokobo.blogspot.com/2015/06/virtual-disk-alignment.html]Virtual disk alignment[/url]

We can't debug your setup for you.
There isn't much we can say by taking a look at your job

[b](c)XSIBackup-DC[/b] already includes a [b]--prune[/b] feature. Anybody using this or any other shared code snippet does it at his own risk.