We use CouchDB and PouchDB to have in browser replications of a remote database. We create backups of the CouchDB in case something ever goes wrong.
Introducing a backup when data is lost is no problem, but resetting the system to a older state which should also affect all synchronized PouchDB seems to be very difficult to achieve.
As an example: User1 and User2 synchronize a local PouchDB with a remote CouchDB. User1 creates a new document D1 which is also synced to the remote database and to User2. Now User1 wants to reset the database to the state before D1 was created. To achieve this, the user deletes the own local database and resets the remote CouchDB to the previous state. When User1 synchronizes with the remote CouchDB, the D1 wont be there. But User2 still has D1 in his local database and once this is synced with the remote database, D1 will also be back on the CouchDB and synced to User1's local database. Eventually the system is in the same state as before it has been reset.
For our project it is impractical to ask every user to delete the local databases before the system can be backed up.
How could a procedure looks like that would reset such a distributed system into a older state.
Some additional challenges:
- The example is rather simple and should just give a general idea what is happening. In the end there might have been a big number of create, edit and delete operations that have to be undone with the backup.
- Some of the clients might be offline when the system reset happens