Choose a file you know, such as a spreadsheet from last week. Find the backup or recovery service and pick a version whose contents you can recognize. Restore a copy to a separate folder you control so you can compare it without touching the current working file.

A backup report can tell you that a job finished. Only a restore shows that a person can find the instructions, sign in, pick the right date, and end up with a file that opens and holds what it should. NIST's Cybersecurity Framework 2.0 lists "Backups of data are created, protected, maintained, and tested" as one of its outcomes (PR.DS-11), and CISA's StopRansomware Guide tells organizations to regularly test the availability and integrity of backups in a disaster recovery scenario. Restoring one file is the smallest version of that test. It needs an authorized person, a file, a private folder, and somewhere to take notes.

Choose a file that proves something

A blank document can show that you can download a file. It will tell you very little about whether your backup contains the information you need. Pick a file with a detail you can check, such as a worksheet with a known entry from last week. If you are testing version history, choose a date before a known change and verify the old value in the copy.

A good test file meets most of these conditions:

  • It sits in a location the backup is supposed to protect, such as a shared library, a shared drive, or a synced Documents folder
  • It holds a detail you can confirm without guessing, such as a total, a client name, or a dated entry
  • It changed on a date you know, so you can ask for the version from before that change
  • It is a kind of file the business relies on, such as a spreadsheet, a PDF, or an export from your accounting software
  • Nobody needs to edit it while the test is running

Avoid testing on the original or putting sensitive data in an open folder. A sensitive file can still be a good test file if everyone running the test is already allowed to see it.

Know which safety net you are testing

A file kept in Microsoft 365 or Google Workspace can have more than one safety net. The service that holds the file keeps its own version history and a recycle bin or trash. A separate backup, if you have one, keeps copies somewhere else. Both are worth testing, but they answer different questions, so write down which one you used.

Version history is the quickest way to undo an edit, but it does not reach back forever. Microsoft lets administrators and site owners set version history limits for SharePoint libraries and OneDrive, and its documentation describes an Automatic setting and a manual setting that caps the number of major versions, with or without an expiration period. Versions that exceed a library's limits are permanently deleted without passing through the recycle bin.

Google Drive Help says a version of an uploaded file, such as a PDF or an image, might be permanently deleted after 30 days or once there are 100 newer versions, unless someone marked it Keep forever. For work or school accounts, Microsoft's help for Office files says the number of versions you can go back to depends on the library configuration. Ask whoever manages your Microsoft 365 or Google Workspace which limits apply, then test a version as old as the business expects to rely on, not just last week's.

Version history and the recycle bin also live inside the same service as the file, and Microsoft's documentation notes that users can delete versions from a file's version history. CISA warns that many ransomware variants try to find and delete or encrypt accessible backups, which is why its guide calls for offline, encrypted backups of critical data. A restore from the separate backup is the test that shows a usable copy exists outside the system that holds the file.

Administrative recovery has limits of its own. Google's Workspace admin help says an administrator can recover deleted Drive items within 25 days after a user empties their trash, but cannot restore individual files or folders. The restore brings back everything removed during the chosen date range, and the user has to reshare restored items before others can open them again.

Get an older copy without replacing the current file

Recovery tools often offer two different actions. One lets you open or copy an older version, and the other replaces the current file with it. For a test, you want the first. These are the controls named in the vendors' help pages:

  • In Word, Excel, or PowerPoint for Microsoft 365, with the file stored in OneDrive or SharePoint, click the file's title, select Version history, and select a version to open it in a separate window, then check it without selecting Restore
  • In a SharePoint library, view the earlier version from the file's version history rather than choosing Restore, because Microsoft says viewing does not overwrite the current version while a restored version becomes the new current version
  • In Google Docs, Sheets, or Slides, click Last edit at the top right, click More next to the version you want, choose Make a copy, pick the test folder, and leave Share it with the same people unselected
  • For a PDF, image, or other uploaded file in Google Drive, select the file, click More, then File information, then Manage versions, and choose More and then Download next to the version you want
  • On a Windows PC that uses File History, right-click the folder in File Explorer, choose Restore previous versions, and select a version, then either expand Open and choose Open in File History to look, or expand Restore and choose Restore to so the copy lands in your test folder
  • On a Mac or in a separate backup product, check where a restore will put the file before you start, and choose a download or a different destination if one is offered

Microsoft's File History page warns that a plain Restore replaces the current version on your computer and that the replacement can't be undone. That is the mistake to design out of the test.

A download lands on the computer you are using, so move it into the test folder instead of leaving it in Downloads. Where a tool opens the old version for viewing rather than saving a copy, check the detail there and note what you saw. You have still shown that the version exists without touching the current file.

Run the test in order

Work from the written restore instructions, not from memory. Good instructions cover:

  • Which service or backup holds the copy, and how to reach it
  • Which account signs in, and where its second sign-in step goes, without the password itself
  • How to pick a version or a date
  • Where restored files should go, and who can open that folder
  • Who to call if a step fails

Then run the test and keep notes as you go:

  • Write down the file, the version date you want, and the detail you expect to find in it
  • Confirm the tester has the access the steps need, such as edit permission on a Google Docs, Sheets, or Slides file, which Google's help says is required to browse earlier versions
  • Create or choose a test folder that only the people running the test can open
  • Start a timer when you begin looking for the instructions, not when you click the restore button
  • Follow the instructions as written, and note every point where you had to guess or ask someone
  • Retrieve the chosen version into the test folder, or open it for viewing if that is all the tool offers
  • Stop the timer once the copy is open and checked

The timer measures the whole recovery, not just the download. If the instructions live in one person's inbox, or the sign-in needs a code from a phone that only one person carries, the elapsed time will show it. Keep a copy of the instructions, without passwords, somewhere you could still reach if the main system were down, such as a printed page or a second location.

Check the result

Open the recovered copy in the app you normally use. Check its date and one or two details you recognize. NIST's framework lists a related outcome for real recoveries, that the integrity of backups is verified before they are used for restoration (RC.RP-03). If the file will not open, is missing data, or comes from a different date than you expected, record the problem and raise it with whoever manages the backup. Keep the restored copy in a location with the same privacy controls as the original.

The kind of failure tells you where to look:

  • The newest copy is older than expected, which suggests the backup has stopped capturing that location or is failing without anyone noticing
  • The version you wanted is gone, which often means retention or version limits are shorter than the business assumed
  • The file is not in the backup at all, which can mean its folder was never included
  • The copy opens but is damaged or incomplete, which calls for a second test on a different file before anyone relies on that backup
  • Nobody could sign in, which means recovery depends on an account or device the team cannot reach

Write down where you found the backup, which version you restored, how long it took, and whether someone else could follow the instructions. Put a date on the next test. If the team cannot find the restore instructions or sign in to the recovery service, fix that now while the original file is still available.

Make the result repeatable

Record the backup location, file name, version date, restore location, elapsed time, and result. A useful note might say that an authorized team member restored the Tuesday copy into a restricted test folder in seven minutes and verified the expected worksheet. If you could only complete the test because you happened to have an administrator's login, write that down as a dependency.

For the next round, ask a second authorized person to follow the instructions. Change one thing each time, such as the person, the location, or how far back the version goes, so that over several rounds you cover each place the business keeps files. When someone restores a file for a real reason, record it the same way, because that is evidence too.

A single file test is a starting point. Plan separate tests for applications, permissions, or larger folders that the business depends on. Permissions deserve attention because a file can come back without its sharing. Drive items an administrator restores have to be reshared, and a copy made from Google version history is shared with the same people only if you select that option.

A worked example

Imagine a twelve-person property management office that keeps its rent roll in an Excel workbook in a SharePoint library, with a separate backup service for Microsoft 365. On Tuesday the office manager changed one tenant's monthly rent from $1,450 to $1,500 and noted the change.

On Friday she runs the test. She writes down the file, Monday's date, and the old figure. In Excel she clicks the file's title, selects Version history, and opens Monday's version in a separate window without selecting Restore. The figure on that tenant's row reads $1,450, as expected. That part takes six minutes.

Next she tries the separate backup, because version history lives in the same service as the file and might not survive a compromised account. The plan is to restore Monday's copy of the workbook into a test folder that only she and the owner can open. The instructions name the backup portal, but the only account that can sign in belongs to the owner, and its sign-in code goes to the owner's phone. The owner is traveling, so the test stops at 25 minutes with a clear finding.

Her note records the file, the dates, the six-minute version-history check, and the blocked backup restore as a dependency on one person. The fixes are a second authorized account for the bookkeeper and an updated set of instructions. The retest goes on the calendar for the following month, with the bookkeeper following the steps and the office manager only watching.

What to do this week

  • Pick one file with a detail you can verify, and note the version date you want
  • Ask whoever manages Microsoft 365 or Google Workspace which version limits apply
  • Find the written restore instructions, or write them if they do not exist
  • Run the test into a restricted folder and time it from the first step
  • Record the result and any dependency on one person or one login
  • Put the next test on the calendar with a different person and a different location

Where ALCO can help

ALCO USA Inc is an IT services company headquartered in Caldwell, Idaho, with technicians serving businesses across Idaho. Its backup and disaster recovery service restores real files and systems on a schedule, times each restore, and records what worked and what did not. It also backs up mail, OneDrive, SharePoint, Drive, and shared drives outside the provider. The ALCO help desk is staffed 24 hours a day, including holidays, and calls are answered by a person.

Sources