Most organizations believe they have a ransomware recovery plan because they have database backups. That belief is dangerous — and incomplete.
A database backup recovers your data. It does not recover your server. When ransomware hits, it does not just encrypt files — it destroys the environment your SQL Server runs in. Recovery means rebuilding from scratch: the operating system, the SQL Server binaries, every configuration setting, every Agent job, every login. Without that capability, your database backups have nowhere to land.
A backup that has not been tested, isolated, and paired with certificate management is not a recovery capability. A database backup without a server rebuild plan is not one either. Both gaps create the same false sense of security — one that will cost you at exactly the moment you cannot afford it.
Successful Backup. Useless File.
Ransomware operators target your backups first. Not your data — your recovery path.
They spend weeks inside your network before they detonate. During that time they map your backup infrastructure, identify your backup software, and stage for destruction.
Backups stored on network shares, mapped drives, or backup servers connected to the same domain get encrypted along with everything else. Modern ransomware targets backup software agents — Veeam, Commvault, Backup Exec — specifically because attackers know those are the recovery paths. They mount the backup destination during the job window and encrypt it. Your backup software logs a successful job. The file on disk is now ciphertext.
The backup job logged as successful. The file on disk is ciphertext.
Three Ways Backups Fail During a Ransomware Event
Storage location failure. If your backup destination is reachable from a compromised machine — a network share, a mapped drive, a connected backup server — it is not safe from ransomware. The moment an attacker has domain credentials, every connected storage location is in scope.
Certificate failure. If your databases use Transparent Data Encryption (TDE) and your TDE certificate backup lives in the same location as your data backup, you have lost both in a single encryption event. SQL Server will refuse to restore an encrypted database without the certificate. The backup file exists. The database will not open.
Ransomware operators who reach SQL Server make this worse deliberately. If TDE is already enabled, they rotate the certificate. They generate a new certificate under their control, re-encrypt the database master key against it, then delete the original certificate and every backup they can locate. Your certificate backup from last night is now the key to a lock that no longer exists. The database was re-encrypted with a certificate only the attacker holds.
If TDE is not already enabled, they apply it. They enable TDE on your databases using a certificate they control, then detonate the ransomware. Your databases end up with two layers of encryption: TDE at the SQL Server level with an attacker-held certificate, and ransomware encryption at the file system level. Recovering from the file-level encryption does not open the database. SQL Server still requires the certificate the attacker used — and you do not have it.
Either path ends in the same place. A backup file you cannot open, on a server you cannot fully recover, with a certificate that no longer exists in your environment.
Validation failure. Backup software reports success at the file transfer level. It confirms the file was written. It does not confirm the file contains restorable data. A database can go corrupt between backups, and the next backup will faithfully archive the corruption. You find this during the restore — not before.
A Backup File Is Not a Server Recovery Plan
The three failure modes above assume you can get a SQL Server instance up and running to restore into. During a ransomware event, that assumption is often wrong.
When ransomware hits a production SQL Server environment, you are not restoring a database file onto a running server. You are rebuilding from scratch. The operating system is gone. The SQL Server installation is gone. The instance configuration is gone. A SQL Server backup file contains the user database — the data files and log files for that database. It does not contain any of the rest.
SQL Server unattended install files. When you installed SQL Server — even if you used the GUI installer — the installer generated a ConfigurationFile.ini that captured every setting: edition, collation, feature selection, service accounts, and instance-level options. Without that file, you are rebuilding from memory. If the collation on the rebuilt instance does not match the database, the restore loads successfully and the application fails in ways that are slow to diagnose. These files should be exported from every production SQL Server instance and stored in immutable storage. They are small. There is no excuse for not having them.
Instance configuration scripts. Every setting in sp_configure — memory limits, max degree of parallelism, cost threshold for parallelism, CLR enabled, xp_cmdshell, remote access settings — governs how your applications behave. A rebuilt instance with default settings will not behave like your production server. These settings should be scripted out, stored in immutable storage, and updated whenever a configuration change is made.
Logins and permissions scripts. SQL Server logins live in the master database — not in your user database backups. You cannot restore them from a database backup. During a ransomware recovery you should not restore master from backup either, because master may contain attacker-added logins or linked servers pointing back to compromised infrastructure. Logins and role assignments should be scripted out regularly and stored separately. Post 3 in this series covers why rebuilding master from script is the correct path.
Agent jobs, alerts, and operators. SQL Server Agent jobs live in msdb — not in your user database backups. Your backup jobs, maintenance plans, integrity check schedules, and alert configurations all require separate scripts. Without them, the rebuilt server has no automated jobs until someone recreates them manually from memory. Post 3 explains why you rebuild msdb from script rather than restoring it from backup — a malicious Agent job carried back through a restore can re-execute a payload the moment the SQL Server Agent service starts.
The rule is simple: if it lives outside a user database, a database backup cannot restore it. Everything needed to rebuild the SQL Server instance from scratch — install files, sp_configure scripts, login scripts, Agent job scripts — must be stored in immutable storage before the attack. If it is not there when ransomware hits, you are reconstructing it from memory at 2am under pressure.
What “Done This” Actually Means
Four things separate a real recovery capability from a file storage system.
Backups land on isolated, immutable storage. Not a mapped drive. Not a UNC path accessible from domain machines. Object Lock-enabled Azure Blob, S3, or equivalent — storage that cannot be modified or deleted by anything that touches your network, regardless of credentials.
TDE certificates are backed up separately and stored offline or in a vault. If your certificates live next to your data, they die with your data. The certificate backup must be stored in a location physically and logically separate from the database backup chain. OpenBao, Azure Key Vault, or an encrypted offline copy — the mechanism matters less than the separation.
Certificate changes must also be covered by SQL Server Audit. CREATE CERTIFICATE, ALTER CERTIFICATE, and DROP CERTIFICATE are high-value events — any change to your certificate inventory should generate an alert. An attacker rotating a TDE certificate leaves a record in the audit log. Without that alert, you may not discover the rotation until you attempt a restore and find the certificate does not match the backup.
A full restore test was completed within the last 30 days. Not RESTORE VERIFYONLY. Not a backup report that shows success. A full restore to an isolated server, followed by DBCC CHECKDB, followed by a confirmed application connection. Thirty days, not ninety — ninety days of unvalidated backups can lead to more data loss than most organizations can survive. In that window, backup jobs change, databases get added, certificates get rotated, and retention policies drift silently. Any one of those changes can break your restore chain without announcing itself. Find the failure in a monthly test, not under ransomware pressure. If you cannot point to a test within the last 30 days and its results, you do not know whether your backup restores today.
A documented recovery procedure exists and has been walked through. Under ransomware conditions, your team will be stressed, your environment will be partially destroyed, and decisions will have consequences. A procedure written in advance — reviewed at least every three months in a tabletop exercise and executed at least every six months in a live simulation — is the difference between a structured, clean recovery and a chaotic one that takes three times as long — and chaotic recoveries that cut corners to restore speed are how organizations get hit again, either by the same ransomware or a second attack that moves in while the environment is still exposed.
Backup Verification Is Not Optional
RESTORE VERIFYONLY reads the backup header and checks the media structure. It does not apply data pages. It does not verify logical consistency. A backup can pass VERIFYONLY and still fail on RESTORE with a torn page or a broken log chain.
The only verification that proves you have a working backup is a full restore followed by DBCC CHECKDB with no repair options. Run it in a test environment. Run it monthly on your critical databases. Document the results. The findings before a ransomware event are maintenance work. The findings after are a crisis.
Verifying the database restores is only half the picture. A restore test proves the backup file is intact. It does not prove the server can be rebuilt. Under ransomware conditions you are not restoring a database onto a running server — you are standing up the server from scratch first: operating system, SQL Server installation from the unattended install files, instance configuration, logins, Agent jobs. A database restore test that skips the server layer has proven backup integrity. It has not proven ransomware recovery capability. The full server rebuild workflow — what to build, in what order, on isolated infrastructure — is the IRE process covered in The Steps Nobody Tells You About.
Know Before Ransomware Does
The gaps described above — backup infrastructure reachable from a compromised domain, certificates stored alongside the data they protect, restore procedures that have never been executed, server rebuild artifacts that do not exist — are present in most SQL Server environments. Most organizations do not know which ones apply to them until they are already in recovery mode.
That is the wrong time to find out.
The SQL Server Security Discovery Call is where you get the full picture. We look at your environment together — backup architecture, certificate management, recovery readiness, and server rebuild capability — and identify exactly where your exposure is before an attacker does.