Backups and Restore

A backup you have never restored is only a hope. Backups must include the data that cannot be recreated: databases, uploads, generated files, and critical config.

pg_dump "$DATABASE_URL" > backup.sql
tar -czf uploads.tar.gz /var/www/app/uploads

Store backups outside the server: object storage, another machine, or a managed backup service.

Further Learning

• “database backup restore test” — restore validation
• “3-2-1 backup rule” — backup strategy
• “pg_dump restore basics” — PostgreSQL example

Backups and Restore

A backup is a safety copy of everything you can’t just recreate — your database, uploaded files, important config. Your app’s code is safe in Git, but your actual data needs its own protection.

Making a backup

pg_dump "$DATABASE_URL" > backup.sql          # dump the database
tar -czf uploads.tar.gz /var/www/app/uploads  # zip up uploaded files

Keep backups somewhere else

Storing a backup on the same server as the original doesn’t protect you from much — if that server dies entirely, your backup dies with it. Always copy backups to somewhere separate: another machine, cloud storage, or a dedicated backup service.

The most important rule

Also, write down the exact restore steps somewhere. Guessing your way through a restore during an actual incident wastes precious time and increases the risk of making things worse.

In one sentence

Back up your actual data (database, uploads) regularly, store the backups somewhere separate from the server, and — most importantly — actually test the restore process before you’re forced to rely on it in a real emergency.

Want to go deeper?

Switch to Expert mode above for the 3-2-1 backup rule and a full PostgreSQL backup/restore walkthrough.