The backup report says the job finished. The useful follow-up is whether your team could recover the particular work it needs: the right file, from the right point in time, in a form someone can use.
Plan a small, supervised restore to an approved separate destination. Open the recovered sample with the intended application, compare it with the agreed expectation, and record exactly what the test proved. Keep the working original in place. Ask the person responsible for your backup service to choose the product-specific method and safeguards.
This is a routine planning exercise for a small business, including a dental or professional office. It is not an incident-recovery procedure or a test of every system in the business.
Start with a business task, not a green icon
A useful sample answers a practical question. Could your office recover an approved project document? Could the responsible employee open it with the application they normally use? Which saved point would they receive?
Choose a harmless demonstration file or an approved, appropriately protected sample. Write down its normal location, the application needed to open it and the content you expect to find. Avoid putting patient information, client records, passwords or license keys into a general test note.
The CISA #StopRansomware Guide recommends routinely checking backup availability and integrity through recovery testing. A small file exercise is one useful check; it does not replace the wider disaster-recovery testing your environment may need.
Agree these five things before anyone clicks Restore
- The sample and the question.
Name the file or supported item, its source location and the business task it represents. Ask the backup owner to confirm that the configured service actually protects that item.
- The saved point.
Record the recovery point and its time zone. Ask whether that point is available under the actual retention settings. Do not assume that a file present today was protected at the earlier date you need.
- The safe destination.
Have the responsible provider confirm where the recovered copy will go and who can access it. The method should keep it separate from the working original and avoid syncing a test copy over live work. If the product cannot safely support that test, agree another approved method before proceeding.
- The people and the window.
Name the authorized operator, the staff member who will check the result and the person who can stop the exercise. Agree a suitable time, the expected effect on normal work and an escalation contact.
- The acceptance check.
Define what the reviewer will open and compare. Decide how to record a pass, a failure or a blocked test, and how the separate test copy will be retained or removed under your approved process.
Do not delete a working file to make the test feel realistic. Do not format storage, disable protections or change retention settings as part of an improvised exercise. A missing prerequisite is a reason to pause and assign an owner.
Check the recovered work, not just the download
Ask the staff reviewer to open the recovered sample in its intended application. Compare the expected version and meaningful content. For a document, that might mean checking the agreed text and attachments. For a spreadsheet, the review might include the expected sheets and calculations, using harmless test content.
Record dependencies that the sample does not exercise. Recovering a document does not demonstrate that an accounting database, practice-management application, server or entire office can be restored. Those need their own vendor-supported recovery and acceptance plans. Do not restore a live application database over production to extend a file test.
If you measure elapsed time, record the test conditions as well. The duration of a small sample restore is not a promise about recovering a large folder, application or full system during an outage.
Leave a useful result for the next person
Use a short evidence note rather than a screenshot that says only “success.” Keep sensitive details in the approved support record, with access limited appropriately.
- Scope: sample reference, source location and task being checked.
- Recovery: backup or job reference, selected recovery point and time zone, authorized operator and separate destination.
- Review: application used, comparison performed and staff reviewer.
- Outcome: passed for this scope, failed, or blocked, with the actual limitation.
- Follow-up: action owner, agreed next check and handling of the test copy.
For example, a hypothetical design office might confirm that its sanitized estimate file opens from a selected recovery point. If a linked reference is missing, the result should name that gap. “Recovered the file; linked reference unresolved” is more useful than calling the whole backup plan verified.
Use the test to improve the plan
A blocked or failed sample is a decision to address, not something to hide. It may expose a question about coverage, an unavailable recovery point, access to the restore tools or who accepts the result. Have the responsible provider investigate the actual cause before changing the setup.
VFIX's backup and disaster recovery service page describes backup and restore planning. Book a consultation to discuss the data you need, your recovery priorities and a suitable sample test. Confirm the work and service scope in your proposal; a file exercise is not full-system recovery.
For the wider planning conversation, read Security incidents: plan before there's a problem.
Sources checked October 28, 2026, Pacific time. During a suspected compromise, follow your incident-response process and responsible provider's direction before restoring data.