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

od-db-backup: note off-site tools must source <DEST>, not the live datadir

Browse Source 
Off-site replication (Duplicati->B2, rclone, Veeam, etc.) should back up the
cold-copy output under <DEST>, not re-crawl C:\mysql\data. The od-backup-*
folders are already consistent; a naive hot copy of a live InnoDB datadir is
corrupt. Adds sequencing guidance (run off-site job after the cold backup;
stagger schedules) and layered off-site encryption/immutability.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Ivan Godwin
2026-07-12 23:23:27 -07:00
parent 25a5127d53
commit a5a36e9a6f
1 changed files with 9 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
od-db-backup.md
+9
View File
@@ -118,6 +118,15 @@ schtasks /Create /TN "OD Nightly Cold Backup" /TR "powershell -NoProfile -Execut
- Keep several daily generations plus weekly/monthly rollups; prune old `od-backup-<timestamp>` folders on a schedule. - Keep several daily generations plus weekly/monthly rollups; prune old `od-backup-<timestamp>` folders on a schedule.
- These files contain **PHI** — encrypt at rest and in transit; restrict access. HIPAA applies. - These files contain **PHI** — encrypt at rest and in transit; restrict access. HIPAA applies.
### Point off-site tools at `<DEST>`, not at the live database
Any off-site/cloud replication (Duplicati → Backblaze B2, Veeam, `rclone`, Wasabi, etc.) must use **`<DEST>` as its source** — it backs up *this backup*. It must **not** re-run the stop/copy against the live `<DATA_DIR>`.
- The `od-backup-<timestamp>` folders under `<DEST>` are already a **consistent, cold copy** produced with the service cleanly stopped. Copying *them* off-site is a safe file copy — no service stop, no downtime, no consistency risk.
- Never let a naive file-sync tool crawl the live `C:\mysql\data` directly. A hot copy of a running InnoDB datadir is **corrupt and unrestorable** — the exact failure this runbook exists to avoid. Off-site tools have no idea they need to stop the service first; that's *this* script's job, done once, up front.
- **Sequence:** this cold backup runs first (nightly, off-hours) → the off-site job runs **after** it completes, sourcing `<DEST>`. Stagger the schedules (e.g. cold backup 23:30, off-site upload 01:00) so the upload never reads a half-written `od-backup-<timestamp>` folder. If your tool supports it, exclude any in-progress/partial folder or upload only completed timestamps.
- Let the off-site tool own its **own** encryption + retention on top — B2/Wasabi object lock or Duplicati's immutability/versioning gives you the ransomware-resistant, off-site copy of the 3-2-1 rule.
--- ---
## Security note ## Security note