Test a backup by restoring selected file versions to a separate location, checking their contents and measuring recovery time without risking your live work.
Direct answer: Restore a small, representative set of files and older versions to a separate test location, then open them and verify the content you would actually need. Record the time from starting recovery to having usable work, including finding the right version and obtaining access. Do not overwrite the current originals during the rehearsal; a successful backup notification is not a substitute for a successful, non-destructive restore.
A backup can exist without answering the question that matters in a stressful moment: can you recover the right version soon enough to continue? The file might be missing, the retained version might be too recent, or an application dependency might prevent it opening usefully.
Testing those conditions now is more useful than discovering them after accidental deletion. This is a narrow reliability check within getting more from the technology you already own, not an invitation to replace a working backup product without evidence.
Applies to: file-level backup verification, with a Windows File History example for Windows 11. Other services have different restore and retention controls. Instructions are based on documentation; no backup system was tested for this article.
Use the non-destructive restore rehearsal
The non-destructive restore rehearsal is an editorial method that separates retrieval, version correctness, openability and time to useful work. It deliberately avoids replacing the live file so that the test does not create the loss it is meant to prepare for.
Choose a quiet period and save active work. Confirm you have permission to access the backed-up information, a safe destination with enough space and the relevant application to inspect it. If the backup is encrypted, establish legitimate access to its key or recovery method without exposing it in screenshots or notes.
Do not format the backup drive, reinitialise the backup set or accept a prompt to replace existing data just to begin a test. If the application cannot find the backup, stop and investigate the documented import or recovery route. A new empty backup is not a successful recovery of the old one.
Use the existing trusted tool and source. Do not upload a confidential backup to an unknown “repair” website. Restored copies need the same access protection as the live material, even when their filenames include the word test.
Choose files that represent your risks
Select examples from the work you would genuinely miss, including different file types and locations. A document, an image and a spreadsheet can reveal different failures. Include a recent file and an older version containing a known earlier detail.
For each example, write down a checkable expectation before recovery. A report should contain a named section; an image should have the expected dimensions and visible content; a spreadsheet should contain the required sheets, formulas and a known total. Do not use only file size or the fact that an icon appears.
Choose versions around a meaningful change. If you need protection from accidentally replacing yesterday's work, recovering only the current version proves too little. Check whether the retained history reaches the point before the unwanted change would have occurred.
A small sample does not certify the entire backup. Its purpose is to find failure modes and establish a workable process. Expand testing when the sample exposes missing locations, unsupported file types or inconsistent retention.
Restore to a separate destination
Create a clearly named test destination outside the live working folder. Confirm the path in the restore dialogue before proceeding. If the location is automatically synchronised or shared, choose an approved alternative so you do not distribute older confidential copies unintentionally.
For Windows File History, Microsoft documents opening the folder's Restore previous versions, selecting the relevant version and using Open in File History to preview it. To avoid replacing the current version, expand Restore and choose Restore to..., then select the separate destination. See Microsoft's File History restore guidance.
The same guidance warns that restoring over the current file replaces it and cannot be undone through that operation. That is why the destination check belongs before the button press. If your screen lacks the documented option, do not guess which control is equivalent; check the tool and version or obtain support.
Do not assume that starting File History today gives you older versions from before it was configured. The test must examine versions that actually exist in the chosen backup set.
Check whether the restored file is useful
Open the restored copy from its test folder, not the original from a recent-files shortcut. Check the title bar or path where necessary so you know which copy you are inspecting. Otherwise you can accidentally congratulate the live file for opening and never test the restore.
Compare the expected details you recorded. For a spreadsheet, inspect the relevant formulas as well as visible values. For a project file, check whether linked media or supporting files are available. A project opening with missing dependencies may be recoverable, but it is not yet ready for work.
Separate these outcomes:
| Result | What it establishes | Next action |
|---|---|---|
| Correct version opens with required content | This sampled item passes | Record the process and time |
| File opens but contains the wrong revision | Retrieval works, history selection does not meet the need | Check retained dates and version selection |
| File exists but cannot open usefully | Copy presence is insufficient | Investigate format, application and dependencies |
| File or location is absent | Coverage is incomplete for this item | Correct backup scope and repeat a later test |
If you compare checksums, remember what that proves. A matching digest can establish matching bytes between two copies, but it does not establish that the source version was correct or that the file contains the material you intended to preserve. Content and recovery need their own checks.
Measure a complete recovery, not just copying
Record the start when you begin finding the backup and the finish when the required file is usable. Include connecting the drive, authenticating, locating the version, restoring and opening the result. Exclude unrelated breaks, but state what you excluded.
Consider an illustrative writer's test with three file types and four saved versions of each, producing 3 × 4 = 12 restored items. All figures are invented for explanation, not observed backup performance.
Locating the backup takes four minutes, obtaining authorised access takes three, finding the versions takes six, copying takes five and checking their contents takes twelve. Total recovery effort is 4 + 3 + 6 + 5 + 12 = 30 minutes.
If the writer's next meeting requires the recovered material within an illustrative 45 minutes, the tested process leaves 45 − 30 = 15 minutes of margin under these assumptions. It does not prove recovery will always fit: a missing drive, unavailable account recovery or a larger set can change the result.
Suppose 11 items pass and one spreadsheet opens without a required linked file. The result is not “92% safe”. It is one unresolved dependency that may defeat the specific task. Add the dependency to the backup plan, make a new backup and repeat that recovery case.
Keep setup and maintenance visible. If preparing the test takes fifteen minutes in addition to the 30-minute rehearsal, your total review session is 45 minutes. That is time invested in evidence, not cash saved or a measured reduction in the probability of data loss.
Decide whether the backup earns your reliance
My recommendation is to test one realistic restore before relying on a newly configured backup, and repeat after material changes to storage, accounts or applications. A dashboard success message is useful operational information, but it cannot answer whether a particular old version is usable.
Do not make the test larger merely to create an impressive count. Prioritise files with consequential contents, awkward dependencies or a history requirement. If your whole business depends on rapid recovery, involve a qualified specialist to design a broader recovery exercise rather than treating this file-level rehearsal as a complete disaster-recovery plan.
Run the first rehearsal this week
- Set aside about 45 minutes, identify the needed recovery timeframe and choose a small set of representative versions.
- Record expected contents and the separate restore destination before opening the recovery tool.
- Restore, open and verify the copies, timing the entire route to usable work.
- Fix one identified gap and repeat that case after a new backup. Retain the original files and backup set throughout. Stop if a prompt risks overwriting live data or the only backup; seek help before proceeding.
Related guides
Frequently asked questions
Does a backup marked successful mean every file is recoverable?
No. The status usually concerns the operation reported by the tool, not a proof that every file you care about is included, correctly versioned and useful when opened. Check the intended locations and test representative recoveries. A successful run can still leave a gap if a needed folder was outside the configured scope or a linked dependency was not included. Do not ignore the status, but pair it with evidence from an actual restore. If the tool reports errors, resolve them before treating an unrelated successful sample as reassurance about the missing or failed items.
Can I test by deleting a live file and restoring it?
You usually do not need to take that risk for an initial file-level rehearsal. Restore a selected backup version into a separate destination and check it without touching the live original. If a later exercise genuinely needs to simulate deletion, use a deliberately created test file and a clearly bounded plan, not your only copy of important work. Keep the recovery evidence and permissions explicit. A backup test should reveal problems while you still have options; making real work unavailable first can turn an avoidable testing mistake into an urgent recovery incident.
How far back should the version I test be?
Choose a version that matches the kind of mistake you need to recover from. If you might notice an accidental change after several days, testing only the most recent copy is insufficient. Determine what history your actual backup retains and select a known earlier state within it. Do not assume that a long-running subscription automatically provides indefinite versions. If the required period is missing, adjust the plan before relying on it. The right history is a decision about your work and discovery delays, not a universal number that every household or team should adopt.
What if the restored document opens but its linked files are missing?
Treat it as an incomplete recovery for any task that needs those links. Identify the specific missing dependency and whether it was outside the backup scope, stored in another account or dependent on an application service. Restore the supporting material to an appropriate separate test location and follow the application's documented relinking process. Do not rewrite the live project to hide the warning during the rehearsal. Once the dependency is included in a new backup, repeat the test. A project icon and an open window are not sufficient evidence that another working session can continue successfully.
Is cloud synchronisation the same as a tested backup?
Do not assume so. A synchronised copy may be useful, but you need to check the service's actual version, deletion and recovery behaviour for your account and configuration. The relevant question is whether it can return the required state after the kind of mistake you are planning for. Apply the same separate-destination and content checks where supported. If a service offers recovery controls, verify their current limits rather than borrowing another provider's terms. Simply seeing the file on a second device proves that a copy is visible there, not that the older state you need remains recoverable.
What should I do with the test copies afterwards?
Keep them until you have recorded the result and resolved any discrepancy, then remove only the clearly identified disposable test material according to your information-handling rules. Verify the path before deletion so you do not remove the original or backup set. Test copies may contain the same confidential information as live documents, so do not leave them in an open shared folder. Record the selected versions, checks performed and unresolved issues without embedding sensitive file contents or recovery secrets in the report. The evidence should support the next rehearsal without creating an unnecessary new collection of exposed data.
Sources and verification
- Microsoft: backup and restore with File History, checked 11 September 2026 for preview, separate-destination restoration and overwrite consequences on Windows.
This article is practical guidance. Apply it in proportion to your tools, evidence, risks, and responsibilities.
