Sync is not a backup, and the difference shows up on your worst day

There is a settled way of talking about backup strategy. It is worth asking how much of it survives contact with the detail.

Sync copies changes, including bad ones

A synchronisation service watches for changes and reproduces them everywhere, which is exactly what you want while working. Deleting a folder, saving a corrupted file or encrypting everything with malicious software are all changes, and they propagate at the same speed. Within minutes every device holds the damaged version and the good one is gone.

The property that makes sync useful is the same property that makes it not a backup.

A backup needs separation

The defining feature of a backup is that the machine holding the original cannot silently alter or destroy the copy. That separation can be achieved by disconnecting the medium, by write-once storage, or by a service that keeps versions the client cannot delete. Immutable retention windows, where copies cannot be removed for a fixed period regardless of credentials, exist precisely for this.

The short version: without separation you have redundancy against hardware failure and nothing against mistakes or attackers.

Versioning is the practical middle ground

Many sync services keep previous versions and deleted files for a retention window, which converts them into a limited backup. The value depends entirely on how long the window is and whether it survives an account compromise. A ransomware event that goes unnoticed past the retention period leaves nothing to restore.

Under load, checking the retention period on services you already pay for takes minutes and is usually the cheapest improvement available.

The three-two-one habit

The long-standing rule is three copies of anything you care about, on two different kinds of media, with one held somewhere else. The offsite copy protects against fire, theft and flood, which defeat every copy in one building regardless of how many there are. The different media requirement guards against a shared failure mode, such as a batch of drives failing together or a filesystem bug.

The rule predates the cloud and translates onto it cleanly.

Restores are the part that fails

Backups fail silently far more often than they are noticed, because nothing tests them until they are needed. Common failures include jobs that stopped months ago, encrypted archives whose key was stored only on the lost machine, and backups that never included the folder that mattered.

Restoring a handful of random files quarterly finds all three cheaply. A full restore rehearsal once a year is the honest version and almost nobody does it.

What to include that people forget

Authentication seeds for two-factor codes, password vaults, recovery keys and licence details are the items that make a restore possible at all. Photographs held only on phones and in a vendor account are a single ecosystem away from being one copy.

Configuration, browser bookmarks and email held only on a server are frequently outside any backup you control. A written list of what would need to be recovered, made once, exposes the gaps faster than any software.

The takeaway

If the original can delete the copy, it is not a backup. Test a restore before you need one.

The constraint is almost always physical, and marketing rarely mentions which one.