The point is that the subscriptions are created and started from the original database (as usual), so log offsets are fine. And when extracting several remotes, it's the multiple REMOTE RESET with one final COMMIT that takes care that offsets can be set in one single transaction (REMOTE RESET itself does no AUTO COMMIT in contrast to START SUBSCRIPTION).

The "make a backup immediately after starting the subscriptions" rule makes sure that the extracted data itself fits to the state of the data as to the according log offsets. - So you're somewhat saying "My extract does guarantee that the data fits the log offsets...".

FWIW, we have used this technique for several years - until we switched to a custom extraction process which was wayyyy faster than DBXTRACT and allowed us to extract from the production database directly.

"Handle with care" and "Test very thoroughly" - as usual with SQL Remote setups:)

The newly extracted remote db will contain the changed/added record whereas the production db will not. So data will be inconsistent between the consolidated and the remote.

In contrast, adding data on the consolidated while the extract is being made from the copy will generate according SQL Remote messages for the "remote under construction". Once the remote is created and starts replicating, it will apply the already existing messages and will add the changes from the consolidated.

To make it short: The copy should only be used to extract data, not to change it in any way. After extraction is done, it should be erased.