The Complete Guide to Backing Up Open Dental

What do you actually need to back up in Open Dental?

You need two distinct things, and you need them captured at the same moment: the database and the image folder. Most failed dental restores happen because someone backed up one and assumed it included the other.

Open Dental stores your structured data—patients, appointments, treatment plans, ledgers, perio charts, clinical notes—in a MySQL or MariaDB database. But it stores X-rays, intraoral photos, scanned forms, and documents as ordinary files in a separate folder on disk, commonly named OpenDentImages. The database holds a pointer to each image; the image bytes live in the folder. Restore the database without the folder and every chart opens with broken image links. Restore the folder without the database and you have a pile of files with no idea which patient they belong to.

This split is also why USB and NAS shortcuts so often fail dental practices—we cover that failure mode in Why USB and NAS Backups Aren't Enough.

Where do these live on the server?

The database files sit in the MySQL/MariaDB data directory on whichever machine runs the server (the path varies by install and OS, so confirm yours: {{VERIFY: default MySQL data directory path for your Open Dental install}}). The image folder location is configured inside Open Dental and points at a shared path like a server share named OpenDentImages. Write both paths down before you design any backup job.

How to back up Open Dental, step by step

The goal of every step below is one thing: an application-consistent capture you can actually restore from.

Step 1 — Capture the MySQL/MariaDB database consistently

Do not copy the live database data files while MySQL is running. The correct approach is a logical dump with mysqldump, which reads the database through the engine and writes a clean, importable .sql file, or a consistent storage-engine snapshot that quiesces writes for the instant of capture. Use the flags --single-transaction --routines --triggers and write the dump to a dated file.

The --single-transaction flag gives you a point-in-time consistent dump without locking the whole database—but, importantly, that only works cleanly for transactional tables (see Step 3). Schedule this to run on a cadence that matches how much work you can afford to lose; DDSArk captures recovery points as frequent as every 15 minutes.

Step 2 — Back up the OpenDentImages folder at the same point in time

Immediately after the database dump, capture the OpenDentImages folder. It must be paired with that specific dump so the database's image pointers match the files on disk. Because this folder is large and grows constantly, use an incremental or block-level copy after the first full capture—but always tie each image capture back to a known-good database dump from the same window.

Step 3 — Mind InnoDB vs MyISAM (this is where silent corruption hides)

MySQL stores tables using a storage engine. The two that matter here are MyISAM and InnoDB.

• MyISAM — Open Dental has historically used this engine. It is not transactional and not crash-safe. If you take a hot file-copy of MyISAM table files while the server is writing, you can capture them mid-update and produce a corrupt, partially-written backup that imports with errors or quietly drops rows. mysqldump --single-transaction does not protect MyISAM tables, because they don't honor transactions.
• InnoDB — transactional and crash-safe, with far better crash recovery. Tables on InnoDB can be dumped consistently with --single-transaction and tolerate interruption far more gracefully.

Practical implication: if your install still uses MyISAM, prefer mysqldump (which reads through the engine) over any file-level copy, and consider whether converting to InnoDB is appropriate for your environment {{VERIFY: whether your Open Dental version/config supports converting tables to InnoDB}}. Either way, never restore by copying raw MyISAM table files out from under a running server.

Step 4 — Send a copy off-site and make it immutable

A backup sitting on the same server—or on a NAS on the same network—dies with that server. Ransomware actively hunts and encrypts reachable backups. In one real incident, Tampa Bay Dental Implants had roughly 6,400 individuals affected when an encrypted server also held the backups . The defense is an off-site copy written write-once (immutable) and encrypted, so an attacker who owns your network still cannot alter or delete it. This is exactly the scenario we unpack in Why Your Dental Backup Got Encrypted Too.

Step 5 — Verify by restoring

A backup you have never restored is unproven. On a schedule, restore the .sql dump and the paired image folder to a separate test machine, open Open Dental against it, and confirm that charts load and X-rays render. This is the only step that actually tells you your backups work.

The Open Dental backup checklist

Use this every time you design or audit a backup:

• Database captured with mysqldump (--single-transaction --routines --triggers) or a consistent snapshot—not a hot file-copy
• OpenDentImages folder captured and paired to the same point-in-time as the database dump
• Storage engine confirmed (MyISAM vs InnoDB) and capture method matched to it
• Stored procedures, triggers, and any custom queries included in the dump
• At least one copy is off-site
• At least one copy is immutable (write-once) and encrypted
• Backup runs on a defined schedule matching your acceptable data loss
• Restore tested to a separate machine, with charts and images verified to open
• Restore is documented so any team member can perform it under pressure

Do all of this yourself, or have it managed for you under a HIPAA Business Associate Agreement. DDSArk captures the Open Dental database application-consistently, pairs it with the image folder, and writes encrypted, immutable copies off-site—so a single ransomware event cannot take both your live data and your recovery with it.