Once you have cloud storage, every file faces a question: does it go in the synced folder, or stay local? Most people answer it inconsistently, which produces the worst outcome — two parallel structures, neither complete, and a permanent low-grade uncertainty about where anything is.
The answer isn't "everything in the cloud." Some files genuinely shouldn't be synced, and some will cause problems if they are.
The four buckets
Every file belongs in one of these:
1. Cloud, pinned. Active work. You need it on multiple devices, you need it offline, and it changes often. Current projects, this year's documents.
2. Cloud, online-only. Things you need access to occasionally but not locally. Archives, reference material, finished projects, media libraries. Present and searchable, taking no disk space.
3. Local only, backed up separately. Files that shouldn't or can't be synced — see below. These need their own backup, because sync isn't doing it for them.
4. Local scratch, not backed up at all. Temporary work, downloads you'll delete, exports, rendering caches. Deliberately disposable.
Most files fall into buckets 1 and 2, and the useful discipline is moving things from 1 to 2 as they finish, rather than pinning everything forever.
What should stay out of cloud sync
These are the categories where syncing causes real problems, not just inefficiency.
Application databases and library files. Photo library packages, email databases, accounting data files, password manager vaults with their own sync, note applications with proprietary storage. These are single large files, or bundles that look like files, constantly modified while the application is open. Syncing them mid-write produces corruption, and it's the most common cause of catastrophic cloud-related data loss.
If you take one thing from this article: don't put a live application database in a synced folder. Use the application's own sync if it has one.
Virtual machines and disk images. Enormous single files that change on every use. Every session triggers a re-sync of the whole thing.
Development environments. Dependency folders with tens of thousands of tiny files, generated build output, version control internals. Syncing these is slow, conflict-prone, and pointless — the source of truth is your version control system.
Active video and audio projects. Scratch files, render caches, and constantly-rewritten project files. Work locally, move the output to the cloud when finished.
System and application folders. Program installations, system libraries, anything outside your documents area.
Very large files you access constantly. Games, sample libraries, datasets. There's no benefit and considerable cost.
The general rule: if an application writes to a file continuously while running, don't sync that file. Sync is designed for files that are saved and then left alone.
What definitely belongs in the cloud
Documents. Everything you write, read, or fill in.
Photos and videos you care about, once they're out of the editing stage.
Anything you'd be devastated to lose. Tax records, contracts, identity documents, irreplaceable personal material — with the important caveat that cloud sync isn't a backup, so these need a second protection too.
Anything you need on more than one device.
Anything shared with anyone.
Reference material. Manuals, receipts, scans, saved articles — the material you look up rather than work on.
Use one structure, not two
The most valuable single decision: your cloud folder is your documents folder. Not a separate thing you copy files into.
Point your work at the synced folder. Save there by default. Set your applications' default save location to it. The computer's own Documents folder either becomes the synced folder (most clients can take it over) or goes unused.
Two structures — a local one and a cloud one — guarantee divergence. Files get saved to the wrong one, edited in both, and within months you have two half-complete copies of your working life and no idea which holds the newer version of anything.
Same folder names, same numbering, same shape, one location.
Where local files live, and how they get protected
For bucket 3 — things that must stay local — create a clearly named folder outside the synced tree:
~/Local (not synced)/
Photo Library/
Video Projects/
Virtual Machines/
Dev/Naming it explicitly matters, because the default assumption for anyone looking at your machine — including future you — is that everything is synced.
Then make sure it's actually backed up. This folder is by definition not covered by cloud sync, so it needs a real backup routine: an external drive with automated backup, or a cloud backup service pointed at it. This is the gap that catches people who assume cloud storage covers everything.
Scratch space, and why it should exist
Bucket 4 needs a home too, and the desktop shouldn't be it.
~/Scratch/Downloads you're about to open, exports you're about to email, files someone sent you. Nothing lives here more than a week. Nothing here is backed up. Empty it on a schedule.
Having a designated disposable area is what stops disposable things from accumulating in permanent ones. And it keeps your synced folder — the thing consuming your paid storage and your bandwidth — free of files that were relevant for four minutes.
The desktop and downloads question
Two specific folders that cause endless trouble.
Desktop: most cloud clients offer to sync it. This is reasonable if your desktop is deliberately kept clean, and a bad idea if it's your working surface, because you'll be syncing dozens of transient files continuously. Better to keep the desktop empty by habit and not sync it at all.
Downloads: never sync this. It's the highest-churn, lowest-value folder on any computer — installers, duplicates, files you opened once. Syncing it wastes storage and bandwidth on material with essentially no value.
What happens across devices
The four buckets look different on each machine, and that's correct:
Main computer: most things pinned, local-only folder present and backed up.
Laptop: almost everything online-only, current project pinned, minimal local-only material.
Phone: nothing local except specifically-marked offline files. Photos uploading automatically.
Tablet: whatever you actually use it for, usually reading material pinned for offline.
The structure is identical everywhere. What varies is which parts are downloaded.
Deciding for a new file, in one question
When you make something new, ask: would I be annoyed if this vanished?
Yes → synced folder, and confirm it's covered by a real backup too. No → scratch. Yes, but it's a live application database or a huge working file → local folder, and make sure that folder is backed up.
That's the whole decision. It takes a second and it prevents the parallel-structure problem entirely.
The setup, once
- Make the cloud folder your documents folder. Set application defaults to save there.
- Build the same numbered structure inside it that you'd use anywhere.
- Create
Local (not synced)and move application libraries, VMs, and big working projects into it. - Point a real backup at both the cloud folder and the local folder.
- Create
Scratchand use it. - Don't sync Downloads.
Twenty minutes, and afterwards there's exactly one place anything could be.
Next in this series: What Happens to Your Cloud Files When You Stop Paying