Recovery methodsTechnical

Cloud Change History and Sync-State Reconstruction

Cloud change APIs describe how the synchronized namespace evolved over time. Revision APIs describe the historical content of one specific object. Reconstructing what actually happened in an incident usually needs both, and they aren't substitutes for each other.

Two different questions, not one

"What changed in this account/folder over time?" and "what did this specific file used to say?" are genuinely different questions, and cloud providers generally answer them with two different API families — a change feed for the first, and a revisions endpoint for the second. Conflating them leads to tooling that can tell you something changed without being able to say what it changed from.

Dropbox: cursors, list_folder and DeletedMetadata

Dropbox's list_folder and its continuation calls, driven by a cursor, let an application ask what changed since the last time it checked, including entries typed as DeletedMetadata for items known to have been removed. That's a real technical distinction from an item simply being absent from a current folder listing — and it matters because a cursor only tells you what changed, not what the file used to contain; content history is a separate revisions lookup.

Google Drive: changes, page tokens and the trashed query

Google Drive's changes API, driven by a start page token, lets an application maintain a model of additions, modifications and removals across an account or shared drive. It's a genuinely different tool from the revisions resource that returns a given file's historical versions — and Drive's search can separately query for trashed = true, which is why the first move when a file goes missing should be checking whether it's actually sitting in trash rather than uploading a replacement.

Microsoft Graph: delta and the deleted facet

Microsoft Graph's driveItem delta endpoint returns incremental changes since a prior state, including a deleted facet for removed items, with nextLink/deltaLink values to continue paging or resume later. "Deleted" in a delta stream means removed from the current synchronized state — it doesn't by itself prove that every recoverable historical copy is gone; that's a separate question for version history or retention.

Push notifications are triggers, not evidence

Google's own documentation is explicit that push notifications don't carry resource metadata, file content or paths — they only indicate that something changed, and the application still has to query the API using a resource ID or change token to find out what. Treating a notification itself as a historical record is a category error worth avoiding in any recovery tooling built on top of these APIs.

Delta tokens and cursors expire; they aren't durable audit logs

Microsoft documents cases where an old delta token can no longer be used and returns a 410 Gone response, requiring a fresh resync. A local sync database that stores only the latest delta token or cursor is not a durable historical audit log on its own — if historical evidence actually matters for a case, the client needs to preserve its own change records rather than relying on the provider to remember everything indefinitely.

Local sync-client databases are recovery evidence too

Desktop and mobile sync clients maintain their own local state — object IDs, paths, revision IDs, sync status, pending operations, timestamps and conflicts — and that metadata can answer what existed, when it changed, and which object ID or revision to query server-side, even when the actual file content is already gone from that endpoint.

Reconstructing a timeline from IDs and timestamps

Put together, a change feed narrows down when something happened and to which object, and a revisions lookup on that same object ID can then recover what it looked like before. Neither one alone tells the full story of an incident that spans multiple files, endpoints and points in time.

Practical rule

A change token or cursor is a bookmark in a stream, not a copy of what the stream contained. Don't build a recovery process that assumes the change feed itself is the backup.