A backup restore drill you will actually run

Most companies have a backup. Far fewer have a restore. The difference shows up on the worst Tuesday of the year, when someone deletes a shared folder, a plugin update corrupts a database, or an account gets compromised, and the question changes from “do we have backups?” to “how long until Monday’s work is back, and from when?”

A restore drill is the answer to that question, asked in advance. Pick a thing, bring it back from backup, time it, and write down what happened. The version that survives in a small company is short, scheduled, and has one owner. This is that version.

Why “Completed” is not evidence

A backup dashboard reports that a job ran. It does not report that:

• The data inside is the data you need
• You have the credentials and access to bring it back
• The restore works in the order your systems require
• Anyone knows how long it takes
• The backup is not also encrypted with a key that left with a former employee

Each of those has bitten a company we have been called into. None showed up as a red badge. They showed up when someone tried.

We make the same point in our notes on MFA, logs, and restorable backups: a security program that nobody restores from is a brochure. This post is the practical follow-up, the calendar you can actually run.

Pick the scope in three tiers

You do not need to restore everything. You need a short list of things whose loss would hurt, and a few cheap proofs.

1. Proof restore (cheap). One file, one mailbox item, one small table. Low stakes, run often.
2. Business restore (meaningful). A whole shared library, a user’s full mailbox, the website and its database to a staging copy, a CRM export loaded into a test instance.
3. Disaster rehearsal (rare). Rebuild a critical system from nothing in a clean environment, with the documentation you really have.

The first tier protects the habit. The second proves you can recover what the business runs on. The third tells you whether your runbook is a document or a wish.

The cadence we recommend

For a company of ten to forty people, this works without becoming a job:

• Every two weeks (or weekly): one proof restore, 15 minutes
• Every quarter: one business restore, scheduled in a calm window
• After any tooling change: one extra restore, same week
• Once a year: the disaster rehearsal, or at least a tabletop walk-through of it

Put the dates in the calendar of a named person, plus a deputy. A drill that depends on “whenever things are quiet” will not run. Things are never quiet.

What to restore, by system

Make the list concrete. For a typical Montreal SME it looks like:

• Email and calendar. Recover a deleted item and a deleted shared mailbox message. Check retention settings.
• Files. Restore a previous version of a document and a deleted folder from the shared library.
• Website. Restore files and database to a staging copy and load the site. A host backup you have never opened is a rumour.
• CRM and forms. Restore or re-import a sample of records, as described in one system for site, CRM, and search.
• Servers or line-of-business software. Restore to a test machine or instance, not over production.
• Configuration. Can you re-create DNS, identity policies, and key settings from written notes or exports?

Always restore to somewhere harmless unless the drill is explicitly the real thing. “Restoring over production to see if it works” is how a drill becomes an incident.

Time it and write it down

The point of the drill is information. For each run, record:

1. Date, person, and what was restored
2. The backup point used (date and time)
3. Time from decision to usable data
4. What went wrong, however small
5. What you changed as a result
6. Who needs to know

Keep it in a plain page, not an app. The first entry will probably be uncomfortable: a missing permission, an expired credential, a retention period shorter than you assumed. Good. That is the problem you wanted to find on a calm afternoon.

From these entries you can state two numbers honestly: how far back you can go (recovery point) and how long it takes to be working again (recovery time). Leadership can then decide whether those numbers are acceptable. Without the drill, both are guesses.

Common findings

The same few things appear in most first drills:

• Backups exist for the primary system but not for the SaaS tool nobody thought of
• The restore needs an admin account that has since been removed, or a key no one has
• Retention is 30 days and the loss was discovered at day 45
• The backup includes data but not the settings, so the restored system looks wrong
• The restore works but takes a day and a half, and the business assumed a few hours
• Nobody wrote the steps down, so only one person can do it

Each one has a cheap fix once seen: add the SaaS tool, store the key properly, extend retention, export the configuration, document the steps. The expensive fix is finding out during an incident.

Keep it alive past the first quarter

Drills die in predictable ways. Prevent them:

• One owner and one deputy, named
• The calendar entry creates a ticket, and closing the ticket requires the log entry
• Review the log in a short monthly or quarterly meeting; unresolved findings carry forward
• Rotate which system gets the business restore, so each is tested at least yearly
• When someone joins or leaves, check that the drill still has the access it needs

If the drill takes more than an hour for a proof restore, shrink it. Drills that feel heavy get skipped.

How this fits with the rest

A restore drill is one loop of a wider routine: MFA where it belongs, logs a human reads, and recovery tested on a date. If you want someone to run that routine day to day, hands-off IT in Montreal is how we do it, with the drill log as part of what we hand you.

What to send us

If you are not sure where to start, send a short list of the systems that would hurt to lose, where each is backed up, and the date of the last restore you remember. We reply on weekdays, 9 to 17 ET, at hello@aervio.io or +1 438-498-3913. We will tell you which two drills to run first, and how long each should take. Our alerting and hardening work includes setting up and running this calendar for you.

Questions

How often should we test a restore?

A small restore weekly or every two weeks, a meaningful one quarterly, and an extra one after any change to backup tooling, hosting, or retention. The rhythm matters less than the fact that it is on a calendar with an owner.

What should we restore first?

Something unimportant but real: one mailbox item, one file from a shared library, one table from a database. That proves the pipeline end to end without risking anything, and it builds the habit.

Do cloud services like Microsoft 365 or our host back up for us?

Providers protect their platform, not necessarily your data from deletion, overwrites, or a compromised account. Check retention and recovery options yourself, and test what you can actually bring back, and how fast.