A backup you have never restored from is just a hope. Here is how to run your first single-file restore, check your version history, and set a testing schedule you can keep.
A backup you have never restored from is a claim, not a guarantee. Backup software can report success every night while the copies behind it sit corrupted, incomplete or cut off from the keys needed to open them. The only way to know is to restore something and look at it. This guide walks through a first single-file restore, a check of your version history, and a testing routine simple enough to keep up.
Why an Untested Backup Isn’t a Backup Yet
A backup is a separate copy of a file or system kept in reserve in case the original is lost, stolen or destroyed. Recovery is the reverse operation: putting the copy back in place of the damaged original. Backup testing and recovery testing are different activities. Backup testing asks whether the copies were made and stored correctly. Recovery testing asks whether you can actually get your data back, and that is the question that matters on a bad day.
The gap between the two is where data gets lost. Damaged files, encryption keys nobody can find and system images that fail are among the reasons a backup job that ran without errors still cannot be restored. Testing exists to find those problems before an incident, not during one. A survey by the backup vendor Veeam found that, after a data-loss event, more than half of the businesses surveyed could not get everything back, and the usual causes were backups that were incomplete, set up the wrong way or damaged. Households hit the same failure modes: a sync app that quietly skipped a folder, an external drive that died in a drawer, an encryption password nobody wrote down.
The FTC’s guidance on protecting data covers both halves: save copies of important files in the cloud or on an external drive on a steady schedule, and put any recovery plan through regular tests instead of leaving it on paper. Ransomware adds another reason. Attackers often target the backups themselves so victims have nothing left to restore, which makes confirming your restore process part of resisting that attack, not an optional extra. Restoring is also a skill, and the first time you try should not be the day your drive dies.
Pick One File and Restore It Today
The single-file restore is the smallest useful test, and it is the right place to start. You are not trying to rebuild a computer. You are proving that one file can come back and that you know the steps.
Follow this sequence:
- Log in to your backup service directly through its app or website. Do not get there by clicking a link in an email, even one that looks official.
- Choose a file you know well: a photo you can picture from memory or a document you have read often. A familiar file makes problems obvious.
- Find the restore or download option and, if the service asks where to put the file, direct it to a new folder on your desktop called something like “restore-test” rather than over the original.
- Open the restored copy. The photo should display fully. The document should open without errors.
- Compare it with the original where you can. The contents, and ideally the file name, should match.
IT administrators run the same kind of test by redirecting a restore into a throwaway folder, and the approach works just as well at home. Note what you learn: where the restore option lives, how many steps it took, how long it ran. Restoring a file at random now and then is not a complete test, but it beats never testing, and it builds the familiarity you will want when something actually breaks.
Worth doing
Write down how long the restore took and how many steps it needed. That note becomes your baseline for how much a real recovery would cost you in time.
Checking How Far Back Your Version History Goes
Version history is the feature that keeps old copies of a file as you change it, so you can roll back to an earlier version. Retention is the related setting that decides how long those old copies survive. Both deserve a test of their own.
Plenty of cloud services clear out old backup versions on their own once those copies reach a set age, often at the 30-day or 90-day mark, unless you change the retention setting yourself. Some default to capturing changes only daily or weekly. That means a file you edited an hour before disaster struck may have no recoverable copy from those last few hours. It also means the older version you will want after a mistake may already be gone.
To check, pick a file you changed a few weeks ago and open its version history in your service. Count the versions, look at their dates, and restore one of the older copies to a new location to confirm it opens. If the list is shorter than you expected, look for a retention setting and read what it actually says.
Version history carries extra weight against ransomware, which can lock up both the files on your computer and the copies that sync to the cloud. In that situation, previous versions kept by your backup service may be your only clean copies. Scope matters here too. Desktop sync apps typically copy only the folders you have pointed them at, so files stored elsewhere on the drive may never be copied at all. Online office suites often keep mail, chats and documents inside their own platform instead of preserving them for the long term unless you set up separate retention. Knowing where your backup coverage ends is part of testing it.
When to Run a Full Restore Test
A full restore answers a question no smaller test can: if every device in the house failed tomorrow, could you get everything back? It is also the only test that shows how long a complete recovery takes.
| Test level | What you restore | What it proves |
|---|---|---|
| Single file | One document or photo into a test folder | The restore process works and you know the steps |
| One folder | A whole folder into a different location | Folders come back with names and structure intact |
| Full restore | Everything, onto a spare drive or a reset device | Your complete recovery works, and you learn the real time it takes |
Run a full restore at least once a year, and do it onto hardware you are not using for daily work so a mistake cannot overwrite your live files. During the test, confirm the contents are readable, not merely present: open files at random and check them against the originals. Watch the clock, too. A recovery that would take days when your household needs its files back by the weekend is a plan that fails in practice, and only a timed test reveals that.
Testing After Device and Plan Changes
Backup setups drift out of date whenever the things around them change. A new laptop, a new phone, an upgraded storage plan, a canceled subscription: each can quietly change what gets copied and what does not. After any of these changes, run the single-file test again from the affected device or account. It takes minutes and catches the most common problem, which is a backup that stopped covering something you assumed it still covered.
Plan changes deserve a closer look. Upgrades and downgrades can alter retention periods and how many versions are kept. If you are sizing up a plan, our guide to how much cloud storage you actually need can help you estimate the space your files require before you commit. Before you let any subscription lapse, find out what happens to the stored copies at the end of the term, since terms vary by provider.
Two cautions apply throughout. First, messages claiming you are out of storage are a common phishing lure. If the email names a company you do not use for cloud storage, that is the clearest sign it is a scam to report and delete. If you do use that company, skip the link and log in to your account directly to see whether the warning is real. Second, backing up to the cloud means storing files on somebody else’s server, so it is worth reading the provider’s privacy and security policies and favoring services that offer multi-factor authentication. If sensitive files are part of what you back up, our explainer on end-to-end encryption in cloud storage covers what that protection does and does not give you.
A Testing Schedule You Will Actually Keep
A schedule you will not follow is worse than a simpler one you will. Keep it small:
- Every month: restore one file to a test folder and open it. This takes about five minutes.
- Every three months: restore one folder to a different location and check what comes back.
- Once a year: run a full restore onto a spare drive or reset device, and time it.
- After any change: a new device, a new plan or a canceled plan calls for an immediate single-file test.
The FTC makes the same point for businesses: make backing up a habit, and test recovery plans instead of only writing them down. Its framework for managing cyber risk counts Recover among the core functions, and a recovery function only exists if the steps behind it have actually been exercised.
Keep a log. The date, what you restored, whether it worked and how long it took is enough, and a note on your phone qualifies. Over time the log turns vague reassurance into evidence, and it shows which parts of your setup deserve attention before a crashed drive finds the problem for you.
The first step is small: pick one file, restore it to a new folder, and open it. Do that today and you will know more about your backups than most people ever learn about theirs.
If you are still setting up, start with our timeline for setting up your first cloud backup, which spreads the work across manageable steps. And if your copies live on an external drive or a NAS instead of the cloud, our comparison of the two explains what changes for testing and what stays the same.
The essentials
- A backup is only proven when restored; damaged files, misplaced encryption keys or failed system images can make a successful backup job unusable.
- Start with a single-file restore into a test folder, then open the copy and compare it with the original.
- Many cloud services delete old versions after 30 or 90 days unless you adjust retention settings, so check how far back your version history goes.
- Retest after any new device, plan change or cancellation, and run a timed full restore onto a spare drive once a year.
- Keep a log of every restore test: the date, what you restored, whether it worked and how long it took.
Reader questions
How often should I test my backups?
Restore one file every month and one folder every three months, then run a full restore once a year. Also test right after changing devices, plans or backup settings.
Is a cloud sync folder the same as a backup?
Not quite. Desktop sync apps usually copy only the folders you connected them to, and some office suites keep data inside their own platform rather than retaining it long term unless you arrange that separately.
I got an email saying my cloud storage is full. Is it real?
It may be a phishing scam. If you do not use that company for cloud storage, report and delete it. If you do, skip the link and log in to your account directly to check.
Should I restore over my current files when testing?
No. Restore to a new test folder or a spare drive so a mistake during the test cannot overwrite your live files.
We describe how services generally work; features, settings and terms change often, and they differ between companies. This is general information, not legal advice. Check the provider’s current policies and official sources such as FTC.gov.