How do I check my backup is actually working?
Backup software reporting success is not evidence. Here is the twenty-minute test that turns a hopeful backup into a proven one, and what each failure means.
- Difficulty
- beginner
- Time
- 40 min
- Read
- 4 min
- Safety
- caution
Short answer
Restore something, do not just look at the log. Pick a folder you have not opened in months, restore it to a new location — never over the original — and open several files of different types, including a large photo or video. Check the newest file in the backup is from the last run, and that the backup includes the awkward things: email, a password vault export, application data. Repeat every six months and after any change to the setup.
Do this first
The failure people plan for is a drive that dies. The failure that happens is a backup that has been quietly not running since a software update in March. Testing is what separates the two, and it takes far less time than people assume.
Safety
Step by step
- Check the date of the most recent backup first.Not the schedule, the actual last successful run. If it is older than your interval, stop and fix that before anything else — this alone catches the most common failure.
- Check the newest file inside the backup.Browse the backup and find the most recently modified file. If the backup ran last night but the newest file inside it is from last year, the software is running and not capturing anything, which is a different and worse fault.
- Restore a folder to a new location.Create a folder called restore-test on the desktop and restore into it. Never restore over live data during a test; if the backup is damaged you want to discover that without losing the good copy.
- Open the restored files, several kinds.A document, a spreadsheet, a large photograph, a video, and something from an application's own data. Files can restore at the right size and still be unopenable, and only opening them proves anything.
- Confirm the size and the count roughly match.Compare the restored folder's size and file count with the original. A large discrepancy usually means an exclusion rule, a permissions failure, or a sync folder that was online-only and therefore had nothing local to back up.
- Check the awkward items from your inventory.Email store, password vault export, photo-editing catalogue, accounting file, hidden application-data folders. These are the ones a default backup selection misses, and a test that only checks Documents will not reveal it.
- Test the offsite copy too.It is the one you will need after a fire or a theft, and it is the one nobody checks. Restore a single folder from it. For an online service, time how long a modest folder takes so you have a realistic sense of a full restore.
- Write the date on the drive and in a note.A label on the drive with the last verified date, and a calendar reminder six months out. Verification decays; the note is what makes it recur.
Tips
- The single best test is unfair on purpose: pretend the computer is gone and try to get one specific document back using only the backup.
- If the backup software offers verification after writing, enable it. It roughly doubles the run time and catches media faults early.
- Keep at least two backup generations. A single copy overwritten each night will faithfully overwrite good data with corrupted data.
- Test after any change: new machine, new drive, new software version, new cloud service. Changes are when backups quietly break.
If it doesn't work
Backup reports success but contains almost nothing
Cause: The source is a cloud sync folder set to online-only, so the files are placeholders with no local content to copy — Fix: Set the folders you back up to always keep on this device, or point the backup at a genuinely local folder. This is a very common silent failure once a service switches on files-on-demand.
Backup has not run for months, no error shown
Cause: The destination drive has a different identifier after a reformat or enclosure change, or the scheduled task was disabled by an update — Fix: Reselect the destination in the software, run a manual backup, and confirm the completion date changes. Then set a reminder to check the date monthly.
Restored files open with errors or are zero bytes
Cause: The backup media is failing, or files were in use and captured mid-write — Fix: Test the destination drive's health, and prefer software that uses a snapshot so open files are captured consistently. Replace the drive if errors repeat — a backup on a failing drive is worse than none because it is trusted.
Restore is impossibly slow from the online service
Cause: Normal — domestic upload and download speeds make a full restore a multi-day job — Fix: Keep a local copy as the fast route and the online copy as the disaster route. Some services will post a drive for a fee; check whether yours does before you need it.
Files restore but permissions are wrong and nothing will open
Cause: Restoring to a different user account or a different machine without taking ownership — Fix: Restore to a folder inside your own user area, then take ownership of the folder if the system offers it. Avoid restoring system-owned locations.
Questions people ask
How often should I test?
Every six months for a household, and always after changing anything in the setup. Check the last-run date far more often than that — monthly is a good habit and takes seconds.
Is checking the log enough?
No. The log tells you the software did what it was configured to do. It cannot tell you the configuration was right, and misconfiguration is the usual fault.
Should I test a full system image restore?
Testing a whole image restore means wiping a machine, which most people will not do. A reasonable substitute is to boot the recovery media, confirm it starts and can see the backup, and browse the image to restore a single file.