Most people set up a sync folder, watch it appear on the laptop and the desktop, and quietly file the problem under "solved." It isn't solved. Sync and backup answer different questions, and the day you find that out is usually a bad day. This is for anyone whose work lives in a cloud folder and who has never actually tested getting an old version back.
The verdict
If deleting a file everywhere at once would hurt, sync alone is not a plan.
Sync is about where a file is. Backup is about when a file was. You need both, and for different files.
What sync actually does
A sync service keeps one live file consistent across several machines. Change it on the laptop, and the desktop gets the change. That is the entire feature, and it is genuinely useful: no more report_final_v3_REAL.docx emailed to yourself.
But the mechanism cuts both ways. Sync propagates every change, including the ones you regret. Delete a folder at 9 a.m. and the deletion lands on every device you own — that is the system working correctly. Overwrite a good draft with a bad one and the good one is gone from every machine at the same moment. If a piece of software on one machine rewrites your files — ransomware being the obvious case — sync treats those rewrites as legitimate edits and pushes them out. A mirror does not judge what it reflects.
Most sync services do keep some version history, and that history has saved a lot of people. Treat it as a convenience, not as your backup. History windows, what counts as a "deleted" file, and how far back you can go vary by provider and plan — check your provider's documentation for the specifics of yours, because those details are exactly what you'll be relying on under pressure.
What backup actually does
A backup is a copy of an earlier state, stored somewhere that does not automatically follow your live files. The point isn't redundancy — sync gives you redundancy. The point is time travel: the ability to say "give me this folder as it was last Tuesday" and get it.
The word doing the work is versioned. A copy that gets overwritten every night with whatever is currently in your folder is a mirror with a delay. If you don't notice a problem before the next run, the mirror has already caught up with the mistake. Versioned backup keeps distinct restore points, so noticing late still leaves you something to restore from.
The second word doing work is separate. If your backup can be deleted by the same account, the same password, or the same piece of malware that reaches your live files, it shares a failure with them. A widely used guideline, commonly called the 3-2-1 rule, is a reasonable starting point: keep more than one copy, on more than one kind of storage, with at least one of them somewhere your daily machine cannot reach on its own. Treat it as a rough shape to aim for rather than a standard, and adjust it to what you actually have.
Sync vs. versioned backup
| Sync | Versioned backup | |
|---|---|---|
| What exists | One live file, mirrored to several devices | Copies of earlier states, kept apart from the live file |
| Protects against | Losing a device; being on the wrong machine | Deletion, overwrite, corruption, a bad edit you notice late |
| When you delete a file | It disappears everywhere | Earlier restore points still hold it |
| Recovery question it answers | "Where is my file?" | "What did my file look like before?" |
| Typical failure | A mistake propagates instantly and silently | You never tested a restore, and it doesn't work when you need it |
| Good for | Active work, collaboration, small teams | Anything whose loss would cost you money, time, or trust |
The decision path
Sort your files into four buckets. How long this takes depends on how much you have accumulated — set aside an unhurried half hour to start, and expect to refine it later. This sorting is the whole exercise.
Bucket 1 — sync it. Files you are actively working on, across more than one machine or with other people. Current projects, working documents, shared team folders, notes. The value here is being able to pick up where you left off. Sync is the right tool and it does not need to be the only one — these files usually belong in bucket 2 as well.
Bucket 2 — back it up, with versions. Anything you could not recreate, or could only recreate expensively. Client deliverables, financial records, contracts, original photos and recordings, code that isn't pushed anywhere, the years of notes you've accumulated. Ask one question per folder: if this vanished and my sync history didn't cover it, what would I have to do? If the answer involves apologizing to someone or redoing paid work, it goes here.
Bucket 3 — neither. Not everything deserves protection, and pretending otherwise makes the first two buckets slower and more expensive. Files you can re-download at any time. Exports you generated from a source you still have. Caches, build artifacts, installers, sixty screenshots from a bug you fixed last year.
Bucket 4 — archive it. Old material you want to keep but never touch. Finished projects, past client work, source files for things already shipped. This wants cheap, cold, versioned storage — not a sync folder that pays to keep it live on every laptop you own. The test is simple: if you would be annoyed to lose it but would not notice for a year, it belongs here.
A file can sit in more than one bucket. Most working files should: sync for access, versioned backup for time travel.
The step everyone skips
An untested backup is a belief, not a system. Pick one real file — not a test file you just created — and restore it from a point at least a week old. Time it. You are checking three things: that the restore path exists, that you can follow it without hunting for a password you no longer have, and that the recovered file actually opens. Do it once when nothing is wrong. Repeat it occasionally, and especially after you change providers, machines, or accounts.
Who can skip this
If everything you make lives in a system you don't administer — documents in a company-managed workspace, code pushed to a shared repository, records in a tool your employer runs — then someone else's retention policy is already covering you. Find out what that policy is, rather than building a parallel setup that duplicates it badly. The same goes if your work genuinely is disposable and re-creatable; a heavy backup routine is cost and maintenance for no benefit.
You should not skip it if you freelance, run your own machine, keep client material locally, or have ever said the words "it's in Dropbox" as a complete answer to where something lives.
Do this next
Open your sync folder and find the single file whose loss would hurt most. Restore an old version of it from wherever you believe your backups are. Whatever happens in the next ten minutes will at least tell you whether the restore path exists and whether you can follow it. It will not tell you everything — it says nothing about how far back your history goes, or whether your copies are truly separate — but a plan that fails this test was never a plan.