What Backup Strategies Would You Use in Production?
Learn production backup strategies — full vs incremental, RPO/RTO, and the 3-2-1 rule — with a DevOps interview-ready answer.
Expected Interview Answer
A production backup strategy combines full, incremental, and differential backups on a schedule driven by Recovery Point Objective (RPO) and Recovery Time Objective (RTO), stored across at least two independent locations following the 3-2-1 rule, with regular restore drills to prove the backups actually work.
A full backup captures the entire dataset and is the baseline; incremental backups capture only changes since the last backup of any type, minimizing storage and transfer time but requiring the full chain to restore; differential backups capture changes since the last full backup, trading more storage for a simpler, faster restore path. The 3-2-1 rule says keep at least three copies of data, on two different media types, with one copy offsite or in a different cloud region, so a single failure domain (a disk, a rack, a region) cannot destroy every copy. RPO defines how much data loss is acceptable, which sets backup frequency, while RTO defines how quickly the system must be restored, which drives whether you need warm standbys, snapshots, or cold archival storage. Backups must be encrypted at rest and in transit, access-controlled separately from production credentials so a compromised production account cannot also delete backups, and periodically test-restored end to end, because an untested backup is not a real backup.
- Bounds data loss to a known, agreed RPO window
- Bounds downtime to a known, agreed RTO window
- Protects against ransomware, human error, and regional outages
- Builds organizational confidence through proven, tested restores
AI Mentor Explanation
A team keeps a full scorebook after every innings (the full backup), then only jots down the runs and wickets since the last entry during play (incremental). They also keep a duplicate scorebook in the coach’s bag and a photo of it on a phone stored in a different city, so a fire in the pavilion cannot destroy every record. Before a big final, the analyst deliberately tries reconstructing a past innings purely from the backup entries to make sure the process actually works, because a scorebook nobody has ever rebuilt from is not trustworthy.
Step-by-Step Explanation
Step 1
Set RPO and RTO
Agree with stakeholders how much data loss and downtime is acceptable; this drives backup frequency and restore tooling.
Step 2
Choose backup types and schedule
Combine full, incremental, and/or differential backups on a cadence that meets the RPO without overloading storage or network.
Step 3
Apply the 3-2-1 rule
Keep three copies, on two media types, with one copy offsite or in a separate cloud region/account from production.
Step 4
Test restores regularly
Schedule real restore drills into a sandbox environment and measure whether the achieved RTO/RPO actually meets targets.
What Interviewer Expects
- Distinction between full, incremental, and differential backups
- Understanding of RPO vs RTO and how they drive backup design
- Knowledge of the 3-2-1 rule and offsite/immutable copies for ransomware protection
- Emphasis that untested backups are not a real disaster-recovery plan
Common Mistakes
- Only taking backups without ever testing a restore
- Storing every backup copy in the same account/region as production
- Confusing RPO (data loss tolerance) with RTO (downtime tolerance)
- Giving production credentials the ability to delete backup copies too
Best Answer (HR Friendly)
“We design backups around two numbers: how much data we can afford to lose, and how fast we need to be back up. From there we pick a mix of full and incremental backups, keep copies in at least two separate places so one failure cannot wipe everything, and — most importantly — we regularly practice restoring from those backups so we are confident they actually work when it matters.”
Code Example
#!/usr/bin/env bash
set -euo pipefail
STAMP=$(date +%Y%m%d-%H%M%S)
BACKUP_FILE="/backups/pg-full-${STAMP}.sql.gz"
# Full logical backup
pg_dump -Fc mydb | gzip > "$BACKUP_FILE"
# Upload to a separate cloud region/account (3-2-1 offsite copy)
aws s3 cp "$BACKUP_FILE" s3://dr-backups-eu-west/postgres/ --region eu-west-1
# Periodic restore drill into an isolated sandbox database
if [ "$(date +%u)" = "7" ]; then
pg_restore -d restore_drill_db "$BACKUP_FILE"
echo "Restore drill completed for ${STAMP}"
fiFollow-up Questions
- What is the difference between incremental and differential backups?
- How would you protect backups from a ransomware attack that also targets backup storage?
- How do you decide backup frequency for a system with a 15-minute RPO?
- What would you monitor to know if a backup job silently failed?
MCQ Practice
1. What does RPO define in a backup strategy?
RPO (Recovery Point Objective) defines the maximum acceptable data loss, which directly determines how often backups must run.
2. What does the 3-2-1 backup rule recommend?
The 3-2-1 rule is three total copies of data, across two different media types, with at least one copy stored offsite or in a separate region.
3. Why must backups be periodically restored, not just taken?
A backup that has never been restored is unproven; corruption, missing files, or broken restore tooling only surface during an actual restore attempt.
Flash Cards
RPO vs RTO? — RPO = acceptable data loss window (drives backup frequency); RTO = acceptable downtime window (drives restore speed/tooling).
What is the 3-2-1 rule? — Three copies of data, on two media types, with one copy offsite.
Incremental vs differential backup? — Incremental captures changes since the last backup of any kind; differential captures changes since the last full backup.
Why test restores? — A backup is only proven trustworthy once a real restore from it has been successfully performed.