I want to say thank you Bob for starting this conversation. IIUC, if tabs are the only problem we need to think of, this is a good place to be in! Impact seems pretty minimal if you can run updates and restart a server rather than do a full node migration.
As per > Is this true of other collections in general? In particular, I'm > wondering about the possibilities of recovering the user's data atop a > point-in-time backup using this method, along the following lines: > Very happy we're talking about options around restoring data. Questions: - Would resolving this issue with the current server benefit the sync.next server that syncs with Mentat? (given that we "might" fork the existing server to create the new one.. or so I've heard) - Also, would it help reduce risk in any way to be able to recover from a point-in-time when we start to migrate users to sync.next? -- Alex Davis // Vancouver Product Manager // Application Services (514) 582-2539 IRC & Slack: adavis On Sun, May 27, 2018 at 9:06 PM, Mark Hammond <[email protected]> wrote: > On 28/05/2018 1:05 pm, Ryan Kelly wrote: > >> Is this true of other collections in general? In particular, I'm >> wondering about the possibilities of recovering the user's data atop a >> point-in-time backup using this method, along the following lines: >> >> * We take regular backup snapshots of the user's data on the server >> * Something bad happens to a storage node, and we want to restore the >> user's data from a backup, so we: >> * Down the node, having it return 503s with backoff >> * Restore the db from backup >> * Futz with their meta/global to remove the syncIDs while leaving >> other data intact >> * Restore the node to service >> * On its next sync, the client detects that the syncIDs have changed and >> does a full re-sync >> > > In general, this should cause clients to act as though they were just > connected to Sync - they'll do a full reconcile etc. Or more accurately, it > will probably behave as though the client was disconnected on the date of > the backup and reconnected today. > > While I can see this approach being useful for users who are treating sync > as a backup (ie, where they've lost the only syncing device, so any data is > better than no data), there's a risk for accounts where active clients > exist, particularly around the resurrection of deleted items, but also for > reconciliation in general (where Sync may end up deciding the server data > should be taken over the remote data) > > I guess we could decide the damage is likely to be minimal if the backup > was recent enough, but the outcome will almost certainly never be > deterministic as it is likely to depend on exactly how recent the backup > is, what device ends up doing a first sync and when it previously synced. > > This is much easier to rationalize about for tabs because each tab record > is written to by exactly 1 device - there's no opportunity for a stale > client to screw up the record for a different device. > > (That said though, there might be scope to change client's behaviour - if > each client knew that it was dealing with restored data it might be able to > make better decisions, but that might end up being a very large change - > eg, it might require all clients to move to tombstones and always persist > those tombstones locally, some way to avoid "old" clients doing the first > "recovery sync", etc) > > > Mark > _______________________________________________ > Sync-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/sync-dev >
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
