Short answer
Synchronisation is primarily designed to keep several locations in the same current state. Backup is designed to let you recover an earlier trustworthy state after a file is deleted, overwritten, corrupted or encrypted by ransomware. Sync is useful, but it is not automatically a reliable backup. The important question is not merely whether a file has been uploaded to the cloud. It is whether independent copies, previous versions, deleted-file retention and a workable recovery path still exist when the original device or account fails.
Sync solves a consistency problem
When a computer, phone and cloud folder are synchronised, a change in one place usually propagates to the others. Edit a document on the computer and the revised version appears in the cloud. Move a file and the move is reflected elsewhere. Delete a photograph from the synchronised folder and that deletion may also reach the cloud and every connected device.
This behaviour is the point of sync. It removes the need to copy every revision by hand and reduces confusion about which file is current. Collaboration services can also bring several people's changes into one shared document. The system, however, propagates mistakes as efficiently as intended changes. It cannot ordinarily know whether a deletion was deliberate housekeeping or an accident. It cannot infer that the version you just overwrote was the one you later needed.
Microsoft's OneDrive documentation makes the propagation explicit: adding, changing or deleting an item in the OneDrive folder causes the corresponding item to be added, changed or deleted on the OneDrive website, and vice versa. A file being “in the cloud” therefore does not necessarily make it an isolated copy; the local error may be synchronised to it. Microsoft: Sync your computer's files and folders with OneDrive
Backup solves a recovery problem
Backup is less concerned with making every location identical than with preserving a route back after something goes wrong. A useful backup system commonly provides one or more of the following: multiple historical versions, retention of deleted items, a copy on a different device or under a separate failure boundary, bulk restoration, or protection against an ordinary sync operation immediately rewriting every copy.
Suppose a spreadsheet was correct on Monday, damaged by a bad formula on Tuesday, and not noticed until Wednesday. If the system keeps only the current synchronised state, the damaged spreadsheet may now be identical on every device. If a backup holds Monday's snapshot or version, there is still something to restore. Backup value is not measured by how many identical icons you can see during normal operation. It is measured by how many usable states remain after the incident.
Product language can blur this distinction. Some cloud services call continuous synchronisation of Desktop or Documents folders “folder backup”. That feature can certainly protect files when one computer is lost or its drive fails. Its protection against deletion, overwriting and malicious encryption still depends on version history, recycle-bin retention, account recovery and any independent copy. The label on the button is less important than the recovery behaviour.
The common deletion example
Imagine that your laptop's Documents folder is synchronised with a cloud service. To free space, you delete an old project locally. The sync client sends that deletion to the cloud, and a second computer removes the same project. There were several locations, but they all represented one logical state.
You might recover the project while it remains in the provider's recycle bin. You might recover an overwritten document if version history is enabled. Those are valuable recovery features, but they are not guaranteed merely by the act of syncing. Recovery can still fail if the bin has been emptied, its retention period has expired, the account is inaccessible, or an attacker has removed the cloud versions as well.
Conversely, an external drive connected only once a month may contain an older copy but become extremely valuable after ransomware. If the drive was disconnected during the attack, the malware could not encrypt it along with the live files. This illustrates an important point: good backup design is not only about having another copy. It is about giving copies enough independence that one event does not destroy every one of them.
Questions that reveal what you actually have
Instead of asking whether your files are in the cloud, ask how the service behaves:
- Does deleting a local file automatically delete the cloud copy?
- How many previous versions can be restored, and for how long?
- How long are deleted items retained, and can someone empty the bin immediately?
- If the account is stolen, suspended or inaccessible, is another recovery path available?
- Is any copy disconnected or otherwise protected from immediate deletion and encryption?
- Can you restore a whole folder or system, rather than downloading files one at a time?
- Have you tested the restoration procedure with real files?
If deletion propagates everywhere and the other questions have no clear answers, you mainly have synchronisation convenience rather than a complete backup strategy.
The practical idea behind 3-2-1
The familiar 3-2-1 approach suggests keeping at least three copies of important data, using two different kinds of storage, with one copy off-site or isolated from the primary system. It is not the only possible design, and the numbers do not automatically solve account compromise, version retention or recovery testing. Its enduring principle is nevertheless useful: do not let every copy share the same point of failure.
For an individual, a simple arrangement might include the working copy on a computer, a cloud copy with version history, and an external drive that is updated periodically and then disconnected. For irreplaceable photographs, identity records and creative work, think beyond device failure. Ask whether theft, fire, loss of the cloud account or an accidental deletion could affect all copies together.
An organisation must also consider permissions, immutable backups, retention policy, encryption keys, legal requirements and recovery time. Copying files to another folder on the same server may look like duplication, but a failed drive, administrator mistake or ransomware infection can still damage both folders in one event.
A backup can fail silently
Backup is not a one-time setting that remains trustworthy forever. An external drive can develop faults. An automated job can stop after permissions change. Cloud storage can fill up. A newly created folder may never be included. An encrypted archive can become useless when its key is lost. Recovery instructions may depend on an email account that is no longer accessible.
The meaningful check therefore goes beyond seeing “Backup complete”. Periodically restore a small selection of files and open them. Occasionally verify the recovery path for a whole folder or device. Confirm that failure notifications reach someone who will act. Record how important accounts and encryption keys can be recovered. A backup that has never been tested is a recovery hypothesis, not a demonstrated recovery capability.
My assessment: ask whether the system can return to the past
Product names often blur backup and sync. I ignore the label and imagine one accidental deletion: a week later, can I retrieve a version that the current device did not overwrite? If recovery depends on the same account, sync rule and continuously connected devices, it has not escaped the original failure domain. A backup's value is not another icon; it is a tested route to an earlier state.
One-minute checklist
- Do I know which files are synchronised and which are independently backed up?
- Can I recover yesterday's, last week's or last month's version?
- Will a deletion spread to every copy?
- Is at least one copy isolated from my everyday device or account?
- How long do the recycle bin and version history retain data?
- Have I recently restored and opened a real file?
- If my main email and cloud account are both inaccessible, do I still have a recovery route?
Conclusion
Sync makes the current working state available in several places. Backup keeps a past trustworthy state recoverable. Both are useful, and one product may provide elements of both, but they should not be treated as synonyms. The largest risk is not choosing the wrong cloud brand. It is assuming that “synchronised” means “cannot be lost” without examining version, deletion and recovery behaviour.
Related reading
- Why Can Files Still Be Lost in the Cloud?
- What Is the Difference Between Encryption, Password Protection and Access Control?
Continue reading: All articles in How Digital Life Actually Works
Discover more from Geoffrey Chen
Subscribe to get the latest posts sent to your email.