How to test that your backup actually works

A backup said it finished. Whether the file would come back is a different question, and the answer is not on the backup screen. It is in one small restore, done deliberately. This page shows that test on Windows, Mac, and phones, then the signals that a backup has quietly stopped.^[1]

A backup you haven't tested is a maybe

The agencies that write ransomware guidance do not ask whether you have a backup. They ask whether you have checked it. CISA's StopRansomware guidance says to maintain offline, encrypted backups of data and regularly test those backups. The UK's National Cyber Security Centre is sharper: check that you know how to restore files from the backup, and regularly test that it is working as expected. Neither says how. This page is the how.^[2][1]

Test a restore, not the backup job

A completion message proves the job ran, and nothing more. Damaged or skipped files never announce themselves at backup time. The only real test is pulling files out and opening them, and every check below is a small restore, not a read of a settings screen.^[1]

Windows: restore a file from File History or Previous Versions

Pick a file you could stand to lose and that File History would have copied, something in Documents or Pictures. The test is a Previous Versions restore in File Explorer: a version from an earlier date that appears and opens is the proof, and a version list that keeps growing after each backup run is the ongoing proof.^[3]

File History and Previous Versions, step by step

Mac: go into Time Machine and pull one file back

The top of the Time Machine menu shows how much of the current backup is done, or the date and time of the latest backup. That date is what you are testing, because a completion report is not proof the files are readable. Restored items return to their original location, so the file you pull back lands where the real one lives.^[4][5]

Restoring from Time Machine, step by step

Phones: check the backup your phone actually made

Phone backups hide their status, and the two platforms tell you different things. Restoring a phone usually means wiping and setting it up, so here the check is reading what the backup says about itself.^[1]

iPhone and iPad

Open Settings, tap your name, tap iCloud, then tap iCloud Backup. Under Back Up Now is the date and time of your last backup. That date explains most surprises on its own: Apple's automatic backup needs the device on Wi-Fi, connected to power, and locked, which is why a phone that never sits still can go weeks between backups. Not enough iCloud storage shows up as an alert.^[6]

Android

Backup lives under Settings, Google services, All services, Backup, where you turn Backup on and tap Back up now. Google's signal is different: the word On appears under each data type once that data is saved, and a Backup details screen shows what was actually backed up. Google states a Google One backup can take up to 24 hours, so a backup made this morning may not show itself until tomorrow. Android tells you it is on and what it covers, Apple shows a date and time, and the two are not equivalent.^[7]

When backups quietly fail

The most common quiet failure is a full destination, and Time Machine handles it in a way that can mislead you: Apple states the oldest backups are deleted when the backup disk is full, so a drive that is always full is quietly eating your oldest copies. The case that interrupts backups is different: your Mac will tell you when Time Machine needs more storage space, and for a disk that is nearly full Apple suggests one with at least twice the Mac's storage.^[4]

A backup that seems to hang is not always stuck. After the first backup, Time Machine copies only the changes since the last one, so later backups should be fast, but some apps keep their data in unusually large files that update often, and Time Machine backs those up every time it sees they changed. Apple's fix is to exclude files like that.^[8]

On Windows the honest check is the restore test above. File History's documented target is an external drive or network location, so connect that drive, run a backup, and look for a new version in Previous Versions. If nothing new appears across several runs, the backup is not reaching the drive, and reconnecting or reselecting it in File History settings is where to start.^[10]

How often to test

Test whenever the backup set changes: a new drive, a new computer, a new phone, folders added or removed. Changes are where backups break silently, and one meaningful restore from the new setup catches it. Between changes, one small restore every month or two is plenty. The cadence is this site's recommendation; the agencies only say that testing is part of the job.^[1]

How often should you back up?

Related reading

If the test finds nothing to restore, the backup never existed or died with its drive, and the job becomes rebuilding rather than testing. Once a test passes, the next question is whether one copy is enough.

Setting up backups after you have lost data

The 3-2-1 rule, explained

Not sure where to start?

Guided help points you at the right guide