godwinsystems/rb
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

od-db-backup: clarify full backup = DB + images (app is reinstalled), capture config + versions

Browse Source 
Per Open Dental docs a complete backup is the database + A-to-Z images; the
program itself is not backed up but reinstalled at the matching version on
restore. Extend the script to capture two recovery aids best-effort (outside
the downtime window): a copy of FreeDentalConfig.xml and the exact Open Dental
+ MySQL/MariaDB versions, recorded in MANIFEST.txt. Runbook now spells out
what is/isn't backed up and notes the config file holds the obfuscated DB
password on direct-connect setups.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Ivan Godwin
2026-07-12 23:21:17 -07:00
parent 5dfa62ced6
commit 25a5127d53
2 changed files with 56 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files
od-db-backup.md
+16 -7
View File
@@ -3,14 +3,19 @@
**Applies to:** The Windows machine hosting the Open Dental MySQL/MariaDB database (the "server").
**Goal:** A fully consistent, restorable backup of both halves of an Open Dental practice — the **database** and the **A-to-Z images folder** — following Open Dental and MySQL/MariaDB best practice, including cleanly **stopping the database during the copy and restarting it after**.
A complete Open Dental backup is **two things**, and both must be captured together:
### What a complete Open Dental backup is (and isn't)
| Component | Default location | Holds |
|---|---|---|
| MySQL/MariaDB **data directory** | `C:\mysql\data\` (contains the `opendental` DB) | All clinical/financial data |
| **A-to-Z / OpenDentImages** folder | `C:\OpenDentImages\` | Scanned docs, images, attachments |
Per Open Dental's own docs, a full backup is **two things — the database and the A-to-Z images folder** — and both must be captured together. A database backup **without** the images folder (or vice-versa) is not a usable restore.
A database backup **without** the images folder (or vice-versa) is not a usable restore.
| Component | Default location | Back up? | Holds |
|---|---|---|---|
| MySQL/MariaDB **data directory** | `C:\mysql\data\` (contains the `opendental` DB) | **Yes — required** | All clinical/financial data |
| **A-to-Z / OpenDentImages** folder | `C:\OpenDentImages\` | **Yes — required** | Scanned docs, images, attachments |
| **`FreeDentalConfig.xml`** | Open Dental install dir | Nice-to-have | Connection / Choose-Database / AtoZ path config |
| Open Dental **program files** | `…\Program Files\Open Dental\` | **No — reinstall** | The application itself |
| Other office documents | (varies) | Per your policy | Non-Open-Dental files |
**There is no separate "application backup."** Open Dental does **not** back up the program itself — on restore you **reinstall the matching Open Dental version** (and matching MySQL/MariaDB) and point it at the restored data. So the two "recovery aids" worth grabbing are just: a copy of **`FreeDentalConfig.xml`** and a record of the **exact versions** to reinstall. The script captures both automatically into the backup folder (`FreeDentalConfig.xml` + `MANIFEST.txt`) — nothing extra to run.
**Placeholders:**
@@ -61,7 +66,8 @@ It will:
3. **Stop `<DB_SERVICE>` and verify it reached *Stopped*** — aborting the copy if it doesn't.
4. `robocopy` the **whole** data directory to `<DEST>\od-backup-<timestamp>\data`, then the images to `…\OpenDentImages`.
5. **Restart `<DB_SERVICE>`** in a `finally` block — this runs even if the copy fails or is interrupted.
6. Write `MANIFEST.txt` and `backup.log` into the backup folder.
6. Capture recovery aids (best-effort, outside the downtime window): a copy of **`FreeDentalConfig.xml`** and the exact **Open Dental + MySQL/MariaDB versions**.
7. Write `MANIFEST.txt` and `backup.log` into the backup folder.
### Manual equivalent (offline / if you can't fetch the script)
@@ -118,11 +124,14 @@ schtasks /Create /TN "OD Nightly Cold Backup" /TR "powershell -NoProfile -Execut
Backup media and dumps hold the **entire practice's PHI**. Treat them as the crown jewels: encrypt the destination, lock down share permissions, and keep at least one copy **off-line/immutable** so ransomware can't encrypt your backups along with production. Don't store `<DB_PASSWORD>` in the scheduled command line — use a MySQL option file / limited account.
Note that the captured `FreeDentalConfig.xml` stores the MySQL password **obfuscated but reversible** on **direct-connection** setups. The backup already contains all PHI so this doesn't change the requirement — but it's one more reason the destination must be encrypted and access-controlled. (Middle Tier setups don't put DB credentials in that file — see `od-cfg-persist.md`.)
## References
- Open Dental manual — Backups (overview): <https://opendental.com/manual/backups.html>
- Open Dental manual — Manual Backups: <https://www.opendental.com/manual/backupsmanual.html>
- Open Dental manual — Backup Tool: <https://www.opendental.com/manual/backuptool.html>
- Open Dental manual — FreeDentalConfig.xml: <https://www.opendental.com/manual/freedentalconfig.html>
- Open Dental — InnoDB (backup implications): <https://www.opendental.com/site/mysqlinnodb.html>
- Open Dental manual — MySQL Data Directory Management: <https://opendental.com/manual/mysqlmanage.html>
- MySQL — `mysqldump`, `--single-transaction`: <https://dev.mysql.com/doc/refman/en/mysqldump.html>