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
