On Mon, May 28, 2018 at 12:06 AM, Mark Hammond wrote: 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.
We could potentially count the clients records and only restore users with a single client. On Mon, May 28, 2018 at 12:06 AM, 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
