I deleted a folder by accident and it disappeared from my laptop, my phone and the cloud within about ten seconds. All three copies were gone, because they were not three copies.
Synchronisation and backup solve different problems and the distinction is not obvious until it matters.
What synchronisation actually does
It makes several locations match. That is the entire function.
If a file changes, the change propagates. If a file is deleted, the deletion propagates. If a file is corrupted or encrypted by malicious software, the corrupted version propagates.
Synchronisation protects against hardware failure, because a dead laptop does not take the files with it.
It does not protect against anything you do to the files, because it faithfully reproduces whatever you did everywhere.
What a backup does differently
A backup preserves a state at a point in time, independently of the current state.
The critical property is that changing the live copy does not change the backup. Deleting a file does not delete it from yesterday's backup.
Which means it protects against the failure modes synchronisation cannot: accidental deletion, overwriting, corruption, malicious encryption, and mistakes that are not noticed for weeks.
That last one is why retention matters. A backup that keeps only the most recent state is barely better than synchronisation, because a corruption you notice a month later has already propagated into it.
Version history is a partial answer
Most synchronisation services do keep previous versions and deleted files for some period, which is what saved me.
The limits are worth knowing. Retention periods vary and are frequently shorter than people assume, sometimes thirty days on consumer tiers.
Restoring many files from version history is frequently a poor experience compared with restoring from a real backup, since the interfaces are built for recovering one document.
And a mass deletion or encryption event can exceed retention limits or be difficult to reverse in bulk.
It is genuinely useful and it is not equivalent to a backup, and treating it as one is the mistake I made.
The rule that covers it
The commonly cited principle is three copies, on two different kinds of media, with one off-site.
A more useful modern version adds two conditions: one copy offline or otherwise not writable by the live system, and verified restores.
The offline requirement exists because malicious software encrypts everything it can reach, including connected backup drives and mounted cloud storage. A backup the compromised machine can write to is a backup that can be destroyed.
Which is why immutable or append-only backup storage has become standard practice in organisations and is worth considering for anybody with irreplaceable data.
The restore test
The step almost nobody performs.
A backup that has never been restored is a hypothesis. The failure modes are numerous: incomplete coverage, corrupted archives, missing encryption keys, formats that require software you no longer have.
Once or twice a year, restore something real and confirm it opens.
The first time I did this I discovered my backup excluded a directory containing exactly the files I would most have wanted, because of a filter set years earlier and forgotten.
What I actually run now
Synchronisation for convenience and device failure, which is what it is good at.
A versioned backup to a separate service with a long retention period, which is not the same account as the synchronisation.
A local copy on an external drive, updated periodically and then disconnected, which is the offline element.
And an annual restore test.
The cost is modest and the setup took an evening. The alternative, which I had before, was three copies of exactly the same mistake.
What to check on any service you rely on
How long deleted files and previous versions are retained, in days, on your specific plan.
Whether restoring a large number of files at once is practical.
Whether the backup destination can be modified by the machine being backed up.
And whether you hold the encryption keys, which determines both privacy and whether you can recover without the provider.
Those four questions take ten minutes and answer whether what you have is a backup or a copy.
Photographs specifically
The category where this matters most for most people, because the collection is irreplaceable and the volume defeats manual management.
Phone photo libraries synchronise by default, which means a deletion or an account problem propagates.
Worth having a separate periodic copy, in original quality rather than a compressed version, somewhere the phone cannot reach.
An external drive updated twice a year is enough, and it is the difference between losing a decade of photographs and losing a weekend of inconvenience.
Encryption and the key problem
One further consideration that determines whether a backup is actually private and actually recoverable.
End-to-end encrypted backup means the provider cannot read your data, which is desirable, and it means they cannot help you recover it if you lose the key.
Which turns the key into the single point of failure for the entire archive.
Storing it somewhere physical, separate from the machines being backed up, is the standard advice and the step most often skipped.
A key held only in a password manager that is itself only backed up by the system you are protecting is a circular dependency, and it is a surprisingly easy one to create without noticing.