Keeping your own data alive

That list is the whole subject. Not "backing up your computer", which is a chore nobody ever finishes. A specific short list of things that exist nowhere else, and the question of what would have to happen for them to be gone.

One sentence, and everything comes out of it

This is the sentence this lesson exists to give you.

A backup is a copy that a mistake on the original cannot reach. And the only way to know you have one is to restore from it.

Read it twice, because both halves do work, and almost everything people get wrong about this is a failure of one half or the other.

Notice what the sentence does not contain. It doesn't say how many copies. It doesn't say what they should be stored on, or where. Those are all real, and they are consequences rather than rules, which is why they are worth deriving rather than memorising:

More than one copy, because copies fail. A drive stops working, and if that drive held your only copy, then, the number of copies was the problem.

Different kinds of storage, because one kind fails in one way. Two drives bought on the same day from the same batch is less independence than it looks.

Somewhere else, because a fire, a flood or a burglary takes a building rather than a device. Both your laptop and the drive beside it are in the same building.

You may have met a numbered rule that packages those three. This lesson does not teach the numbers, deliberately. The numbers are a mnemonic for the property, and if you have the property you can derive them, while if you have only the numbers you cannot tell which of your copies actually counts.

Why sync is not backup

Lesson 2 told you a synced folder is a directory in the tree with a program watching it. That program has a name, the sync client, and its job is to make every device match. That's what it's for, and it does it well.

Now follow that job to its conclusion. A sync client cannot tell a person saving a file from a program damaging one. It sees that a file changed. It has no view about whether the change was wanted, because it can't have one. So it faithfully uploads the damaged version, and every other device faithfully downloads it.

The same is true of deletion. You delete a file, the client sees a file that is no longer there, and it makes every other device match.

This isn't a flaw, and there's no version of sync without it. A client that second-guessed your saves would be unusable. The problem is only that people use it as an answer to a question it was never asked.

That last step is the one that matters, and the next section is about what you found.

Version history, and the window it lives in

Version history is a real defence and it's worth having. It keeps the earlier contents of a file for a while after they change, so the demonstration you just ran is recoverable.

Two things bound it.

It has a documented retention window. Not forever. It's a specific number of days, which depends on your provider and on which plan you are on, and which the provider publishes.

One provider's, so you know what you're looking for. Dropbox's own documentation, read on 18 September 2026, gives 30 days on its Basic, Plus and Family plans, 180 days on Professional, Essentials, Business and Standard, and 365 days on Business Plus, Advanced and Enterprise.¹ The same page says you cannot restore previous versions of files that have been permanently deleted, and that add-ons can extend the windows.

Those numbers are Dropbox's and they are today's, which is why the exercise below sends you to your own provider's page rather than telling you your answer. A figure in a lesson about a company's product goes stale; the habit of reading the page does not.

And it only helps with damage you notice inside the window. That's the quiet limit, and it's worth sitting with.

Think about how a file goes wrong without anybody shouting. A save that went badly. A program that wrote out something malformed and then closed. A conversion that dropped half a document. None of those announces itself, and if you don't open the file again, nothing tells you. A file you look at twice a year can pass through the whole retention window in that state, and come out the other side with the good version gone.

The case the guidance is actually written about

There is a class of attack where a program encrypts your files and asks for money, and it is worth knowing what the official guidance says about backups, because it is not what backup companies say.

The United States' Cybersecurity and Infrastructure Security Agency publishes a ransomware guide. Its sentence on this is direct:²

"It is important that backups are maintained offline, as many ransomware variants attempt to find and subsequently delete or encrypt accessible backups to make restoration impossible unless the ransom is paid."

Read that word accessible, and read the last clause too, because it names the motive. The guidance is not about how many copies you have or what they are stored on. It's about reach, which is the property from the first section arriving from a different direction. A copy the machine can write to is a copy that something running on the machine can destroy, and a synced folder is by definition a place the machine can write to.

What the guidance does not say is that version history is useless. It says the opposite. It recommends enabling version control "to keep multiple variants of objects in storage", because that "allows for easier recovery from unintended or malicious actions", and separately recommends enabling delete protection or object lock on storage that is often targeted.²

So the honest picture is layered rather than dismissive. Versioning is a real defence with a bounded window. An offline copy is the thing that survives when the machine itself turns against you. And the guidance asks for both.

It also says two things about testing, which is the second half of this lesson's sentence: maintain "offline, encrypted backups of critical data, and regularly test the availability and integrity of backups in a disaster recovery scenario", and "test backup procedures on a regular basis".²

One thing this lesson will not tell you, and it's worth saying because the claim is everywhere. There's a widely repeated line that ransomware defeats version history by renaming files, so the version chain breaks.

This course went looking for it in CISA's guide, which is the source for the rest of this section, and it isn't there. Where this course did find it was in material published by firms selling backup products, which is marketing rather than evidence.

That is not proof the claim is false. It's one page, checked once, and other bodies publish on backups too. It's a reason not to print it here, and to give you CISA's actual claim instead, which is about reachability and happens to be the more useful of the two.

Why the restore is the only test

Now the second half of the sentence, and the part almost nobody does.

A backup system isn't one thing. One way to take it apart, and this is this course's carving rather than anybody's standard:⁵ a schedule, which decides when. A selection, which decides what. A destination, which decides where. A format, which decides whether anything can read it back. And credentials, which decide whether you can still get in.

Every one of them can fail silently while the indicator stays green.

The schedule can run perfectly on a folder you haven't used since 2019. The selection can quietly exclude the one directory that matters, because the default excluded it and nobody looked. The destination can be full. The format can need a program you no longer have, or a password you set once and have not typed since. The credentials can belong to an account you closed.

A restore is the only operation that exercises the destination, the format and the credentials together. Restore one file and you have tested four of the five for that file, because you have also proved that that file was selected. What you have not tested is the selection for everything else, which is why "I restored a file" and "my backup covers what I think it covers" are still two claims and not one.

Even so, these are two very different statements:

• "I have backups."
• "I have restored a file from my backup."

Only the second one is about the future. The first is about an intention.

What people get wrong

"Sync is backup." Sync makes copies match. Backup keeps a copy a mistake cannot reach. Those are different jobs, and the first one actively propagates the mistake, which you watched it do in the exercise above.

"It's on two devices, so it's safe." Ask the sentence. If both devices sync to the same account then one mistake reaches both, and two is a count rather than a property.

"The important thing is how many copies I have." The count is a consequence of the property, not a substitute for it. Three copies in the same account is one copy with a bigger number attached, and one copy in a drawer is a backup.

"My backup runs every night, so I have a backup." No restore, no backup. Everything in the section above can be broken behind a green indicator.

"My photographs are safe because they're in my phone's gallery." This is the one to be most careful about, because it's the commonest and it feels the most solid.

The gallery is a view of what is on the phone plus, usually, what is in a synced account. Delete a photograph and it goes from both, after a bin period. Lose the phone and the account is what you have left, which is real. But a mistake in the account reaches everything, and for a great many people the account is the only copy. For an irreplaceable set of photographs, the honest question is the one from the first section: is there a copy that a mistake on the account could not reach? For most people the answer is no, and an annual export onto a drive that lives in a drawer costs an hour and closes it.

Practice

Connections

Lessons 2 and 3 are why this lesson is possible at all: you can't back up what you can't locate, and the first exercise here is unanswerable if you do not know where your files live.

Lesson 3 also gave you five causes of a file going missing, and a backup answers none of them cleanly. A file you moved, renamed, saved into an application's own storage, or left in a default location you never chose is not lost, and restoring it from a backup is the wrong repair for all four. The fifth is the one to sit with: a file that was never saved anywhere at all. A backup cannot touch that, because there was never anything to copy. Backing up isn't a substitute for knowing where things are.

Lesson 9 is one of the mistakes a backup has to survive. Something you installed is a thing running with your access, and your access includes the drive plugged in beside you.

Lesson 13 asks the same question about copies somebody else holds. This lesson is about the copies you control. That one is about the ones you don't, and how to find out what they are.

Go deeper

• CISA, the #StopRansomware Guide, free, a US government work. The backup section is short and it is the primary source for this lesson's second half. Read it for the difference in tone from commercial advice on the same subject: it tells you what to do and hasn't anything to sell you.
• Your own provider's version-history documentation. Whichever one you use. This is the second exercise above, and it is in Go deeper as well because it is the only item in this lesson that stays useful after the lesson, given that the numbers change and the page does not move.

Sources

1. Dropbox, "Version history overview", help.dropbox.com. Fetched and read 18 September 2026. Primary for a claim about that provider's own product. Supplies the documented retention windows with the plan names as Dropbox writes them: 30 days on Basic, Plus and Family; 180 days on Professional, Essentials, Business and Standard; 365 days on Business Plus, Advanced and Enterprise. Also supplies the statement that previous versions cannot be viewed or restored for files that have been permanently deleted, and that add-ons can extend the windows. These figures are one provider's and are dated deliberately, because this is exactly the kind of number that goes stale inside a year, and the lesson sends the reader to their own provider's page rather than relying on them.
2. Cybersecurity and Infrastructure Security Agency, #StopRansomware Guide, cisa.gov/stopransomware. Fetched and read 18 September 2026. Supplies the quoted sentence about maintaining backups offline because many ransomware variants attempt to find and subsequently delete or encrypt accessible backups, which is verbatim; the recommendation to enable version control to keep multiple variants of objects in storage, with the reason given as easier recovery from unintended or malicious actions; the recommendation to enable delete protection or object lock on storage often targeted in ransomware attacks; and both statements about testing, namely maintaining offline encrypted backups and regularly testing their availability and integrity in a disaster recovery scenario, and testing backup procedures on a regular basis. What it does not supply is the claim that ransomware defeats version history by renaming files. This course's research went looking for that claim in official guidance, did not find it there, found it only in material published by companies selling backup products, and withdrew it; standards 2.2 excludes vendor marketing for a product category. research/SOURCES.md records the withdrawal.
3. The sync mechanism in this lesson is demonstrated rather than cited, on the reasoning recorded in research/SOURCES.md and in the outline's decision 4. That a sync client cannot distinguish a person saving a file from a program damaging one is a description of what sync does rather than a finding about the world, and the reader verifies it on their own files in the exercise above. Nothing here rests on a source for it, which is the right treatment for a claim a learner can check in ten minutes.
4. The five-part decomposition of a backup system in "Why the restore is the only test" (schedule, selection, destination, format, credentials) is this course's own teaching frame rather than a finding attributed to any source. Neither CISA's guide nor any other source in research/SOURCES.md offers such a list. It is offered because it makes the argument for restoring visible, which is that a green indicator reports on one of the five at most. Marked here for the same reason lesson 11 marks its three-part account of a con.
5. The numeric backup mnemonic that usually appears in lessons like this one is deliberately absent. Its popular attribution runs through a book this course has not opened, and the property it encodes is taught here directly instead, on the reasoning in the outline's decision 4. A reader who has the property can derive the numerals; a reader who has only the numerals cannot say which of their copies counts.