Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Yes, there's another post open with the same problem. As it's more recent let's stick to it to follow the issue.
When a CBT sync is performed, the .vmdk file descriptors need to be updated in the .map files of the replica to reflect the new CID.
When a subsequent sync cycle is run (c)XSIBackup-DC checks that the hash of the .vmdk file descriptors is the same as those stored in the corresponding .map files. When some discrepancy is detected, the CBT scheme is reinitilized.

There are mainly two reasons that could lead to this:

1/ The remote VM was switched on without a test snapshot (--options=R) and the CID changed as per the VM activity. This is the simplest explanation and the first we think of, although at this point it seems clear that is not the case.

2/ The remote hashes of the .vmdk descriptor files failed to be updated. This is the most likely cause as of today. That's why we need the full log. If this is the cause, then there must be some special condition: it could be some bug or some faulty component of the ESXi shell (which we have found to be relatively frequent). Having the exact ESXi version and the rest of details present in the log is fundamental to delve into the issue.

Thank you for your feedback, we can see that there are other old dogs around this forum ;-)
We made the amendments which will be visible when the CDN cache is refreshed.

Given that Mr. Miyagui is a Japanese name, I believe there isn't any right spelling for it, as it's just a phonetic interpretation of the original name.

I'd swear Mr. Miyagui said that in Karate Kid. Nonetheless that's an archetypal character: the wise old master, I bet Yoda said something similar sometime.

Sure, you have some examples in the manual page:
[url]https://33hops.com/xsibackup-dc-full-manual-home.html#over-ip[/url]

They are just kept there to know about the history of events. They are useless from a recovery point of view.
You can manually remove them, should you ever use the replica in production.

That depends on what (c)ESXi version you are using. From (c)ESXi 7.0 all files in a virtual machine are read blocked, even when the VM is running on top of a snapshot, thus keeping preexisting snapshots is not possible. This is by design and a decission taken at (c)VMWare.

Thank you for your feedback.
As Carl Gustav Jung would say: you made the unconscious conscious and a whole new world opened up in front of you.

This is so weird. There's clearly something altering the .vmdk file descriptor CID or unique identifiers that allow (c)XSIBackup to know whether the disks have changed since last synchronization. Why don't you just use a totally different volume just to make sure that you don't have some other software interfeering in your replicas?.

It is the mail-from address that is required to contain an @ sign. The username field is much more permissive, it requires 1 to 70 chars of any kind.
There is indeed an error in the REGEXP pattern which is that the hyphen or dash character needs to be at the end (or at the beginning) of the character class to be interpreted literally. We have fixed that and will be published as 1.5.0.7. We have also extended the port to allow using up to 5 digits, in case somebody wants to use some non-standard port.

We checked your server with grep regexp, which is very similar to the one we used, and it passed the test.

echo "1;smtp.domain.ca:587;backup-logs@domain.ca;1234567;abcdef123456789;none;TLS;0" | grep -E "^([0-9]{1,3});([0-9a-zA-Z._-]
{1,70}):[0-9]{2,5};([0-9a-zA-Z._-]{1,70}@.*{1,70});.{1,70};.{4,70};[a-zA-Z]{3,4};[a-zA-Z]{3,4};[0-5]{1}$"

This validation had to be added, as well as some others to prevent spurious characters in the smtpsrvs.conf file breaking execution and causing segfaults.

(*) Please note that the hyphen issue is resolved in the pattern we used. This could break behavior of the REGEXP test. Please try with 1.5.0.7 available since 2021-06-06. In fact, if you move the hyphen from the last position to the previous one in the two character classes where it is used, this very same server line will not pass the REGEXP check, thus, that is proof that the hyphen misplacement is the source of your issue too.

Well, you already have all that you need to easily arrange something like that. Let us know what your exact goal is and we can prepare some post on the subject which will for sure be interesting to other people.

You can exchange keys with any kind of server and log that info to a Mysql server, to some Syslog server, with which we already offer comatibility, etc...

There must be some text inconsistency, we'll check that, there's only one version of the tool. You can download from here:
[url=https://33hops.com/xsidirector-esxi-management-deployment.html]XSIDirector Home Page[/url]

We aren't getting you. We asume that you are indeed running (c)vSphere (c)ESXi in your host. What would be the reason to post here if you weren't running this system?

On addition to that. Please take the time to learn what an independent disk is and how it differentiates from other types of storage in (c)ESXi: [url=https://cormachogan.com/2013/04/16/what-are-dependent-independent-disks-persistent-and-non-persisent-modes/]post on (c)ESXi disk modes[/url]

Please be aware that independent disks cannot be hot backed up, use --backup-how=cold instead.

The message is already stating that point, thus: we don't understand where your doubt exactly is or what do your expect from us.

Your asumptions are mainly correct. The --replica=cbt process generates a replica, which is an exact copy of the replicated VM. The test snapshot is spurious and its only aim is to serve as a sandbox to check the VMs, it's always discarded on the subsequent --replica=cbt cycle and if you happen to manually mix the spurious data (the one generated during a punctual VM test) by deleting the test snapshot through the GUI, you will break the replica process. This will in fact be detected on the following CBT cycle and the --replica will be resync'ed

Now on the empirical side of your tests:

The .locked file is automatically deleted at the end of any replica cycle, thus, if it is still there at the end, then something is not working as expected.

You can replicate data anywhere: a Linux compatible server or another (c)ESXi host. When you replicate to another (c)ESXi host, you happen to be doing it to some system that allows you to perform this kind of "sandbox" testing via a snapshot. Still, you will need to pay attention to some basic principles, like the ESXi hosts being coherent in terms of HW and VMFS version.

If you mix VMFS or HW versions, you will experience the same effects as if you would the same any other way, in the end (c)XSIBackup is just a tool. You take the decissions on what to do with it.

In any case we have just started an especulative thread. If you need concrete answers on concrete matters, please post the job and the output of the job. There are two definitive issues around your description:

1/ .locked file not deleted.
2/ No snapshot, even though you have requested it to be taken as per the --options=R argument.