Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

XSITools stores files in repositories, as you can see a repository is compounded of a data folder, an .xsitools descriptor file and some timestamped folders which have nothing to do with regular backup folders, they just store the hash maps and auxiliary VM files of every backup operation, but do not contain data, they are not backup folders, they are the intermediate differential data description.

The backup folder is the repository itself, but as you have stored the XSITools repository to the root of the datastore. The backup folder is the datastore, not the [b](c)XSITools[/b] repository and has no name, but the upper level, which is the datastore and cannot be removed.

To have your XSITools repository considered for deletion, place it inside a folder in the root of the datastore, not in the root itself. You must make sure that the folder name follows the [b]datedirmask[/b] convention. You can easily achieve that by using dynamic folders like:

To create a monthly XSITools repository that will be deleted when the disk is full.

--backup-point="/vmfs/volumes/backup/$(date +%Y%m'00000000')"

If you want to store quaterly.

--backup-point="/vmfs/volumes/backup3/$( date +"%Y %m" | awk '{Q=int($2/4)+1; printf("%sQ%s\n", $1, Q);}' )"

You have a more thorough explanation along with examples here:

[url]https://33hops.com/xsibackup-pro-dynamically-naming.html[/url]

You have some previous errors:

sh: rsync: unknown operand

Error: skipping, not able to retrieve VM information

The [b]arithmetic syntax error[/b] is just a consequence of not having been able to retreive some fundamental information previously.

XSIBackup is not that picky as some people want to believe. Just as long as you have clean paths with no especial characters, just letters, numbers and spaces, except in the datastores names and you have a properly configured host, it will work.

1/ Already answered in [b][https://33hops.com/viewtopic.php?id=337]this previous post[/url][/b]
10/ XSIBackup does not allow especial characters in VM names nor paths, remove the parenthesis.
13/ Same problem as number 1
14/ Same problem as number 1
15/ You seem to have some permission issue in your target datastore.
6 & 7/ comparison of backed up disks failed, the reason for this could vary, but there should be some previous error.

Please, contact support with all the details: full backup job and full output corresponding to the issue, one issue at a time. Some of your problems are related to naming conventions or permission configuration. Our support department will help you with identifying the source of your problem, namely, we will point the possible issue, nevertheless you are responsible for configuring your system.

That depends on how you have configured your ESXi clock.

Have you renamed the license files to [b]license.key[/b] and placed them in the installation root dir (xsi-dir)?
In regards to the second issue, the size mistmatch. Are your two servers coherent in terms of VMFS version?
You are getting this message:

2018-11-03T08:06:03|  [v02] error DIFQMSH3: data size mistmatch: 56984 NE 56156... 

Which means that [b][url=https://linuxcommand.org/lc3_man_pages/du1.html]du -m[/url][/b] is reporting a different number of used blocks.
Resolve issues in order: first make sure your license.key file is correctly installed, once you have fixed that issue, if the size mistmatch problem persists, contact support to diagnose the exact cause.

Most probably some space in your paths. XSIBackup does not support spaces in datastore routes.

Is server [b]10.240.100.45[/b] reachable at port 22?
Have you exchanged the RSA key via the [b]--link-srv[/b] argument with [b]10.240.100.45[/b]?
Is XSIBackup really installed to the folder: [b]/vmfs/volumes/esx-data-store[/b] on the remote server?
What do you mean by "no log events"?, are you aware of the fact that the log file will be

xsi-dir/var/logs/xsibackup-10.240.100.45.log

Yes, you are absolutely right, this is a bug, we'll fix it today.

Nevertheless, we must insist in taking the chance and try to convince you to move your VMs to an VMFS volume for the reasons exposed above.

VMFS has been designed to store VMs, whereas ZFS is a general purpose FS. VMFS keeps track of every extent of data stored in your .vmdk files, this allows to jump over zeroed zones, replicate data and run quick algorithms to check data integrity. You loose all that features by using an NFS volume to run your VMs, on top of that, as estated in the previous post you limit bandwith and increase latencies in disk I/O operations.

Just to pose a real life example: backing up a Linux VM in a single .vmdk disk which is 20 gb in size and contains 2.7 gb of data will take (in one of our test servers, which is an i3 with 16 gb. memory and regular HD with a small SSD acting as a host cache disk) 9 minutes if hosted on an NFS share against 1.5 minutes when hosted in an VMFS5 volume, when using [b]XSITools:z[/b] to backup over IP to a Linux server.

Please, let us know what your ESXi version and build are and whether you are using [b][https://33hops.com/xsitools-vmfs-deduplication.html]XSITools[/url][/b] as the backup program or not, we have had to guess so far.

Schedule it in the cron and inspect the log afterwards. If you want to see the output in real time while it is taking place, just use tail -f

tail -f /vmfs/volumes/datastore1/xsi-dir/var/logs/xsibackup.log

The VMs are copied, including their disks, where you point the --backup-point argument to, i.e.: /vmfs/volumes/backup

That product seems to be designed to be used from within S3 environment.
As stated: NFS is not an easy protocol to be used over a WAN. If you are not a computer expert, then you probably have chosen a very picky subject to deal with.

Are you seeing the right figures when issuing df -h from the command line?
XSIBackup just picks the information from the shell.