The expected behavior here doesn't really make sense. If a database was restored from a backup it won't be able to pick up replication from where it was because the changes to the remote region would have been replayed and discarded already between the backup and restore time. In fact, if the database is restored using the appliance console all the subscriptions should be dropped. This behavior was backported and released in 5.9.2.0 as a fix for https://bugzilla.redhat.com/show_bug.cgi?id=1553903 which was verified in the same version on the same day this bug was opened. I'm not sure how this can both work and not work on the same version.
If this was indeed fixed when the bug from comment 2 was released I think this can be closed as a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1540686
Hey Nick, I was unsure whether this was correct or not just because we have two backup methods currently and the restoring differs slightly, but your right it wouldn't be able to continue working after the restore. I will close this bug as a dup but perhaps there should be a docs bug opened or even a notification added after the restore that says any replication subscriptions that were in place will need to be re-deployed. *** This bug has been marked as a duplicate of bug 1540686 ***