Last time I covered the first thing I check on an unfamiliar network: the firewall. This time it's the second: the backups, and how to test that they actually work. And the first question isn't "what's being backed up?" It's when was the last time someone actually tested that these backups work in a simulated disaster recovery scenario, and when's the next test scheduled?
Here's why that comes first: who cares what's being backed up if nobody knows whether the backups actually work? A backup that has never been restored is just a hope. The software can show green checkmarks every night for three years, and you still don't know whether you can get the business back until you try. The second half of the question matters too. A test that happened once is an anecdote. A test on the calendar is a process.
How to check if your backups actually work
How I actually check it: I ask leadership first, then look for any local documentation, if it exists. If I'm taking over from another admin, I ask them directly. But if I've walked into a brand-new environment that nobody supports and nobody really understands, I don't waste time hunting. I safely assume there has never been a test, and I move straight to inventorying what's there:
What's being backed up. Save this list. Later, when you inventory the servers, VMs, and high-value workstations, you'll compare against it to find what's missing.
Where the backups are stored.
Whether the setup follows 3-2-1 (more on that below).
Errors in the backup software: both current failures and the history of quietly failing jobs nobody noticed.
Whether the backup software is up to date.
Whether the host OS is up to date.
Retention policies. How far back you can restore is a business call, not an IT default, so this one becomes a conversation with management.
The companion spreadsheet has a tab for each of these, with space to record what you find. It's free for subscribers; the download box is at the end of this article.
What to do if your backups have never been tested
What I do if it's never been tested: triage, not panic. The fix isn't just "go run a test." It's building the pieces that make a test (and a real disaster) survivable.
The test itself depends on the environment and the resources you have, but the minimum is restoring into an isolated network and having the stakeholders confirm the system actually works. Then they sign off on it. That sign-off matters: it gives the business owners skin in the game, the same way the scream test does in Part 1. IT doesn't get to declare a restore successful; the people who use the system do. Document the full test restore process while you're at it, so the next test, or the real thing, doesn't start from scratch.
Around that test, a proper backup strategy needs five things:
Tests scheduled on the calendar, not "when we get around to it."
An offline copy of how to restore. If your restore runbook lives on the file server you're trying to restore, or in a SharePoint site behind the identity system that's down, you don't have a runbook.
A checklist of who owns each business app you're restoring, so you can keep them updated during the restore and have them verify it afterward.
A plan for reaching people during a DR event: who to contact, in what order, and how, when email and Teams may be part of what's down. Personal cell numbers, on paper, somewhere outside the environment.
A named backup person: a trusted contractor, an MSP on a small retainer, or a peer at another company who knows where the runbook lives and could run a restore if you can't. As the only IT person, you are the backup system's single point of failure until someone else can use it.
How often should you test backups?
There's no single magic number. NIST's contingency planning guidance treats once a year as the floor and expects more for high-impact systems. Here's the cadence I'd start with and adjust to your environment:
Every day: backup job monitoring and alerts that go to someone who actually reads them, ideally a shared mailbox plus a second person, so a failed job doesn't sit unread in your inbox while you're on vacation. If your software can automatically verify that backups boot or mount, turn that on.
Every month: spot-check restores. Pull back a random handful of files, a mailbox, a database. Small, fast, and it proves the data is actually there.
Every quarter: a full restore of your critical systems into an isolated network, with stakeholder sign-off.
Every year: a full DR exercise: the whole plan, not just the data. Runbook, contact tree, a tabletop walkthrough with leadership, and the test restores together.
After any major change: new server, new backup hardware, a big application upgrade, or a key person leaving. Don't wait for the next scheduled test to find out the change broke something.
How to secure backup credentials
Second, I find out where the backup credentials live and who has access to them. What I usually find is a spreadsheet saved in someone's My Documents folder. If that's what you find, change it as soon as possible. Good looks like this:
The credentials live in a password vault, and the vault has MFA. CISA's ransomware guidance calls for phishing-resistant MFA on accounts that access critical systems, and for escalating to senior management when a system doesn't support or enforce it.
The backup system has its own credentials, not domain admin, and not reused anywhere else.
The backup server isn't joined to the production domain. Veeam's own built-in security analyzer flags this. Its guidance: a separate management forest for larger environments, a separate workgroup for small and medium ones.
Access is audited, and credentials are rotated whenever an admin, employee, or MSP leaves.
A break-glass copy is stored offline, so you can still get in if the vault is unreachable during a disaster.
Here's the question that makes all of this matter: if an attacker got domain admin, could they log in and delete your backups? If the backup server is domain-joined and shares credentials with production, the answer is usually yes. And that's not theoretical: many ransomware variants deliberately hunt down and delete or encrypt any backups they can reach, so the ransom becomes the only way back.
How to harden the backup server
Third, I check how secure the backup box itself is, and when it was last updated. This is the firewall question from Part 1, aimed at a different device. The backup server should be its own box, not a VM sitting on the same production Hyper-V host it's protecting. It should be segregated from the rest of the environment with its own credentials, and both the host OS and the backup software should be fully patched. Beyond that:
Give it one role only. It isn't also the file server, the WSUS box, or anything else.
Don't RDP into it for daily work. Use the backup console from a management machine, and only log on to the box itself for upgrades and patching.
Don't forget iLO or iDRAC if the server has it. Out-of-band management is a full back door to the box, with power control, console access, and virtual media. Keep it off any internet-facing network, ideally on its own management VLAN. Change the default credentials, keep the firmware current, and turn off anything you don't use.
The 3-2-1 backup rule on a small-business budget
Fourth, I check retention and whether there's an offsite or immutable copy (the 3-2-1 rule): three copies of your data, on two different types of media, with one copy offsite. Current guidance stretches that to 3-2-1-1-0: add one copy that's offline or immutable (it can't be changed or deleted, even by an admin account), and zero errors, meaning you've verified the backups actually restore instead of trusting a green checkmark. The most common failure I find here isn't a misconfigured retention policy. It's a complete lack of backups.
How you meet 3-2-1 is going to be dictated by your budget, and that's fine. At my 9-to-5, I started with a group of external drives. I'd back up to them, then rotate them out and take them home. Not glamorous, but it's offsite and offline. If you do this, encrypt the drives: a backup drive in the back seat of your car is also a data breach waiting to happen. CISA's guidance specifically calls for offline encrypted backups.
Later, I moved to recycled hardware: an old server retired from production became the backup box, with new drives, and another old server became a hardened Linux Veeam repository. A hardened repository makes backups immutable for a set period (they can't be moved, changed, or deleted during that window), and it's set up with single-use credentials that aren't stored in the backup infrastructure, so even a compromised backup server can't log in to it. One caveat: only recycle hardware you can keep patched. An old box running an unsupported OS isn't a hardened repository; it's just another vulnerable server.
Backing up Microsoft 365 and other cloud data
Fifth, I check what's protecting the cloud data. Microsoft 365, Google Workspace and other cloud services keep the service running, but that isn't the same as a backup you control. Deleted mailboxes, overwritten files and a compromised admin account can all mean permanent data loss once the retention window passes. Find out what your provider actually keeps, for how long, and what you can restore on your own. If that isn't good enough for your Tier 1 data, add a third-party backup for it. (Check the provider's current retention documentation before relying on any default; they change.)
How to talk to management about backups (RTO, RPO and retention)
Before that conversation, sort every system into three tiers:
Tier 1, business stops: the line-of-business database, file server, email or identity. Backed up most often, tested most often.
Tier 2, painful but survivable: secondary apps, print and utility servers.
Tier 3, rebuild from scratch: anything you can reinstall in an afternoon.
That ranking turns "I need money for backups" into "here's what we lose and how long it takes to get it back," which is the version leadership actually funds.
Before you change anything, take your inventory findings to leadership. These are business decisions, not IT decisions, and every answer, including "we're not funding that right now," should be written down with who made the call:
Recovery time (RTO): for each critical system, how long can the business be without it?
Data loss (RPO): how many hours or days of data can we afford to lose per system?
Retention: how far back do we need to restore? Any legal, regulatory, or contractual requirements?
Budget: what's approved for backup hardware, software, and offsite/immutable storage?
Testing cadence: approve the schedule above so it's on the calendar, not optional.
Sign-off: who signs off that each restored business app actually works?
Declaring a disaster: who's authorized to declare a DR event and approve emergency spending?
Cyber insurance: do we have it, does it cover incident response, and what are the notification requirements and approved vendors? (Same question as Part 1: acting before notifying the insurer can void coverage.)
Insurance evidence: does the insurer want proof of restore tests at renewal?
Out-of-band contacts: approve collecting personal cell numbers for the DR contact tree.
Offsite storage: approve where offsite copies live: cloud, second site, or encrypted drives taken offsite.
Notification obligations: who must we notify in a data loss or breach: customers, regulators, partners?
Known gaps: accept or fund each gap you found. Unfunded risk should be a documented leadership decision, not an IT secret.
Disaster recovery (DR) test checklist
So you're not figuring it out from scratch every time:
Before the test
Test is on the calendar, and leadership and app owners know the window
Systems in scope are chosen (rotate through all critical systems over the year)
Isolated test network is ready, so restored systems can't collide with production (duplicate names, IPs, or a restored DC talking to the live domain)
App owners are lined up to verify and sign off
Offline runbook is printed or available outside the environment, and you're working from it, not from memory
Target restore times (RTO) are written down so you can measure against them
During the test
Restore from the backups as they actually exist, including the offsite or immutable copy at least once a year
Time every step
Note every place the runbook was wrong, vague, or missing a step (passwords nobody had, service accounts, license keys, install media)
App owners confirm the system actually works, not just that it boots
Get written sign-off from each app owner
After the test
Record the results in your DR test log: date, systems, time to restore, pass/fail, sign-off, issues
Tear down the test environment so restored copies don't linger on the network
Schedule the next test before you close this one out
Review and update the DR process
Update the runbook with every fix and gap found during the test
Print or export a fresh offline copy and replace the old one
Confirm the app-owner checklist still matches who actually owns each system
Review whether RTO/RPO targets were met. If not, take that back to management
Verify the out-of-band contact tree
Call or text every number on the list. Don't assume
Remove people who've left; add new owners, vendors, and the insurer's hotline
Confirm everyone has a current copy outside the company environment
Backup box health check (at least yearly)
Still hardened per the "Third" section above: one role only, no RDP for daily work, iLO/iDRAC locked down and patched
Backup software and host OS are current
Free space on protected servers and backup repositories is monitored
What untested backups cost
I learned the test-the-restore lesson by watching what happens when nobody does. At a previous employer, a mission-critical reporting server went down. It tracked time spent with patients so the organization could bill insurance, which meant it generated new data every single day, and nobody had accounted for that growth. The server ran out of disk space, which left no room for the swap file, and that caused the backups to fail. Nobody had ever tested a restore, so nobody knew. When the server crashed and we needed it back, the backups couldn't restore it. It took two server techs about two months to recreate that VM, using a lot of hacky techniques to recover the data. One test restore, or one look at the job errors, would have caught it. Instead, it cost months of skilled labor on a system the business couldn't bill without.
That's the cost of untested backups. Here's the cost of not having real ones at all.
Years ago, a small business owner contacted me to help protect his company from hackers. This was when ransomware seemed to be every other news story. He ran a tool business that had been around for 30 years and had moved mostly to online sales over the previous five. After discovery, I found his entire IT environment was out of date: end-of-life equipment with known exploits, roughly $25k worth of updates needed, plus about $5k for a proper backup setup. He said it was too much.
About a year later he called me again. He'd been hit with ransomware and wanted to know if I could recover his data. Of course, I couldn't. There was nothing to recover from. He refused to pay the attackers, and he lost the business. It was a million-dollar-a-year company, gone over a roughly $30k fix.
That story is why backups are the second thing I check, right after the firewall. The firewall and your patch levels are how you keep attackers out. Backups are what save you when that fails. He had neither: the out-of-date equipment let them in, and the missing backups made sure he couldn't come back. Check the door first, then check that you can survive if someone gets through it anyway.
Write it down: runbooks from this part
Add these to the runbook list you started in Part 1. Part 7 shows how to turn each one into a step-by-step guide, with a free template.
Restore a single file or folder (the one you'll use most).
Restore a full server or virtual machine.
Check last night's backups, and what to do when one fails.
Keep a printed copy of the restore runbooks somewhere other than the backup server. If the server is gone, so is the runbook stored on it.
Get the free Backup Health Review spreadsheet
Subscribers get the companion spreadsheet for this article: a tab for each check above, plus a DR test log and a contact tree for when email is down. Subscribe free and it's yours, along with a new checklist with every issue.
Backup testing FAQ
How often should you test backups?
Check backup alerts daily, spot-check restores monthly, do a full restore of critical systems quarterly, and run a full disaster recovery exercise once a year. Test again after any major change.
What is the 3-2-1 backup rule?
Keep three copies of your data, on two different types of media, with one copy offsite. Many people now add one immutable or offline copy and zero errors on restore tests (3-2-1-1-0).
Does Microsoft 365 back up my data?
Microsoft keeps the service running, but that isn't the same as a backup of your data. Deleted or encrypted mail and files can still be lost, so cloud data needs its own backup.
What's the difference between RTO and RPO?
RTO (recovery time objective) is how long the business can be without a system. RPO (recovery point objective) is how much data, measured in time, the business can afford to lose. Both are leadership decisions, not IT defaults.
Appendix: Where I actually check this
Companion spreadsheet: Backup Health Review: free for subscribers (see the download box above). Tabs for backup inventory, backup infrastructure review, 3-2-1 and retention (with an automatic "meets 3-2-1?" check), the management conversation, a DR test log, and an out-of-band contact tree. Fill in the yellow cells.
CISA: #StopRansomware Guide: the federal baseline for backups: offline encrypted copies, testing in a DR scenario, and keeping a hard copy of your plan.
CISA: I've Been Hit by Ransomware: the response checklist from Part 1. Print it and keep it with your offline restore runbook.
Veeam: Security & Compliance Analyzer: if you run Veeam, this built-in check flags common problems like a domain-joined backup server, missing security updates, or the configuration backup stored on the backup server itself. Run it on day one.
Veeam: Hardened Repository: how immutable Linux repositories and single-use credentials work, if you're building the setup above.
Your backup vendor's hardening guide: not on Veeam? Every major backup product publishes one. Start there, the same way you'd start with the vendor's advisory page for a firewall.
HPE iLO / Dell iDRAC security advisories: check out-of-band management firmware the same way you check firewall firmware: exact version against the vendor's advisories and NVD.
