Skip to content

The 3-2-1 Backup Rule, Adapted for App Users

The 3-2-1 backup rule is the oldest good advice in computing: keep three copies of your data, on two different media, with one copy offsite. It was invented for servers and file cabinets, but it adapts beautifully to the app era — where your “data” is scattered across dozens of services and your “media” are cloud accounts and hard drives. This guide translates the rule for how people actually live now.

Think of this as the practical backbone underneath our other guides: the export methods in Canceling Subscriptions: What to Check Before You Click Cancel thinking produce the copies, and the preparedness discipline in Your 2026 Shutdown-Preparedness Checklist for Every App You Use keeps the system running. The rule itself is simple; the adaptation is where the value lies.

The rule, stated plainly

Three copies of anything you cannot afford to lose. Not three versions of the same file in the same folder — three genuinely separate copies, so that any single failure (deleted, corrupted, hacked, shut down) leaves you with two. Two different media types so that one class of failure cannot take all copies: if all three copies are in the same cloud account, a billing error or account closure takes everything. One copy offsite so that a local disaster — theft, fire, flood — does not coincide with data loss.

The logic is combinatorial, not superstitious. Each requirement defeats a different failure mode, and the three together cover nearly everything short of catastrophe. It is not about paranoia; it is about making the common failures survivable, because the common failures are the ones that actually happen.

Translating it for the app era

In the app era, “your data” is not a folder — it is your photos in one app, notes in another, documents in a third, plus the exports and archives you maintain yourself. The translation: for each critical data category, ensure three copies exist across at least two independent locations, with one copy somewhere a local disaster cannot reach.

A concrete example for photos. Copy one: the cloud photo app itself. Copy two: a quarterly export on an external hard drive at home (different media, local). Copy three: the same export uploaded to a second cloud account, or a drive stored at a family member’s house (offsite). Three copies, two media types (cloud + physical drive), one offsite. The rule holds; only the nouns changed.

For notes: copy one is the notes app; copy two is the monthly Markdown export on your computer; copy three is that export synced to a second cloud account or external drive. For documents: the cloud drive, the local sync folder (which counts as a separate copy only if sync is versioned or the folder is also backed up), and the external archive. The pattern repeats; learn it once, apply everywhere.

Stacked external hard drives
Illustration: stacked external hard drives

What counts as a “copy” (and what does not)

This is where most people’s backup plans quietly fail. A synced folder is not an independent copy — delete a file on one device and sync deletes it everywhere; that is mirroring, not backup. What makes a copy count is independence: it must survive the failure of the other copies, including your own mistakes. Versioned backups (which keep old versions after changes) count. Point-in-time exports (frozen snapshots) count. Live sync does not.

Similarly, two folders in the same cloud account are not two media — one billing dispute or account closure takes both. Two different cloud providers, or cloud plus physical drive, are genuinely different. And “offsite” means protected from the same physical risks: a drive in the next room is not offsite from your laptop; a drive across town is.

Apply the independence test ruthlessly to your current setup. Most people discover their “three copies” collapse to one or two real ones under scrutiny — the phone and laptop both sync to the same cloud, the “backup drive” has not been plugged in for a year. The audit is slightly uncomfortable and enormously valuable.

Three concrete setups for real people

The simple setup (under an hour, minimal cost)

For someone starting from zero: buy one external drive, plug it in monthly, and copy your exports and important folders to it. Keep using your cloud apps as copy one. Upload the most irreplaceable category — photos — to a second free cloud account as the offsite copy. Total cost: one drive. Total maintenance: one monthly session. This covers the failures that actually happen to regular people.

The thorough setup (the full rule, properly)

Quarterly full exports of every critical app, stored on an external drive (copy two) and uploaded to a second cloud provider or a drive at a relative’s house (copy three, offsite). Monthly exports for fast-changing data like notes and finances. Automated where possible — sync clients, scheduled exports — manual where not. Annual restore test to verify the whole chain. This is the complete system, and it runs on a few hours per quarter.

The minimalist setup (for the backup-averse)

If you will not maintain a system, at least do this: once a year, export everything critical to an external drive, put the drive somewhere other than your home, and write down what is on it. It is not 3-2-1 — it is 2-1-1 — but it beats the far more common 1-0-0. Imperfect backup done beats perfect backup planned.

Automate the discipline away

Every manual backup step is a step you will eventually skip, so automate relentlessly. Use apps with sync clients that maintain a local mirror. Enable scheduled exports where offered. Set calendar reminders for the steps that cannot be automated, with the exact procedure in the event description so future you does not have to rediscover it.

The goal is a system that degrades gracefully under neglect. If you miss a month, the previous month’s copies still exist. If you abandon the external drive for a quarter, the cloud copies persist. Design for your actual behavior — including the lapses — not for an idealized disciplined self. Systems that assume perfection fail; systems that assume humanity endure.

Credit cards with receipts and a smartphone on a desk
Illustration: credit cards with receipts and a smartphone on a desk

Test the restore, not just the backup

A backup you have never restored is a hypothesis. Once a year, pick one category and actually restore something: open exported files on a different device, import a sample into a fresh account, confirm the data is intact and usable. This catches the silent killers — corrupted archives, expired links, formats your new computer cannot open — while there is still time to fix them.

The restore test also answers the only question that matters: if the app disappeared tomorrow, could you rebuild from these files? If yes, your system is real. If no, you have found the gap cheaply — which is the entire point of testing. Untested backups are where false confidence lives; the annual test evicts it.

Answering the common objections

“I don’t have anything important.” Everyone thinks this until they list it: the photos, the messages from someone no longer here, the work samples, the records. Importance is usually discovered at the moment of loss, which is the worst possible time for the discovery. Assume your data matters; the audit takes an hour and settles the question with evidence instead of vibes.

“The cloud company handles backups.” They handle their continuity — keeping the service running — not your recovery from your mistakes, their account actions against you, or their business decisions. Their backups serve their needs; your backups serve yours. These are different jobs, and only one of them is looking out for you specifically.

“I’ll do it when I have time.” You will not; time does not appear, it is allocated. The minimalist setup takes one annual session — put it on the calendar now, with the drive purchase as the first action item. Future you, facing any data emergency, will consider this the highest-ROI hour of the year.

Frequently asked questions

Is 3-2-1 enough, or do I need more?

For personal data, 3-2-1 properly implemented is enough — it covers device failure, account problems, service shutdowns, local disasters, and your own mistakes. More copies add complexity without meaningfully reducing risk for most people. Implement the rule well before considering anything fancier.

Do two different cloud providers count as two media?

Yes, for the practical failure modes that matter — one provider’s outage, billing error, or shutdown does not affect the other. Purists note that both are “cloud,” but independence of failure is the real criterion, and separate providers with separate accounts satisfy it. Cloud plus physical drive is still the gold standard for maximum independence.

How many versions back should I keep?

For most personal data, the last two or three point-in-time copies suffice, plus any versions tied to meaningful milestones (before a big migration, end of a project). More versions help against slow-burn corruption — the file that was damaged months ago — but each additional version is storage and complexity. Two to three is the sweet spot.

Should backups be encrypted?

Offsite and portable copies — yes, always. A drive at a relative’s house or a second cloud account should be encrypted, because you control those environments less. The encryption password goes in your password manager (which itself follows the rule). Local copies on your own encrypted computer are fine as they are.

What does all this cost?

Less than the data is worth. One external drive covers the physical side for years. Second cloud accounts are often free at the capacities personal archives need, or modestly priced above that. The real cost is time — a few hours per quarter — which is the cheapest insurance you will ever buy against the most common data disasters.

Three copies, two media, one offsite. It fit on an index card in the 1990s and it fits in a cloud account today. Translate it for your apps, automate what you can, test the restore yearly — and no shutdown, no failure, no mistake gets to take what you cannot afford to lose.

Leave a Reply

Your email address will not be published. Required fields are marked *