Backup & Disaster Recovery

Design backups using tar and rsync, and plan recovery against RPO/RTO targets.

Data protection is judged on recovery, not on having copies. This chapter covers practical backup tooling, the 3-2-1 rule, and recovery planning around the RPO and RTO metrics that the business cares about.

By the end of this chapter you will be able to

Create archive and mirror backups with tar and rsync.
Apply the 3-2-1 rule and incremental strategies.
Define and meet RPO and RTO targets.
Schedule and offsite backups securely.
Validate backups through tested restores.

15.1 tar and rsync

Archive (tar) and mirror (rsync)
# Snapshot a folder into a compressed archive
tar -czf etc-$(date +%F).tar.gz /etc
 
# Efficiently mirror a folder (only changes copied)
rsync -a --delete /var/www/ /backup/www/
 
# Mirror offsite over SSH
rsync -a /srv/data/ deploy@dr-host:/backups/data/

15.2 The 3-2-1 Rule

The industry standard for resilience: 3 copies of your data, on 2 different types of media, with 1 copy offsite.

15.3 Recovery Objectives

Term	Question it answers
RPO (Recovery Point)	How much data can we afford to lose? (Sets backup frequency.)
RTO (Recovery Time)	How fast must we be back? (Sets recovery design.)

15.4 Scheduling and Verification

Automate and check

# Daily 1 AM backup via cron, logged
0 1 * * * /opt/backup.sh >> /var/log/backup.log 2>&1
 
# Verify an archive's integrity
gzip -t backup.tar.gz
# List contents to confirm completeness
tar -tzf backup.tar.gz | head

15.5 Guided Lab: Backup and Verified Restore

Estimated time: 30 minutes. Create a backup, simulate loss, and restore — proving the whole cycle works.

Create sample data: mkdir -p ~/work && echo important > ~/work/data.txt.
Back it up with a timestamp: tar -czf ~/work-$(date +%F).tar.gz -C ~ work.
Verify the archive: gzip -t ~/work-*.tar.gz and list it with tar -tzf.
Simulate disaster: rm -rf ~/work.
Restore from the archive: tar -xzf ~/work-*.tar.gz -C ~.
Confirm recovery: cat ~/work/data.txt shows ‘important’.
Set up an rsync mirror to a second folder and re-run it after a change to see only the delta copy.

Troubleshooting

Symptom	Likely cause and fix
Backup runs but restore fails	Untested backup. Always do periodic test restores. Check that the archive isn’t truncated (gzip -t) and that you backed up the right paths.
Disk fills up with backups	No rotation. Keep N recent backups and delete older ones; use incrementals; compress; move old copies offsite.
rsync deleted files I wanted	–delete mirrors deletions. Use it deliberately; for archival keep versions or snapshots instead of a pure mirror.
Restore is too slow to meet RTO	Recovery wasn’t designed for the target. Use faster media, warm standbys, or automation; rehearse to measure real RTO.

Practice & Prove It

Write-the-command drills

Create a gzip-compressed tar archive of /etc named etc-backup.tar.gz.
Mirror /var/www to /backup/www, preserving metadata and deleting removed files.
Mirror /srv/data offsite to deploy@dr-host:/backups/data over SSH.
Verify the integrity of backup.tar.gz without extracting it.
Create a timestamped compressed backup of /etc using the date in the filename.

Quick quiz

What does the 3-2-1 rule say?
What does RPO define?
What does RTO define?
Why is an offsite copy essential?
What is the one step people skip that makes backups worthless?

Key Takeaways

tar makes point-in-time archives; rsync keeps efficient mirrors — most setups use both.
Follow 3-2-1: three copies, two media types, one offsite.
RPO sets how often you back up; RTO sets how fast you must recover.
Automate and log backups, and verify archive integrity.
A backup is only real once you’ve performed a tested restore.

Next — Chapter 16: systematic troubleshooting methodology.