Backup and Recovery Planning: Protect Your Files

A backup and recovery plan answers two numerical questions: RPO (how much data can you afford to lose, measured in time) and RTO (how long can you afford to be down). Define those for each workload, then engineer backwards. A database with a 5-minute RPO needs continuous WAL shipping; a weekly marketing report with a 24-hour RPO needs one nightly job. Pair with the 3-2-1 rule — three copies, on two media types, with one offsite — and test restores quarterly. Most "we have backups" stories end badly because nobody ever practiced the restore.

RPO and RTO: The Starting Numbers

RPO (Recovery Point Objective) = maximum acceptable data loss in time. RTO (Recovery Time Objective) = maximum acceptable downtime.

Examples by workload:

• Production database for an e-commerce site: RPO 5 min, RTO 1 hour
• Customer-facing file uploads: RPO 15 min, RTO 2 hours
• Internal file server: RPO 24 hours, RTO 8 hours
• Email archive: RPO 24 hours, RTO 48 hours
• Marketing analytics: RPO 24 hours, RTO 72 hours

Tighter RPO/RTO costs more. A 5-minute RPO means continuous replication (expensive infrastructure); a 24-hour RPO means one nightly job (cheap). Don't over-engineer — not every workload needs hot standby.

The 3-2-1 Rule Still Works

Three copies of the data, on two different storage types, with one offsite. The 3-2-1 rule predates the cloud and still holds:

• Primary: production storage (S3, EBS, PostgreSQL disk)
• Secondary: backup on different media or in a different region (another S3 bucket with replication, Glacier)
• Tertiary: offsite, ideally different vendor or air-gapped (Backblaze B2, on-prem tape, physical disks in a safe)

The vendor-diversity point matters. A compromised root AWS account can delete all your AWS backups. A secondary in Backblaze, Wasabi, or on-prem survives that scenario. For companies under $50M revenue, a second-vendor copy adds maybe $50-200/month and insures against catastrophic tenant-wide issues.

Full, Incremental, and Synthetic Full

Three backup strategies:

• Full: Copy everything every time. Simple, restore is fast (one file), storage is heavy.
• Incremental: Copy only what's changed since last backup. Storage-efficient, restore requires full + all incrementals.
• Synthetic full: Server-side merge of full + incrementals into a new virtual full. Fast restore from any point.

Modern backup tools (Veeam, Rubrik, restic with prune, BorgBackup) use incremental-forever with synthetic fulls under the hood. The pattern: nightly incremental, weekly synthetic full, retain 30 daily + 12 monthly + 7 yearly copies (grandfather-father-son rotation).

For a 2 TB file server with 5% daily change rate, incremental-forever stores about 3-5 TB total for a year's retention — versus 700+ TB if you did full-nightly.

Encryption Before It Leaves

Backups shouldn't travel or sit unencrypted. Client-side encryption with AES-256-GCM (the default in restic, Borg, Duplicacy, Veeam, and others) ensures the backup host never sees plaintext.

Key management matters more than algorithm choice. A backup encrypted with a key stored in the same AWS account as the backup is theater — an attacker with IAM access gets both. Store keys in:

• AWS KMS with a separate-account key (cross-account decryption)
• HashiCorp Vault in an out-of-band environment
• A hardware security module (YubiKey, HSM) for the root key
• A printed and sealed paper copy for truly critical keys

Rotate regularly (annually), log every use, and test recovery with a rotated key before the rotation takes effect in production.

Immutability: The Ransomware Answer

Ransomware attacks in 2025 commonly target backups first — encrypt the production data, then delete or encrypt the backups to prevent recovery. Immutable backups defeat this.

Implementations:

• S3 Object Lock (Compliance Mode): even root can't delete for the retention period
• Azure Blob immutable storage: similar, enforced at container level
• Veeam Hardened Linux Repository: append-only, SSH-only, no delete API
• Physical tape in a vault: the ultimate air gap

For business-critical data, at least one backup copy should be immutable for the retention period. The incremental cost is usually zero — you were going to retain it anyway. The value when ransomware hits is total.

Testing: The Non-Optional Part

A backup you've never restored isn't a backup; it's hope. Testing schedule by priority:

• Tier 1 (mission-critical): full restore drill quarterly, random file restore monthly
• Tier 2 (business-important): full restore drill semi-annually, random file restore quarterly
• Tier 3 (standard): full restore drill annually, random file restore quarterly

Record in the test:

1. How long did the restore take (compare to RTO)
2. Did the data match the production state (checksums against a known point)
3. Did any permissions or configurations fail to restore
4. What broke and how was it fixed

Companies that skip testing learn about corrupted backups during actual incidents, which is the most expensive time to learn anything.

Database Backups Need Their Own Plan

Files and databases backup differently. A .pgdata directory copied mid-transaction is corrupt. Use native tools:

• PostgreSQL: pg_basebackup + WAL archiving for PITR, pg_dump for logical
• MySQL: Percona XtraBackup for hot physical, mysqldump for logical
• MongoDB: mongodump, replica sets with delayed secondaries
• Microsoft SQL Server: native backup with BACKUP DATABASE, log shipping for PITR

For a 500 GB PostgreSQL database with 5-minute RPO, nightly base backups + continuous WAL archiving to S3 gives you point-in-time recovery to any second in the last 30 days. Restore time: pull the base backup (30 min), replay WAL to target time (5-30 min). Tight RTO means a warm replica ready to promote.

Application-Consistent Snapshots

Filesystem snapshots (ZFS, Btrfs, AWS EBS, Azure managed disks, GCP persistent disk) freeze a point in time at the block level. For databases, combine with application quiesce:

1. pg_start_backup('label') (PostgreSQL) or FLUSH TABLES WITH READ LOCK (MySQL)
2. Take the snapshot
3. pg_stop_backup() or unlock

The snapshot is application-consistent — usable for restore without crash recovery. AWS Backup, Azure Backup, and Google Cloud Backup automate this pattern for common databases.

Distributing Backup Archives to Third Parties

When backups need to go to outside parties — auditors, regulators, successor trustees — the transfer itself needs care. FTP is ancient; email attachments hit size limits; handing over USB drives is slow.

End-to-end encrypted file transfer handles ad-hoc backup distribution cleanly. HexaTransfer moves files up to 10 GB with AES-256-GCM client-side encryption and a one-time link. Good for sending a database snapshot to an auditor without granting them access to your S3 buckets.

Documentation Is Part of the Backup

The best backup in the world is useless if the person who can restore it is on vacation and nobody else knows how. Document:

• What's backed up and what isn't (explicit exclusions)
• Schedule and retention per workload
• Key management and access
• Restore runbooks with step-by-step commands
• Contact list (vendor support, on-call)
• Test results and dates

Print a copy. Store a copy in the physical safe with the emergency keys. If your backup runbook only lives in a Confluence page served from the same infrastructure that just went down, you have a problem. Paper still works when nothing else does.

Define the RPO/RTO, implement 3-2-1 with immutability, encrypt client-side, test quarterly, document obsessively. Backup success is 10% technology and 90% discipline.

Try it at hexatransfer.com — free, no account, 10 GB max.