I have an existing license and am happy with the performance... will XSIBackup Pro continue to work with ESXI version 7?
I'm afraid it won't. It's not something we decided, but VMWare. ESXi 7 blocks all files for reading, thus we needed to develop an alternative solution that reads data from the SCSI disk.
If you read the above post, please just pay attention to continuum, the other specialist didn't grasp what we were talking about.
All editions will be ported to use DC technology soon.
I have a few dev boxes running ESXI 7 not running backups now... my production is running vSphere 7 (but ESXI boxes are 6.5 because upgrading will break the backup process). Is there an ETA on functional Pro release or an upgrade path from PRO to DC?
Yes, contact us on support to offer you an upgrade path.
What does it mean to read data from the SCSI disks? Is it slower than read data from the files on earlier version of ESXi?
It means that as files are no longer available to be read, the data has to be read from the block device. It's actually a bit faster than reading the files. (c)XSIBackup-DC is considerably faster than Pro Classic in almost any situation.
(c)XSIBackup-DC is considerably faster than Pro Classic in almost any situation.
In our case, it was the opposite, (c)XSIBackup-DC was considerably slower.
It was one of the reasons that made us want to stick to the classic version, though deprecated, as we were still able to run it on ESXi 7 using vmkfstools as backup program (with the free version, the pro version is set up not to allow users to run it on ESXi 7).
That was until we came across this crucial piece of information from last year:
©XSIBackup-DC has two major working modes for backups and replicas: local and remote, that is: passing a local path as the third argument or passing a remote path email@example.com:22:/some/remote/path
When you use the first mode (local), the software assumes your remote site is reachable within a reasonable local latency lapse, thus it queries each individual block before actually copying it or just adding its hash in case it already exists.
When you use the remote path syntax, it changes to a different algorithm by means of which the block maps are exchanged at the beginning of the process, then it starts traversing the disks in block size chunks to check individual hash and check whether it has to be sent or not.
If you mount some remote NFS server and the latency is high (non local), then you should not be using the local mode, but the remote, so that you get the block manifest on advance and perform all checksum comparison operation locally.
When you perform a local backup to a, let's say 50 ms latency remote host, you are adding 50ms to each individual block operation. Every mode has its reason of being, you just have to choose the most suitable one in each situation.
So we unmounted our NFS and gave a remote path to our replicas. And it did allow (c)XSIBackup-DC to achieve higher speed than the classic version.