Backup concepts - what to back up and how · Linux

Backup is the safety net for every other control. Without backups, a disk failure is a service failure. This lesson covers the basics.

What to back up

For every host:

System configuration: /etc, /usr/local/etc, anything installed outside the package manager.
Application data: databases, document stores, user uploads.
Logs and audit: may be required for compliance.
Secrets: certificates, keys, passwords (encrypted).

For clusters:

Service configuration: same as host.
Persistent data: same as host.
Cluster state: membership, consensus state.

File backup vs application backup

File backup: copy files. Fast for static data, but inconsistent for databases (data may be mid-write).

Application backup: the application produces a consistent snapshot (e.g. PostgreSQL’s pg_dump or filesystem snapshot with FLUSH). Slower but correct.

For databases, use application backup. For static files, file backup is fine.

Backup types

Full: copies everything. Slow, large.
Incremental: copies what changed since the last backup - of any kind. Fast, small.
Differential: copies what changed since the last full backup. Larger each day, but the restore is always a two-archive operation no matter how many days have passed.

The backup type decides the restore procedure, so read the two together:

Weekly full + daily incremental: restore the full, then every incremental in order, up to seven archives. Smallest backups, longest and most fragile restore. Lose or skip one link in the chain and the result is wrong.
Weekly full + daily differential: restore the full, then the last differential only. Two archives. Larger backups, much faster and safer restore.

Choose differential when RTO matters more than backup storage.

Do not apply the differential restore rule to incrementals

“Restore the full, then the latest one” is the differential rule. Applied to a weekly-full-plus-daily-incremental schedule it quietly discards up to six days of data.

Follow the arithmetic. Each incremental holds only that day’s delta, because each was taken against the previous day, not against the full. Restoring Sunday’s full plus Saturday’s incremental gives you Sunday’s data with Saturday’s changes layered on and nothing from Monday to Friday.

What makes this dangerous is that it looks like a success. The tooling exits zero, the directory is populated, the service starts. The gap surfaces days later when users report missing files, by which time retention may have pruned the incrementals you needed. Verify a restore by comparison - a file count and a checksum manifest taken at backup time - not by whether the command succeeded.

Retention

How long to keep backups:

Operational: 1-7 days. For operator errors (delete the wrong file).
Operational recovery: 1-4 weeks. For ransomware or mass corruption.
Compliance: 1-7 years. Per regulatory requirement.

Different storage tiers for different retention:

Hot (1-7 days): SSD, fast access.
Cold (1-12 weeks): HDD, slower.
Archive (1-7 years): S3 Glacier, compliance only.

Backup vs disaster recovery

Backup is a copy of data, often on a separate disk or host. DR is the plan for restoring service after a major event (data center loss, ransomware, etc).

Backup is a component of DR, not the whole thing. DR includes:

Backups (offsite, immutable).
Runbooks for restore.
Tested procedures.
Communication plan.
Cross-team coordination.