A question about Deletion Stubs, but not the normal one (I’m up to speed with how documents re-appear from Local Replicas that haven’t replicated for a long time and stubs have been purged) . . .
I just had to recover some documents in a .NSF that were deleted: The application stores documentation and uses doc-links to other documents within itself, so I wanted to restore the deleted documents with the same UNID (so doc-links from other documents still work).
I restored the .NSF from a backup a month ago (before the document deletion) and deleted the Deletion Stubs from the restored (local) instance A and the server instance B. I then replicated A with B and the deleted documents are back, with the correct UNIDs. Life is good.
QUESTION: Some staff have Local Replicas of this .NSF and they will contain the deletion stubs for the restored documents . . . when they replicate with the server, will the deleted Deletion Stubs be put back into the server instance (B) of the .NSF and result in the recovered documents being deleted again?
To ask it another way: Does the deletion of Deletion Stubs replicate to other instances of an .NSF? If so, are there Deletion Stubs of Deletion Stubs?!?</An aside>
Subject: logically thinking …
I’m not 100% sure if the deletion stubs would replicate back or not but as long as the users of the local replicas do not clear replication history I would not think the old stubs would replicate back to the server anyway because their replication date would fall past the last replication date in the replication history.
I’ve been asking for a database option to prevent local replicas from pushing old deleted docs back to the server. This could easily be done using the same algorithm used for the deletion stub purge interval. So if the purge interval is set to 30 (or 1/3 of the replication setting “remove documents not modified in x days”) the server would return an error on the replicator tab stating that the local replica is past the cutoff date, or something like that.
We have a major application where we used to have this issue all the time. I created a routine to get the replication history of the local replicas and save that info in a document. Then an agent runs on the server to check this info and if the user has not replicated in 28 days it sends them an e-mail and locks them out of the database. Works great but it was a pain to get all of the logic working correctly. Requires some API calls and such.
Subject: After a few weeks . . .
FYI: After a few weeks of running with the restored documents in the database, all Deletion Stubs removed (manually) and with replication of Deletion Stubs disabled (Advanced Replication Options), I took the plunge and re-enabled replication of deletions and . . .
. . . touch-wood, the restored documents are still there 
I’m assuming that the deletion of the Deletion Stubs has replicated to all Local Replicas etc. and that’ll be the end of the story. Fingers crossed!