Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Backups made to local storage are always much slower than over IP backups. Reading, hashing and compression must be done with a single core as the (c)ESXi shell is limited that way. By using an IP backup host you allow the load to be distributed among the two ends.

If you need more speed than with (c)XSIBackup Classic, use new [b][url=https://33hops.com/xsibackup-vmware-esxi-backup.html](c)XSIBackup-DC[/url][/b]. It is a C monolithic binary and it offers native support for [b][url=https://kb.vmware.com/s/article/1020128]CBT[/url][/b] (Changed Block Tracking) technology.

Still, even by using our latest edition, backups made over IP will be much faster than local backups.

It is not a bug. Note that you are trying to convert the root of a volume into an (c)XSIBackup repository. Please, just add some folder below the data store, something like: /vmfs/volumes/datastore1/my-repo

We will still revise this behaviour in the GUI before our next release.

Yes, we have indeed changed the command line arguments. We redesigned the concept from scratch, thus we took the chance to improve the arguments' syntax. Still the concept is the same.

Just take a look at the new [b][url=https://33hops.com/xsibackup-dc-full-manual-home.html]XSIBackup Man Page[/url][/b]. The main thing to take on account is that the three first arguments have a fixed order: action, source & target.

We are lacking important information at the header of the job: (c)XSIBackup version, (c)ESXi version, remote OS, free space, etc...

All we know is that your TTY freezes at different points in time: 85%, 93%.... We don't think using VMs(ALL) or a custom selection has anything to do as the SSH tunnel is created in exactly the same way with the very same parameters, there is no difference at all.

The fact that no error is printed out makes this even spookier. Please revise free space in your local volumes.

df -h
vdf -h

And the load on your systems, both ESXi and remote

esxtop # ESXi box
top # Linux backend

Plus any errors in your remote backup server a.b.c.d

tail -n30 /var/log/xsi/error.log
tail -n30 /home/remoteuser/.xsi/var/log/error.log

(*) Depending on the (c)XSIBackup version your error.log file will be at different locations.

You may need to revise the remote OpenSSH log for some more clues, should the problem not be related to some more obvious matter.

Also check that you didn't run out of memory, although this could only happen in some versions of (c)ESXi with huge VMs.
Read this post on the subject and run the command to check your memory load.

[url]https://33hops.com/vmware-esxi-memory-constrains-and-workarounds.html[/url]

If you are using the Free version, make sure you aren't trying to backup something which exceeds its limits, Although in that case you should simply receive a message.

Please, note that current (c)XSIBackup edition is new software and although it resembles the Classic version and follows the same working principles, it is indeed new software with different arguments and syntax. Nonetheless, if you are used to (c)XSIBackup-Classic, getting adapted to new (c)XSIBackup will be fairly simple.

[url=/xsibackup-dc-full-manual-home.html](c)XSIBackup Manual[/url]

You should remove any older version of our software and any previously configured cron entries to avoid conflicts, i.e. running multiple jobs at the same time.

You are receiving that message because you are trying to set some target outside /vmfs/volumes/ which is the root all local datastores should stem from. Select a dir by using the space bar and list contents inside of it by appending a slash "/"

[url]https://33hops.com/xsibackup-datacenter-change-log.html[/url]

(c)XSIBackup is designed to work on a Linux/(c)ESXi backend. We can't support exotic combinations. FreeBSD is not Linux.
If we allowed your choice, why not Windows WLS?, or Android or MAC.

[quote=mikeg]I also just discovered that the backup jobs to the nfs share are not storing the host config to the cfgbak folder even though that option has been added. The same job configuration to a local vmfs6 datastore does write the host config to that folder. Any ideas on that?[/quote]

The --config-backup argument just copies the (c)ESXi configuration to the remote end, it makes no difference between a VMFS and an NFS datastore.

[quote=mikeg]Thanks. I was learning them both and agree. All seems to be working well now and I am looking at some of the other commands/options available. What is the best way to only keep a certain number of the last available backups automatically?

Also I just discovered the ESXi NFS datastore share is lost after rebooting Rocky Linux. Trying to figure out why. It becomes accessible again if I simply duplicate these steps in terminal:

nano /etc/exports
CTRL-O
CTRL-X
exportfs -arv[/quote]

Well, those are general Linux administration issues, just make sure that you have enabled the NFS service to start at boot time.

Congratulations, yours is the biggest homelab server that we ever came to know:
20 CPUs x Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz , 320 GB RAM

Yes, it's perfectly fine to use some VM as the target of your backups, in fact using a VM has some big advantages when compared to using a disk or a physical server.

We can't asess your setup based on words such as "slow" or "fast". You don't even provide some relative comparison that we can base our assesment on.

There are some obvious facts, such as setting your backup VM in a separate datastore, but we guess you already thought of that.

Do use Rocky Linux 8 as your NAS OS?. (c)XSIBackup-NAS is an apliance to help quickly deploy NFS and iSCSI shares for (c)ESXi. You can run XSIGR from (c)XSIBackup-NAS, you may need to install some components manually though.

To have a more straight granular restore backup server just use a minimal install of Rocky Linux 8, then run [b]./bin/XSIGR/install[/b] from the (c)XSIBackup installation dir in the (c)ESXi host.