Ask most business owners whether they have backups and they say yes. Ask when they last restored one, and the room gets quiet. The painful truth about ransomware recovery is that many organizations discover their backups are incomplete, outdated, or unusable only when they need them.
A restore drill is a scheduled, low-drama test that answers the question before an emergency does. It does not require a big budget, only a calendar reminder and some discipline.
What can go wrong with backups
Backups fail in ordinary ways:
- A job silently stopped running months ago.
- Key data was never included, such as a database, a file server share, or a laptop with the estimating files.
- The backup is intact but takes far longer to restore than anyone assumed.
- Backups were stored where ransomware could reach and encrypt them.
- No one knows the credentials or encryption key needed to restore.
- Software licenses and configuration were not captured, so servers cannot be rebuilt.
Each of these is easy to find during a drill and very expensive to find during an attack.
Step 1: Decide what you must recover first
Make a short list of systems ranked by how quickly the business needs them. For a contractor this might look like:
- Email and phone access, so people can communicate.
- Accounting and payroll, so you can pay people and bill.
- Project management and document repositories.
- Estimating and bid files.
- Everything else.
For each, write down two numbers in plain terms: how much data loss you can tolerate (for example, a day of work) and how long you can be without it. These targets drive how often you back up and how you restore.
Step 2: Run a file-level restore
The easiest test is also the most common need. Choose a few files at random from different folders, including some from a few weeks ago, and restore them to a separate location. Confirm they open correctly. Time the process and note who did it.
Step 3: Restore a full system
Quarterly or twice a year, restore an entire server or application into an isolated test environment, not over production. This tests whether the backup is complete, how long recovery really takes, and whether your documentation is accurate. If your accounting database is critical, restore it and have someone from finance verify that recent transactions are present.
Step 4: Test the worst case
Ask directly: if our main network and our main backup console were both unavailable, how would we recover? Confirm that at least one copy is offline, immutable, or otherwise protected from tampering with stolen administrator credentials. Check that the people needed to run the recovery can reach the instructions without the systems that are down. Printed or offline copies of the recovery plan, key contacts, and credentials for backup systems are worth having.
Step 5: Write down what you learned
Record the date, what was restored, how long it took, and what broke. Convert every problem into a task with an owner and a date. A drill that finds nothing wrong deserves a little skepticism: widen the test next time.
A simple schedule
- Monthly: Review backup reports for failures and spot-check a few files.
- Quarterly: Restore a full server or key application in a test environment.
- Annually: Run a tabletop exercise simulating ransomware and walk through who does what.
Include cloud and field data
Do not forget laptops, jobsite devices, and cloud services. Data in cloud applications is not automatically backed up in a way you can restore on your terms, and field devices often hold the only copy of recent work. Confirm that each is covered or deliberately excluded.
Getting help
Ironfield Cyber designs and tests backup and recovery for contractors and energy companies, including recovery time targets and offline copies. If you cannot remember your last restore, we can run the first drill with you.