AllTech
On this page
Field notes from the engineering team
Most organizations we talk to have backups. Far fewer can say when anyone last restored from them. The backup job shows a green check every night, so everyone assumes the data is safe.
A green check says the job finished. It does not say the data can be read, that it is complete, or that your team knows how to get it back at 2 a.m. during an outage. The only way to find that out is to restore something and see what happens.
This is a practical guide to doing that test: what to restore, what to check, and what to write down.
The short version
| Item | Detail |
|---|---|
| The test | Restore real data from the backup to a separate location, then open it and use it. |
| What a pass looks like | The data is complete, it opens, the people who own it confirm it is right, and the time it took is recorded. |
| How often | Our advice: a small restore every month, and a full system restore at least once a year. |
| Who should be in the room | The IT person or provider who runs the backup, and one person from the business who knows what the data should look like. |
| Why it matters now | Ransomware attackers go after backups. CISA tells organizations to test their backups regularly and to keep copies offline. |
What government guidance says
CISA’s #StopRansomware Guide, written with the MS-ISAC, NSA and FBI, tells organizations to maintain offline, encrypted backups of critical data and to regularly test the availability and integrity of those backups in a disaster recovery scenario. It adds that backups should be kept offline because many ransomware variants try to find and then delete or encrypt any backups they can reach, so that restoring is impossible unless the ransom is paid.
The same guide tells organizations that rely on a third party or managed service provider for their backups to make sure that provider follows the same practices, and to write the security requirements into the contract. So if someone else runs your backups, “have you tested a restore?” is a fair question to ask them, and you should expect a dated answer.
The guide also lists what attackers do to your recovery options. It names built-in Windows tools such as vssadmin.exe, wbadmin.exe, bcdedit.exe and wmic.exe and says misuse of them to remove shadow copies or change boot settings is a common technique to inhibit system recovery. Our reading: a snapshot stored on the same machine is not safe once an attacker has administrator rights.
Why a green check is not enough
A backup can report success and still fail you in several ways. These are common ways it happens:
- The wrong things are backed up. A new file share, a new database, or a second location was never added to the job. Nobody noticed because nothing failed.
- The backup is incomplete. Open files or locked databases were skipped, and the job logged a warning nobody read.
- The data is there but unusable. A database restores but will not start. A file restores but is corrupted.
- The credentials or keys are missing. The backup is encrypted and the key is stored on the server that just died. Or the restore needs an account whose password no one has.
- It takes far longer than anyone expected. The data is fine, but restoring it over your internet connection takes days, not hours.
- The copy can be reached by an attacker. The backup repository is a network share that the same admin account can delete.
None of these show up on a status dashboard. They show up when you restore.
How to run a restore test
1. Decide what to restore
Pick items that matter to the business, not a folder of old photos. A reasonable rotation:
- A handful of files from your main file share, including a few from a long time ago.
- One mailbox item or a shared mailbox, if you back up Microsoft 365.
- One application database, such as your practice management or accounting data.
- Once a year, a full server or workstation image, restored to a separate machine or virtual machine.
2. Restore to a separate place
Do not overwrite live data. Restore to a different folder, a test server, or an isolated virtual machine. This keeps the test safe and lets you compare the result to the original.
3. Check that it works, not that it exists
A restored file with the right name and size is not a pass. Open it. For a database, start the application against it and look up a record. For a server, boot it, sign in, and confirm the main service responds. Have the person who owns the data look at it. They will notice a missing last week of entries faster than IT will.
4. Time it
Write down how long each restore took, from the moment someone said “restore this” until the data was usable. That number is your real recovery time. It is often longer than the business assumed. Better to learn that now.
5. Record the result and fix what failed
Keep a short log: date, what was restored, who checked it, how long it took, and what went wrong. If something failed, fix the cause and test again. A failed test that gets fixed is a good outcome. That is why you run it.
Plan for the day the server room is gone
A file restore test tells you the backup works. It does not tell you whether you can rebuild. For the full picture, ask:
- Where is the recovery plan, and can you reach it when the network is down? The CISA guide says to keep network documentation and IT asset documentation as offline backups and hard copies. A plan stored only on the file server can get encrypted along with everything else.
- What gets restored first? The guide recommends restoring from offline, encrypted backups in order of critical services. Decide that order now, not during an outage.
- Is the backup clean? The guide warns that attackers often drop other malware to hide what they did, and says to identify such malware before rebuilding from backups so the compromise does not continue. Restoring into a network that is still infected just starts the problem again.
- Is there somewhere to restore to? If the hardware is gone or cannot be trusted, you need a place to restore. The guide suggests retaining backup hardware to rebuild systems when rebuilding the primary system is not preferred.
What to do
1. Ask for the last restore test date. Ask your IT provider or internal IT: “When did we last restore from backup, what did we restore, and how long did it take?” If the answer is a blank look, you have your first finding.
2. Make a list of what must come back first. Write down the top five systems or data sets the business cannot operate without, and the order you would restore them.
3. Schedule a monthly small restore and a yearly full restore. Put them on the calendar with an owner and a place to record the result.
4. Check that at least one copy cannot be changed or deleted. Our advice: one backup copy should be immutable or offline, so a stolen administrator account cannot erase it. This matches the CISA recommendation for offline backups.
5. Store the recovery plan and the encryption keys somewhere that survives the incident. Print the plan, and keep the keys outside the systems being backed up.
6. Check what your backup does not cover. Confirm that servers, workstations, and Microsoft 365 data are all in scope, and that new systems are added to the job when they go live.
How we help
Restore testing is part of our backup and disaster recovery service. We restore from your backups on a schedule, verify the result, and write down how long it took, so you have an answer before you need one. We also help set recovery priorities and keep a recovery plan that someone can follow when the network is down.
If an incident does happen, incident response covers confirming what was affected and making sure the environment is clean before data is restored, and if drives or servers fail outright, our data recovery service handles physical recovery work.
For law firms, healthcare practices and municipalities, a restore that takes days instead of hours can mean missed filings, closed offices, or services residents cannot reach. If you are not sure when your last restore test was, ask us and we will help you set one up.
