KAHIBARO
Discord Login Register ☰
☰

23.9. Backups

Table of Contents

Why Backups Matter in Backend Systems

Backups are your safety net. No matter how well you design and secure your backend, things will eventually go wrong: disks fail, developers run the wrong script, a migration goes bad, or data gets corrupted.

A backup is a copy of your data, configuration, or system state that you can restore later if you lose or damage the original.

A backend with no reliable backups is a backend that is guaranteed to lose data sooner or later.

For production backends, you should treat backups as a core part of deployment, not as an optional extra.

Common situations where backups save you:

Your goal is not only to create backups, but to ensure you can restore from them quickly, reliably, and to the right point in time.

What You Need to Back Up

In a typical backend deployment you usually care about more than just the database.

Core backup targets

TargetWhy it matters
Database (PostgreSQL, etc.)Main source of truth for business data
Object storage (S3, etc.)User uploads, reports, exported files
Configuration & secretsHow the app runs, connects, and authenticates
Application data that is not in DBCaches you want to persist, job queues (sometimes)
Infrastructure config (IaC, scripts)How to rebuild the environment

You normally do not need to back up:

Focus on data that is unique and cannot be recreated.

Types of Backups

There are a few common backup types. Choosing between them is a tradeoff between storage cost, backup time, and restore time.

Full, incremental, and differential backups

TypeWhat it storesProsCons
FullComplete copy of all dataSimple, fastest restoreLarge, slow to create, costly storage
IncrementalChanges since the last backup of any typeSmall, fast to create, saves spaceRestore can require many backup files
DifferentialChanges since the last full backupFaster restore than incrementalGrows larger until next full backup

Typical approach:

This balance keeps restore steps manageable and storage costs reasonable.

Logical vs physical backups (databases)

For databases like PostgreSQL there are two conceptual approaches.

Logical backups

Export SQL or data representation:

Pros:

Cons:

Physical backups

Copy the actual database files or use filesystem-level snapshots or tools like pg_basebackup.

Pros:

Cons:

In small to medium projects, logical backups are often enough. As your database grows, you will likely combine physical backups with WAL archiving or cloud-native backups.

Backup Strategy: RPO and RTO

Before picking tools, define how much data loss is acceptable and how quickly you must recover.

RPO: Recovery Point Objective

RPO is the maximum acceptable amount of data you can afford to lose, usually measured in time.

Examples:

RPO tells you how often you must back up or replicate data.

RTO: Recovery Time Objective

RTO is the maximum acceptable time your system can be down before being restored.

Examples:

RTO tells you how fast your recovery process must be.

Design your backup and restore process to satisfy both RPO and RTO. A backup that takes 24 hours to restore is useless if your RTO is 1 hour.

The 3-2-1 Backup Rule

A classic and very practical rule for production backups is the 3-2-1 rule:

3-2-1 rule

  • Keep 3 copies of your data
  • On 2 different types of storage
  • With 1 copy offsite

Concretely, for a hosted backend:

Storage types might differ by:

The goal is to avoid losing all copies due to a single incident such as region failure or provider issue.

Database Backups in Practice

Most backends depend heavily on a relational database. Here is how to think about backing it up in a real deployment.

Scheduling database backups

At minimum:

Examples of schedules:

ScenarioFull backupIncremental / logs
Small hobby projectDaily fullNone
Small production appDaily fullWAL or hourly incremental
High-traffic production systemWeekly fullContinuous WAL archiving

Example: PostgreSQL logical backup

A simple script on a Linux server:

bash 
#!/usr/bin/env bash
set -e
# Configuration
DB_NAME="myapp"
DB_USER="backup_user"
BACKUP_DIR="/var/backups/postgres"
DATE=$(date +"%Y-%m-%d_%H-%M")
FILE="$BACKUP_DIR/${DB_NAME}_${DATE}.dump"
mkdir -p "$BACKUP_DIR"
pg_dump \
  --format=custom \
  --file="$FILE" \
  --username="$DB_USER" \
  "$DB_NAME"
# Optional: compress further or upload to object storage
gzip "$FILE"

Then schedule with cron:

bash 
0 3 * * * /usr/local/bin/backup_postgres.sh >> /var/log/backup_postgres.log 2>&1

This creates one compressed backup per night at 03:00.

Testing database restore

A backup is only useful if you can restore it. Always test the full process.

Example for PostgreSQL:

bash 
createdb restore_test
pg_restore --dbname=restore_test --clean /path/to/backup.dump

Check:

Make this test part of a regular operations checklist.

Application and Configuration Backups

Even if your application code is in Git, your running system includes more:

Configuration

Configuration often comes from:

Best practice:

Secrets

Secrets include:

Do not store secrets unencrypted in backups.

Typical approach:

If you must include secrets in backups:

File and Object Storage Backups

User-uploaded files and generated assets are often stored in:

Local filesystem backups

If your uploads live on the server disk (for example /var/www/uploads):

Typical script with tar:

bash 
#!/usr/bin/env bash
set -e
SRC="/var/www/uploads"
DEST="/backups/uploads_$(date +'%Y-%m-%d').tar.gz"
tar -czf "$DEST" "$SRC"

Object storage backups

S3 and compatible services are durable, but you may still want:

Useful strategies:

Example with AWS CLI:

bash 
aws s3 sync s3://myapp-uploads s3://myapp-uploads-backup --storage-class STANDARD_IA

Backup Storage: Where to Keep Backups

Choosing backup storage affects cost, durability, and security.

Options

Storage typeProsCons
Same server diskFast, simpleLost if server fails
Separate disk on same serverHandles disk failureNot safe against server loss
Network-attached storageCan be resilient, sharedComplexity, cost
Cloud object storage (S3, etc.)Durable, cheap at scaleRequires careful security
Another cloud/providerProtects against provider-wide issuesMore complexity
Offline storage (cold backups)Protects against online attacksHard to automate, slow restore

A common practical pattern:

Backup Retention Policies

You do not want to keep every backup forever.

A retention policy defines how long you keep each backup.

Example policy:

This is sometimes called a backup rotation scheme.

You can implement retention:

Example with S3 lifecycle:

Make sure your retention supports:

Security of Backups

Backups often contain everything. If someone gains access to your backup, they may get:

So backups need at least as much protection as production data, often more.

Encrypt backups

Encrypt backups at rest:

Example using gpg:

bash 
tar -czf db_backup.tar.gz db_backup.dump
gpg --encrypt --recipient backup@mycompany.com db_backup.tar.gz

Keep private keys in a secure place (for example a hardware token or secret manager).

Restrict access

Follow least privilege:

Protect against ransomware and malicious deletion

Consider:

Some object storage services support object lock or worm mode to prevent deletion before a set time.

Automating and Monitoring Backups

Manual backups will be forgotten. Production backups must be:

Automation

Use:

Example cron entry for a nightly backup:

bash 
0 2 * * * /usr/local/bin/backup_database.sh

Monitoring

You should know immediately when backups fail.

Typical monitoring:

You can integrate with:

Disaster Recovery and Restore Procedures

Backups are only half of the story. Disaster recovery is the full plan to bring your system back.

Define recovery procedures

Document step by step:

  1. Where to find the latest valid backup
  2. How to provision or choose a target server or database
  3. How to restore:
    • Database
    • Files or object storage
    • Configuration and secrets
  4. How to verify the restored system
  5. How to point traffic (DNS, load balancer) to the restored system

Example: Database disaster recovery checklist

  1. Spin up a new database instance
  2. Download the latest backup from object storage
  3. Restore with pg_restore or equivalent
  4. Apply any necessary schema migrations that are not in the backup
  5. Update application configuration to point to new database
  6. Run smoke tests or health checks
  7. Enable traffic

Practice disaster recovery

Do regular drills:

This also helps you discover:

Backups in Containerized and Cloud-native Environments

With Docker and orchestrators like Kubernetes, the running containers are usually ephemeral. Backups focus on persisted data.

Docker and volumes

When using Docker:

Example pattern:

Kubernetes and cloud services

For Kubernetes:

For cloud-managed databases and object storage:

Cloud-native backups do not remove the need for testing restores.

Integrating Backups into Your Deployment Process

Since this chapter sits in the Deployment section, tie backups into how you ship and run your app:

A simple rule for deployments that touch data:

Never apply irreversible database changes in production without a recent, tested backup and a clear restoration plan.

Even for smaller projects, a minimal practice is:

This discipline makes your backend significantly more resilient and trustworthy.

Views: 6

Comments

Please login to add a comment.

Don't have an account? Register now!

© 2025 Kahibaro
Visitors: 3039 / 24h
Impressum / Imprint
Datenschutz / Data Policy