How to Back Up Dentrix the Right Way in 2026

Why can't I just copy the Dentrix folder?

Because Dentrix is a live database application, and copying its files while it's running gives you a backup that may not restore. Dentrix stores your practice in an active database engine {{VERIFY: exact Dentrix database engine name and version}} that is constantly writing as staff add charts, post payments, and adjust the schedule. Grab those files mid-write and you capture a half-finished transaction. The result is the digital equivalent of photographing a moving car: technically an image, practically useless.

This is the single most common mistake we see, so it gets its own box.

Backing up the folder ≠ backing up Dentrix

Copying the Dentrix data folder while the database is in use produces an inconsistent, often corrupt backup that fails when you actually need it. A real Dentrix backup requires an application-consistent capture — the database is quiesced or snapshotted via VSS {{VERIFY: that the Dentrix database supports Windows VSS-based application-consistent snapshots}} so every record reflects the same moment in time. Then you need that consistent copy stored off-site and immutable, so ransomware on your network can't reach it.

What does Dentrix actually store that I have to protect?

Everything that makes your practice a practice — and it's more than one folder. A complete Dentrix backup has to cover the live clinical and financial record plus the linked media that the database points to but doesn't contain.

What it is	Why it's critical
Practice-management database	The core record tying every patient, appointment, and transaction together.
Patient charts & clinical notes	Treatment history, diagnoses, perio, and progress notes — your medical-legal record.
Schedule / appointment book	Who's coming in and when; losing it stops the practice cold.
Ledgers & financials	Production, payments, insurance claims, A/R. Rebuilding these by hand is brutal.
Linked imaging & documents	X-rays, photos, scanned forms, and signed consents, which often live outside the core database {{VERIFY: that Dentrix stores imaging and linked documents in separate file paths from the core PMS database}} and are worthless without the records that reference them.

If your backup captures the database but skips imaging — or vice versa — you don't have a recoverable practice. You have two incomplete halves.

Why does the backup have to leave the building?

Because a backup sitting on your own network gets encrypted right alongside production. Modern ransomware specifically hunts for connected backups before it triggers. In one real incident, Tampa Bay Dental Implants had its server encrypted along with the backups stored on it, affecting roughly 6,400 people . An on-site-only backup is a single blast radius.

The contrast is just as instructive. True Dental Care in Pennsylvania was able to restore from backups and chose not to pay the ransom after an incident affecting 17,640 individuals . The difference between paying and recovering usually comes down to whether a clean, separated copy survived.

That's why the rule is at least one off-site copy and at least one immutable copy. Immutable means write-once: even an attacker with admin credentials cannot alter or delete the recovery point during its retention window. We go deeper on this failure mode in why your dental backup got encrypted too.

How often should Dentrix be backed up?

Often enough that a failure costs you minutes of data, not days — which in a busy practice means continuous or near-continuous capture, not a nightly file dump. Every appointment booked, payment posted, and note written between backups is data you'd re-enter by hand after a loss. DDSArk's recovery-point objective for Dentrix is as little as 15 minutes and typical restore time is under 15 minutes, but the principle holds regardless of vendor: tighten the gap between backups and you shrink the size of any disaster.

The stakes here aren't abstract. Healthcare ransomware rose roughly 58% in 2025, with around 636 attacks recorded, and dental and other secondary targets made up about 26% of incidents . Average recovery took about 19 days, at an average cost near $1.02M . And of organizations that paid the ransom, only about 2% got all their data back . Paying is not a recovery plan.

What does a correct Dentrix backup actually look like?

It's a layered system, not a single copy. A backup you can trust in 2026 has four properties:

1. Application-consistent — the database is quiesced or VSS-snapshotted so every record is captured at one coherent moment.
2. Complete — the PMS database and imaging/linked documents, together.
3. Off-site — at least one copy lives on a separate network the ransomware can't traverse.
4. Immutable — at least one write-once recovery point that can't be altered or deleted.

Layered on top: encryption in transit and at rest, retention long enough to survive a slow-burn attack, a signed HIPAA Business Associate Agreement, and — most important — regularly tested restores. A backup you've never restored is a hypothesis, not a safeguard.

This is the approach DDSArk takes: application-consistent capture of the Dentrix database and imaging, encrypted off-site replication, immutable write-once recovery points, all MSP-managed. If the worst happens, walk the dental ransomware recovery playbook, and to pressure-test your current setup before you need it, run the HIPAA backup audit self-check.