Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

You haven't still provided your backup job. There's very little we can do without knowing all the details, but guessing.

You get the same simple straight message: [b]sort: out of memory[/b]
By now [b](c)XSIBackup-DC[/b] depends on [b]sort[/b], in any case you could still be running out of memory if it didn't, so:

- Increase your system's memory.
- Run the backup as a remote IP backup to the CentOS 8.0 box so that the load is shared amoung the two CPUs and memory.
- Use a bigger block size to help the problem, i.e.: 10MB block size will require ten times less memory to prune the same amount of data.
- Don't prune, rotate backups to two or more repositories.

If you cut & paste text from the manual you will most probably be suffering from character substitution. Maybe some white space character you pasted to your shell is not what you think it is. Write the argument manually.

It should be much, much faster. That slowness can only mean something is quite not working or clogged at the time to perform the backup job.

The GUI might add it where needed, it's a deprecated argument to users, but don't delete it if the GUI puts it there.

As you stated in a previous post you are Rsync'in to a Unix system, 8c)XSIBackup is not compatible with Unix as a server. That doesn't mean that you can't get it going with Unix, just that we don't support it.

Seems like you need(ed) a reinstall

[b](c)XSIBackup-DC[/b] does delete those folders after each backup or replica cycle. Please make sure that the user you use to run [b](c)XSIBackup-DC[/b] does have rights to delete them. They are typically kept at /tmp which should have open permissions for everyone

Quiescing has nothing to do with including the memory in the backup snapshot which is BTW perfectly useless. It is a kind of almost useless option, as the backup snapshot is deleted right after the backup completes loosing all the data in it, thus including the memory in the backup snapshot will only contribute to make the snapshot creation phase take much longer.

Invalid arguments are ignored.

[quote=AndersG]OK. When I do so, it does not remove the "xsibackupdiff 1" snapshot. Is that to be expected? Should I leave it there or remove all snapshots before I turn back to OneDiff after the upgrade?[/quote]

It does not remove ANY snapshot. If you have some previous "xsibackupdiff" snapshots that you don't want, remove them.

Rename the spare disk and place it in its own folder named after the VM

Don't forget to backup the whole directory, it's just some KB and you may miss some files afterwards, such as the [b]conf/smtpsrvs[/b] file or the RSA keys.

You should backup and remove your current installation of the Free version, as the default installation dir has changed from [b]/vmfs/volumes/datastore1/xsi-dir[/b] to [b]/scratch/XSI/XSIBackup-Free[/b].

[url]https://33hops.com/xsibackup-uninstall-procedure.html[/url]

Then install the Pro version using the online script.

You can then easily overwrite the [b]conf/smtpsrvs[/b] file and the [b]_rsa_[/b] key files in the root installation dir by your existing ones in the Free version installation dir. You can use your pre-existing jobs too,  you will have to edit them to reflect the new installation dir though.

Edit the first and last lines and change [b]/vmfs/volumes/datastore1/xsi-dir[/b] by [b]/scratch/XSI/XSIBackup-Free[/b] to point to the new installation dir.

Contact support if you need some especific help, nonetheless the procedure is quite straight as outlined above.