Backups explained: what is saved, how often, and restore time reality

TL;DR — A backup plan is really three decisions: what data is included, how much recent data you can afford to lose, and how long the business can tolerate being partially or fully unavailable. The most useful takeaway: ask for a plain-English backup matrix listing each system, backup frequency, retention period, and expected restore time for one file, one database, and the full application. Reading time: ~7 min

What it is and where it sits

When people say "we have backups," they usually mean a mix of different things:

• Database backups (copies of application data such as customers, orders, settings)
• File/object storage backups (uploads, images, PDFs, exports)
• Server or disk snapshots (point-in-time copies of a whole machine or volume)
• Configuration backups (infrastructure settings, DNS records, firewall rules, app config)
• Code history (usually Git, which is not the same thing as a production backup)

The important point: backups sit beside your live system, not inside it. They are a separate copy stored somewhere else so you can recover after deletion, corruption, ransomware, bad deployments, or infrastructure failure.

In a typical web application, the live request flow looks like this:

Browser
  |
  v
CDN / DNS
  |
  v
Load balancer / web app
  |                \
  |                 \--> Object storage (uploads, reports, images)
  v
Database

Backups usually attach to the data-producing parts of that flow:

Live app ------> Database --------> Backup storage
     \              |
      \             +-------------> Point-in-time logs / WAL
       \
        +---------> Object storage -> Versioning / replication / backup copy

Config repo / IaC -----------------> Git / artifact storage

What it replaces: ideally, backups replace panic. They do not replace high availability (systems designed to stay online during failure), and they do not replace version control. A standby database can keep the app running; a backup helps you recover data from yesterday. Those are different jobs.

Two terms matter when reading any backup promise:

• RPO (Recovery Point Objective: how much recent data you may lose)
• RTO (Recovery Time Objective: how long recovery takes)

If backups run every 24 hours, your RPO is roughly up to 24 hours. If a full restore takes 6 hours, your RTO is at least 6 hours, often longer once testing and DNS cutover are included.

How it actually works

Here is one realistic example: an online portal with a Postgres database, user-uploaded files in object storage, and the application code deployed from Git.

End-to-end example: a bad admin import corrupts customer records at 2:17 PM

1. Normal operation

   • The app writes customer records to Postgres.
   • Users upload PDFs to object storage.
   • Nightly full database backups run at 1:00 AM.
   • Database transaction logs or WAL (write-ahead log: a sequence of changes) are archived every few minutes for point-in-time recovery.
   • Object storage has versioning enabled, so overwritten or deleted files can be recovered.

2. The incident happens

   • At 2:17 PM, an admin imports a CSV with bad mappings.
   • Thousands of records are updated incorrectly.
   • The app is still online, but the data is wrong.

3. The team chooses a recovery target

   • They decide to restore the database to 2:16 PM, one minute before the import.
   • This is possible because they have the 1:00 AM full backup plus the transaction logs from 1:00 AM to 2:16 PM.

4. Restore starts

   • First, the full backup is restored to a new database instance or recovery environment.
   • Then the transaction logs are replayed up to 2:16 PM.
   • This is why restore time is not just "download backup and done." The system may need to rebuild many hours of changes.

5. Validation

   • The team checks row counts, spot-checks customer records, and confirms the bad import is absent.
   • If uploads were also affected, they recover specific file versions from object storage.

6. Cutover

   • The application is pointed to the recovered database, or the recovered data is selectively copied back into production.
   • Users may see read-only mode or a maintenance page during this step.

7. Actual elapsed time

   • Small database (5-20 GB): often 15-60 minutes
   • Mid-size database (100-500 GB): often 1-4 hours
   • Large database (1 TB+): often many hours, especially if logs must be replayed and integrity checks run

That is why "we back up every night" is only half the story. The real question is: restore what, to when, onto where, and how fast?

What usually gets backed up

In a well-run setup, expect a backup inventory like this:

• Primary database: yes, usually daily full backups plus more frequent incremental/log backups
• Uploaded files: yes, via object storage versioning, replication, or scheduled copy jobs
• Application code: usually in Git, but production build artifacts may also need backup
• Secrets/configuration: sometimes; this is often missed unless infrastructure is managed as code
• Third-party SaaS data: often not included unless explicitly exported
• Email inboxes/chat tools/CRM records: usually not part of app backups unless separately contracted
• Logs/analytics: sometimes retained, often on shorter schedules than business data

The common surprise for customers is that backups often cover the app's own database but not every connected service.

When to use it (and when not to)

You need backups for any system where data loss would cost money, time, trust, or compliance trouble. But you may not need the same backup depth everywhere.

You probably do not need heavy whole-server backups if:

• The server can be rebuilt from code and config in under an hour
• No unique data lives on the server itself
• The real source of truth is a managed database and object storage already backed up separately

You probably do need stronger backups if:

• Staff can bulk edit or import records
• You have legal retention requirements
• Ransomware or accidental deletion is a realistic concern
• The app processes orders, bookings, medical, financial, or regulated data

Trade-offs

Every backup benefit has a cost.

• More frequent backups reduce data loss → but cost more storage, network, and operational complexity
• Longer retention helps with audits and slow-discovered mistakes → but increases storage bills and legal/privacy review needs
• Point-in-time recovery gives finer restore options → but restores are more complex and can take longer because logs must be replayed
• Whole-server snapshots are fast to take → but can be bulky, expensive, and less useful than app-aware database backups for precise recovery
• Cross-region or cross-account copies improve disaster resilience → but add transfer cost, setup work, and more things to test
• Immutable backups (cannot be altered easily) improve ransomware resistance → but can slow cleanup and require stricter retention planning

Lock-in is also real. If backups depend heavily on one cloud provider's snapshot format, moving providers later can be slow. A practical compromise is common: provider-native backups for speed, plus periodic exports in standard formats for portability.

In practice

Below are two examples you can adapt or use to ask your agency for the exact equivalent in your environment.

Example 1: Postgres backup schedule with 30-day retention

If your agency manages a Linux server or container platform, a scheduled job may look like this.

⚠️ This creates backups but does not verify they can be restored. Ask for a monthly test restore into a non-production environment; otherwise you only know that files were written, not that recovery works.

#!/usr/bin/env bash
set -euo pipefail
BACKUP_DIR="/var/backups/postgres"
DB_NAME="appdb"
DB_USER="backup_user"
DATE=$(date +%F-%H%M)
mkdir -p "$BACKUP_DIR"
pg_dump -Fc -U "$DB_USER" "$DB_NAME" > "$BACKUP_DIR/${DB_NAME}-${DATE}.dump"
find "$BACKUP_DIR" -type f -name "*.dump" -mtime +30 -delete

What it does: creates a compressed Postgres dump and deletes backup files older than 30 days. Gotcha: pg_dump is a logical backup (table/data export), which is great for many restores but may be slower for very large databases than physical backup tools.

A matching cron entry could be:

0 1 * * * /usr/local/bin/backup-postgres.sh >> /var/log/backup-postgres.log 2>&1

What it does: runs the backup every day at 1:00 AM. Gotcha: if the server timezone is wrong, the job may run at the wrong business hour and affect performance.

Example 2: Restore a Postgres dump into a fresh database

This is the kind of command your agency would run during a recovery drill or incident.

⚠️ Restoring into an existing production database can overwrite or conflict with live data. The safer first step is to restore into a new database named something like appdb_restore_2026_08_10 and validate it before cutover.

createdb -U postgres appdb_restore_2026_08_10
pg_restore -U postgres -d appdb_restore_2026_08_10 /var/backups/postgres/appdb-2026-08-10-0100.dump

What it does: creates a new database and restores the selected backup into it. Gotcha: application users, extensions, and permissions may need to be recreated separately if they are not included the way you expect.

Example 3: Object storage lifecycle rule for version retention

In many provider dashboards, this is under something like Storage → Bucket → Versioning and Lifecycle rules. A generic JSON rule often looks like this:

{
  "Rules": [
    {
      "ID": "keep-noncurrent-versions-90-days",
      "Status": "Enabled",
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 90
      }
    }
  ]
}

What it does: keeps older versions of files for 90 days after they are replaced. Gotcha: versioning protects against deletion and overwrite, but it does not automatically document which version belongs with which database point in time.

For customers without server access, the right ask in your provider dashboard is usually:

• Database service: look for Backups, Automated backups, or Point-in-time recovery
• Object storage: look for Versioning and Lifecycle rules
• VM/block storage: look for Snapshots
• Kubernetes/platform hosting: ask where persistent volumes and managed databases are backed up separately

A useful plain-English question to send your agency is:

Please list each production data store and, for each one, confirm: what is backed up, how often backups run, retention length, where backups are stored, whether point-in-time recovery is enabled, and the expected restore time for (1) one deleted file, (2) one database table or record set, and (3) the full production system.

Further reading

• PostgreSQL Documentation: "Backup and Restore" and "Continuous Archiving and Point-in-Time Recovery"
• AWS Well-Architected Framework: Reliability Pillar
• Google Cloud Architecture Framework: Reliability and Disaster Recovery
• The "Caching" and storage-related chapters of the MDN Web Docs are less relevant here; prefer provider backup docs and database manuals
• Site Reliability Engineering, chapter on Managing Critical State

This article was written by an AI system and published pending human review. Verify anything you intend to act on.