Sync and backup answer different questions
Synchronisation keeps the current state consistent across devices. Backup preserves a recoverable earlier state. These sound similar and fail in opposite directions.
A sync service may propagate a deletion to its other signed-in copies according to its service and retention settings. That is useful for consistency, but it can also remove data people assumed was independently backed up.
How a synchronised deletion propagates
Deleting on one device typically removes the item from every signed-in device, usually into a recently-deleted area with a limited retention window. After that window, the item is generally gone from the sync service entirely.
The same propagation applies to corruption and to unwanted edits. A synced state is a single shared state, which means a single mistake reaches everywhere the state is mirrored.
Account dependency is part of the risk
A sync service is reachable only while you can reach the account. Lockout, a compromised credential, or an account action taken by the provider can remove access to content that is otherwise intact.
This is not an argument against cloud services — it is an argument for not letting the account be the only path to your own data.
What makes a backup a backup
A backup is a separate, point-in-time copy that survives independently of the primary system. For private content, it should also be encrypted before it reaches the storage location, so the provider holds ciphertext rather than readable images.
The key and the storage should survive independently of each other and of the phone being protected. A backup whose secret lives on the device it protects is one loss away from being unusable.
Build the arrangement deliberately
- List what the sync service mirrors, and how deletion and editing propagate.
- Check version history, retention windows, and account recovery options.
- Create a separate encrypted point-in-time backup that does not depend on the sync account.
- Store the backup's recovery secret somewhere separate from both the backup and the phone.
- Test recovery without the primary account or the primary device.
Common confusions worth naming
- Calling every uploaded copy a backup because it is “in the cloud”.
- Ignoring that the sync account is a single point of failure.
- Assuming encryption has anything to say about deletion recovery.
- Counting a backup as working because it was created, not because it was restored.
Using both, without confusing them
Most reasonable arrangements use both: sync for availability and convenience, and a separate encrypted backup for recovery. The failure comes from believing one is providing the other's guarantee.
One useful test is to ask what you could still open if an account were unreachable tomorrow. The answer reveals an access dependency, but retention, version history, and whether the copy is independently recoverable still determine whether it functions as a backup.
A fictional example
Noah starts with a non-sensitive test: “List what the sync service mirrors and how deletion propagates.” Next, Noah follows the second check: “Check version history, retention, and account recovery.” This fictional scenario demonstrates the decision process; it is not a report of product testing.
Common mistakes
- Calling every uploaded copy a backup
- Ignoring account dependency
- Assuming encryption explains deletion recovery
What this workflow does not change
- Calling every uploaded copy a backup
- Ignoring account dependency
- Assuming encryption explains deletion recovery
Questions people ask
Can a cloud file be a backup?
Yes, if it is a distinct encrypted copy with suitable retention and an independent recovery path.
Does local-first mean no backup?
No. It means the live private library can remain local while the user deliberately creates portable encrypted backups.