Zerethon IDE
Sign in

Backups and recovery

Intermediate 10 min read

Back up the data that matters, keep copies somewhere else, and prove you can restore them.

Why it matters

Servers fail, people run the wrong command, and ransomware exists. Code can be redeployed from Git; data cannot be recreated. A backup that was never restored is only a hope.

Where it fits

  1. Plan & Design
  2. Develop
  3. Version control
  4. Verify
  5. Build & Package
  6. CI/CD
  7. Deploy
  8. ● Operate

What you will learn

  • Decide what to back up, how often and where.
  • Take and restore a database backup.
  • Schedule a regular restore test.

Before you start

Two questions first

  • How much data may you lose? (recovery point objective) — sets how often to back up.
  • How long may you be down? (recovery time objective) — sets how fast a restore must be.
Example 
# PostgreSQL: a compressed logical backup
pg_dump --format=custom --file=app-2026-10-23.dump app

# Restore into an empty database to test it
createdb app_restore_test
pg_restore --dbname=app_restore_test app-2026-10-23.dump
Run restores against a separate database, never over production.

Rules that hold up

  • Backups run automatically, and a failed backup alerts someone.
  • At least one copy is in another location, which the production server cannot delete.
  • Backups are encrypted, and the key is stored separately.
  • A restore is tested on a schedule, and how long it took is written down.

Watch out: Copying the files of a running database usually produces a broken backup. Use the database's own backup tool.

Official documentation and references

Documentation

Reference

Learn next

Related topics

Done with this topic?

Reviewed 2026-10-23. Links go to the official documentation unless marked otherwise.