I was working with the trial version 126.96.36.199 testing out replicas, as that's how I intend to do my backups. I made replicas to a local datastore and then to a NFS share, verified that it indeed kept thin vmdk files thin, and I did sha1sums on all the files and compared both to ensure the copy was valid. All was good. I then tar compressed the VMs, gzipped it, and then ran the process in reverse to restore the files, first to a NFS share from a Linux VM (ESXi's version of tar doesn't handle sparse files) and then used xsi (running on ESXi directly) to replica back from the NFS share to a local datastore. Here is where I ran into an issue. The VM I originally used for the test was down when I made the replica, but when I went to copy a replica of the VM from the NFS back to the local datastore, but to a different directory, because the VM was up xsi skipped one of the snapshot disks indicating that it was "excluded". At first I couldn't figure out what was going on, but then when I shut down the original VM again and ran the replication back to the local datastore, it worked.
Apparently xsi is looking in the .vmk file to identify the VM involved and thinks that because the VM is running it can't fully replicate. However, it doesn't realize that the replica is being put in a different directory than the running VM is in, and therefore it shouldn't be paying any attention as to whether the VM is running or not. I'd suggest either making it smarter and able to know if the directory that the VM is going to is really the one that a running copy of the VM is using, or adding an option to the --backup-how option or perhaps creating a --restore-how option to tell it to just replicate without checking to see if a VM of the same name is running.
Also it would be good to have a way to tell xsi not to create the .map directory, as if one is simply doing a point in time stand alone backup via replica, which is how I intend to use it, it's unneeded as far as I can tell and just wastes space.
Last edited by srwsol (2019-11-03 02:46:29)
If you duplicate VM names XSIBackup-DC will pick the first it finds in the duplicate set.
Don't duplicate VM names.
We could pick VMs by Id, that would solve the issue of having duplicate VM names, but it wouldn't be as convenient on the user side as managing them by name. The only requisite is no to duplicate names and knowing that if you do you may get some unexpected results, like the ones you describe.