A successful job and a successful recovery are different things

Backup software usually reports whether a scheduled operation ran and stored data. A recovery test asks a harder question: can you retrieve the right information, rebuild the services that depend on it, and get employees working again?

CISA recommends testing both partial and full restorations. That matters because a backup can be incomplete, unreadable, missing an application dependency, or stored somewhere that is also affected by the original incident.

Step 1: Identify what must be recoverable

Start with a business inventory, not a list of hard drives. Important items may include shared files, an accounting database, a local production application, Microsoft 365 data, server configuration, firewall settings, and the credentials needed to restore them.

Ask the people doing the work what they would need on the first day after a failure. Backing up a file server while overlooking the database behind the invoicing application can leave the business effectively offline.

Step 2: Review the actual backup jobs

For every protected system, record the backup product, schedule, destination, retention policy, encryption and access controls, alert recipient, and the most recent successful run.

Look beyond the latest result. Repeated warnings, growing durations, skipped machines, expired credentials, or a destination nearly out of space are reasons to investigate.

Step 3: Run a small restore test

Choose a non-sensitive file that changed recently. Restore it to a separate location, open it, and confirm that it contains the expected version. For an application, restoring a database file is not the same as proving the application can use it. Test the actual recovery workflow when feasible.

Avoid overwriting live production data during a test. Use an isolated location or recovery environment and document the steps.

Step 4: Test a larger failure scenario

A full server restoration might require different hardware, a virtual machine, network changes, encryption keys, or vendor assistance. Test a representative scenario that includes the application's dependencies rather than stopping at a boot screen.

Measure how long the recovery takes and note which manual steps require specific people. A recovery plan that only works when one employee is present is fragile.

Step 5: Protect the backups themselves

If ransomware or a compromised administrator can delete both production data and every backup copy, the backup design has a shared weakness. Consider separate credentials, restricted administrative access, and offline or immutable copies where appropriate. An offsite copy can also reduce exposure to local theft, fire, or equipment damage.

There is no universal product or retention schedule that covers every business. The right arrangement depends on the data, threats, storage cost, and ability to restore.

Step 6: Define acceptable loss and downtime

Two useful terms help frame expectations:

  • Recovery Point Objective (RPO): How much recently changed data the business can afford to lose. If losing an afternoon of orders is unacceptable, an overnight backup may not be enough.
  • Recovery Time Objective (RTO): How long the business can tolerate an unavailable system. A fast backup does not necessarily mean a fast restore.

Set these targets with the business owner, then test whether the backup process can realistically meet them.

What about files in Microsoft 365?

OneDrive and SharePoint offer useful retention, versioning, recycle-bin, and recovery features. Their availability and limits depend on configuration and policies. These features are not the same as reviewing your complete recovery requirements, especially for long-term retention, administrator compromise, or complex accidental changes. Evaluate whether a separate backup solution is warranted for your data and risk tolerance.

Keep evidence of every test

Write down the date, protected system, restore point, destination, outcome, elapsed time, and corrective actions. If a test fails, record the cause and retest after the fix. A short, repeatable checklist is more valuable than an impressive plan nobody has exercised.

Bottom line: The question is not “Are backups running?” It is “Can we restore the information and systems this business needs, within the time it can tolerate?”