Backup Security

Database Security

Chapter 8 · Backup Security

Chapter 1 named backup theft as its own threat category, distinct from attacking the live database directly. This chapter is the deep dive: encryption, storage, retention, and the uncomfortable truth that a backup which has never been restored isn't actually a verified backup at all.

Backups Are a Complete Copy of Your Data

Every protection this course has covered — least privilege (Ch.3), network isolation (Ch.4), encryption (Ch.5–6), auditing (Ch.7) — has been about the live database. A backup is a complete, standalone copy of the exact same data, and by default, none of those protections automatically travel with it. Treating backup security as an afterthought means building a well-defended live system with an equally sensitive, far less defended copy sitting somewhere else.

Encrypting Backups

Chapter 5 noted that TDE encrypts the backups the database engine itself produces — but a huge share of real-world backups are made with plain dump tools (mysqldump, pg_dump) rather than the engine's own encrypted backup mechanism, and those tools produce plain-text SQL by default, regardless of whether TDE is enabled on the live database at all.

# A common real gotcha: this backup is plain, readable SQL — even if TDE is on mysqldump shop_db > backup.sql # Encrypting the dump directly, piped so it's never written to disk unencrypted mysqldump shop_db | gpg --encrypt --recipient backups@example.com > backup.sql.gpg

The dump tool's own encryption status has nothing to do with the live database's TDE setting — they're entirely separate mechanisms, and it's easy to assume "we have TDE, so we're covered" while a completely unencrypted mysqldump output sits on a backup server.

Secure Backup Storage & Access

The exact same principles Chapters 3 and 4 applied to the live database apply directly to wherever backups are stored: least privilege (only the specific accounts that genuinely need backup access should have it — not "the whole ops team by default"), and network security (a backup sitting in a publicly readable cloud storage bucket is exactly as exposed as a database port open to the internet, just discovered differently).

Retention Policy Trade-offs

How long to keep backups is a genuine trade-off, not a "more is always safer" decision:

  • Keeping backups too long means more copies of sensitive data sitting around, each one a separate attack surface — and can conflict with privacy/compliance obligations if data that should have been deleted per policy still exists in an old backup.
  • Keeping backups too short risks being unable to recover from a problem discovered late — a slow data-corruption bug, or a breach not noticed for weeks, can mean the only "clean" backup has already aged out and been deleted.

A deliberate retention policy — balancing both risks rather than defaulting to either extreme — belongs on Chapter 10's hardening checklist.

"Your Backups Are Also an Attack Target"

Ransomware routinely targets backups first, deliberately
A well-documented real-world ransomware tactic is to locate and destroy or encrypt an organization's backups first, specifically to remove any ability to recover without paying, before ever touching the live system. If backups are reachable from the same network the live database sits on, with the same (or weaker) access controls, an attacker who compromises one often compromises both in the same incident — turning what should have been a recoverable event into a total loss. Backup storage deserves its own access controls and network isolation, not an inherited assumption that "it's just a copy, it's fine."

Testing Restore Procedures

A backup that has never actually been restored is an assumption, not a verified backup — silent corruption, an incomplete dump, a misconfigured schedule, or a permissions issue can all mean months of "successful" backup jobs produced files that don't actually restore to a working database.

An untested backup only reveals whether it works when it's too late
The worst possible moment to discover a backup doesn't actually restore is during a real incident, when it's needed most and there's no time left to fix it. Scheduled, regular test restores — into an isolated environment, verified against expected data — are the only way to know a backup process genuinely works, rather than simply assuming it does because the job reports "success" every night.

Hands-On Exercises

Exercise 1

A team believes their backups are secure because their database has TDE enabled. Explain why a nightly mysqldump backup could still be a serious risk despite this, and propose a fix.

📄 View solution
Exercise 2

Explain why a ransomware attacker specifically targets backups before (or instead of) the live database. What does this imply about where backups should be stored relative to the live system?

📄 View solution
Exercise 3

A company has run nightly backups successfully (per the job's own logs) for two years but has never restored one. Explain why this doesn't actually guarantee they have a working disaster-recovery plan, and what should change.

📄 View solution

Chapter 8 Quick Reference

  • A backup is a complete copy of the live database's data — none of the other chapters' protections travel with it automatically
  • Dump tools (mysqldump, pg_dump) produce plain-text output by default — TDE on the live database does not automatically encrypt these; encrypt the dump itself (e.g. piping through gpg)
  • Backup storage needs its own least privilege (Ch.3) and network isolation (Ch.4) — not inherited assumptions from the live system
  • Retention is a trade-off: too long = more exposed copies + compliance risk; too short = can't recover from a late-discovered incident
  • Ransomware attackers routinely target backups first to remove recovery options before demanding payment
  • An untested backup is an assumption, not a verified recovery plan — regular scheduled test restores are the only real verification
  • Next chapter: Database-Specific Hardening — disabling unnecessary features, removing default accounts/databases, patching and CVE management