Why Your Dental Backup Got Encrypted Too

If you're reading this because a practice just discovered its backups were encrypted along with everything else, you're not careless and you're not alone. Having backups is no longer enough. The question that matters now is where those backups live and who can reach them — because modern ransomware is built specifically to find and destroy your safety net before it touches a single patient chart.

Why does ransomware encrypt the backup too?

Because attackers know your backup is the one thing that lets you say no to the ransom. Today's ransomware crews don't smash-and-grab; they spend days inside your network first, mapping what's there. The deletion of backups is a deliberate early step, not a side effect. Once they have administrator access, they enumerate every reachable share, every mapped drive, and every connected disk — and your backup is sitting right there with a friendly label on it.

This is why "we have backups" and "we can recover" are two completely different statements. Healthcare ransomware attacks rose roughly 58% in 2025, with around 636 attacks hitting the sector and secondary providers including dental making up about 26% of incidents (Comparitech 2025–26). The crews behind these — strains like Qilin, INC, SafePay, Sinobi, and Medusa — treat backup destruction as standard procedure. And it works: only about 2% of organizations that paid a ransom recovered all of their data , which tells you a clean, untouched backup is worth far more than a payment.

How does an attacker reach a backup that's "separate"?

Through the same network and the same credentials you use every day. The word "separate" does a lot of misleading work in dental IT. A backup is only truly separate if the compromised environment can't authenticate to it or overwrite it. Most practice backups fail that test in one of three ways:

• Same server. The backup folder lives on the same machine as the practice-management database. One encryption pass takes both.
• Same network, mapped as a drive. A NAS or backup appliance shows up as a drive letter on every workstation. If a workstation can see it, so can the ransomware running on that workstation.
• Same credentials. The backup software runs under a domain admin account. The moment the attacker has that account — which is their primary goal — they own the backup too.

The uncomfortable truth is that anything reachable with a password the attacker has stolen is not a backup; it's just another target.

The legacy-server trap: when your last copy dies with your first

The worst version of this is the old server nobody decommissioned. Practices upgrade their PMS or migrate to a new machine, but the previous server gets kept "just in case" — and over time it quietly becomes where the nightly backup lands. It's on the network, it has a big drive, and it feels safe because it's not the production box anymore.

This is exactly what made the Tampa Bay Dental Implants incident so devastating: the encrypted legacy server also held the backup copies . When that one machine went down, the primary data and the recovery copy went down together. The lesson isn't "don't keep old servers" — it's that a recovery copy on any machine inside the blast radius is not a recovery copy at all.

The contrast is just as instructive. True Dental Care PA was hit but restored from backups and did not pay the ransom (17,640 patients affected) . Same threat, opposite outcome — and the difference was a backup the attacker couldn't reach. For a step-by-step view of how the timeline unfolds, see our Dental Ransomware Recovery Playbook.

The fix: immutable, off-site, separately credentialed

The solution is a recovery copy the attacker physically cannot alter, reach, or delete — even with full admin access. That's three specific properties working together, and missing any one of them reopens the hole:

1. Immutable (write-once / object-locked). Once a recovery point is written, it cannot be changed or deleted until its retention window expires — not by ransomware, not by a compromised admin. Encryption tries to rewrite your files; immutability simply refuses the rewrite. DDSArk writes recovery points to immutable, object-locked storage so an encryption pass has nothing it can overwrite.
2. Off-site. A copy that lives outside the building isn't on the LAN the ransomware is scanning. Encrypted, off-site replication keeps a current copy somewhere the local infection can't traverse to. (This is also why USB and NAS alone fall short — more in Why USB and NAS Backups Aren't Enough.)
3. Separately credentialed. The backup must not be reachable with the domain credentials the attacker steals. Different authentication boundary, different control plane — so owning your network doesn't mean owning your backup.

People often ask whether they need air-gapping or immutability. Immutability gives you the survivability of an air gap without unplugging anything every night, and the two are complementary; we break down the trade-offs in Air-Gapped vs Immutable Backups.

What does this look like for a dental practice specifically?

It means application-consistent copies of your PMS database and imaging, replicated off-site, that no one inside a breach can touch. Your practice-management database and imaging files have to be captured in a consistent state or the restore comes back corrupt. DDSArk captures application-consistent recovery points of the PMS database and imaging, replicates them off-site under encryption, and writes them to immutable storage managed outside your practice's credential boundary. Specific retention windows, recovery-time targets, and replication intervals are configured per fleet, and DDSArk signs a HIPAA BAA so the handling of that protected health information is covered by agreement.

The reason this matters in dollars and days: the average healthcare ransomware recovery runs about 19 days, with an average recovery cost near $1.02 million excluding any ransom . A practice that can restore from an untouched immutable copy skips most of that. A practice whose only backup was encrypted lives the full 19 days — assuming it recovers at all.

If you take one thing from this: stop asking "do we have a backup?" and start asking "can the thing that just encrypted us reach our backup?" If the honest answer is yes, you don't have a recovery plan — you have a second copy of your problem.