Backups: how not to lose your project's data

Backups protect against data loss from server failure, developer error, a breach or accidental deletion. A reliable setup means automated database and file backups following the 3-2-1 rule, storage outside your main provider, encryption and regular restore tests. A backup that has never been restored cannot be considered a backup.

Here is what to back up, how often, where to store it and how to check that everything will actually restore when needed.

What needs to be backed up?

Back up everything you cannot quickly recreate: the database, user-uploaded files, secrets and environment settings. Code usually already lives in a repository, but customer data exists in only one place.

• database — orders, users, payments, content;
• files — user uploads, documents, images;
• configuration — environment variables, server settings, DNS;
• secrets — encryption keys and credentials, in a secure vault;
• third-party services — data held by vendors and not duplicated on your side.

We covered file storage in file uploads and storage.

What are RPO and RTO?

RPO and RTO are the two numbers any backup scheme starts with. RPO answers "how much data can we afford to lose", RTO "how quickly must we recover". They determine backup frequency, storage method and cost.

Metric	Question	Example for an online shop
RPO (Recovery Point Objective)	How much data can be lost	No more than 15 minutes of orders
RTO (Recovery Time Objective)	How long recovery may take	No more than 2 hours

If a daily copy is enough, a nightly dump will do. If not even minutes can be lost, you need continuous transaction log archiving and point-in-time recovery.

Photo: Unsplash

What is the 3-2-1 rule?

The 3-2-1 rule says: keep three copies of your data, on two different types of media, with one in another location. For a web project that means the live database, a copy with the same provider for fast recovery and a copy in another provider's storage in case of a disaster or account lockout.

Extra rules:

1. Backups are encrypted and keys are stored separately.
2. The application server has no permission to delete old backups — this protects against ransomware and mistakes.
3. Retention is tiered: daily, weekly and monthly copies.
4. Backup failures trigger an alert, not a log line nobody reads.

How often should the database be backed up?

Frequency follows RPO: for most projects a daily full dump plus continuous transaction log archiving for point-in-time recovery is enough. Small sites with rare changes can live with a single nightly copy.

# Daily compressed PostgreSQL dump shipped to external storage
pg_dump --format=custom --compress=9 "$DATABASE_URL" \
  > "/backups/db-$(date +%F).dump"

aws s3 cp "/backups/db-$(date +%F).dump" \
  "s3://project-backups/db/" --storage-class STANDARD_IA

Managed cloud databases usually do this themselves, but check where the copies are stored, for how many days and whether you can export them. On choosing between your own server and the cloud, see VPS, cloud or managed services.

How do you check that a backup will restore?

The only way to check a backup is to restore it: regularly deploy a copy to a separate server and confirm the application starts with it and the data is fresh. Many teams learn that their backups were empty or corrupt on the day of the disaster.

Checklist:

• restore the database from a backup on a test server once a month;
• time the restore and compare it with your RTO;
• check the date of the latest record in the restored database;
• keep step-by-step restore instructions that someone other than the author can follow;
• twice a year, run a drill: "the server is gone, rebuild from scratch".

For learning about outages in time, see monitoring and logging, and on data protection, OWASP Top 10 explained.

In short

• Back up the database, files, configuration and secrets — anything you cannot quickly recreate.
• Start with RPO and RTO: how much data you can lose and how fast you must recover.
• Follow the 3-2-1 rule and keep one copy with a different provider.
• Encrypt backups and do not let the application server delete them.
• Restore from backups regularly — only then is a backup real.