DATA
PROTECTION

The 3-2-1 Rule

The gold standard of backup strategy:

• 3 copies of your data
• 2 different media types (e.g., external drive + cloud)
• 1 offsite copy (in a different physical location)

Types of Backups

• Full: Complete copy of all data. Slowest to create, fastest to restore.
• Incremental: Only changes since last backup. Fastest to create, slowest to restore (need chain).
• Differential: Changes since last full backup. Balanced approach.

Backup Rotation Schemes

• Grandfather-Father-Son: Daily (son), weekly (father), monthly (grandfather)
• Tower of Hanoi: Complex rotation based on mathematical pattern
• Keep N Days: Keep daily for N days, then delete

What to Back Up

Categorize your data by importance:

Critical (Daily Backup)

• Documents (work, personal)
• Photos and videos
• Source code
• Financial records
• Password databases

Important (Weekly Backup)

• Music collection
• Downloads
• Application data

Replaceable (As Needed)

• Applications (can reinstall)
• Operating system files
• Temporary files

Calculate Your Data Footprint

# Find largest directories
du -sh /* 2>/dev/null | sort -hr | head -20

# Find large files
find /home -type f -size +100M -exec ls -lh {} \;

# Count files by type
find /home -type f | wc -l

Rsync Basics

# Basic rsync syntax
rsync -av /source/ /destination/

# Key options:
# -a: archive mode (preserves permissions, timestamps, etc.)
# -v: verbose
# -h: human-readable sizes
# -n: dry run (don't actually copy)
# --delete: delete files in dest that don't exist in source
# --exclude: exclude patterns

Hard Link Backups

Use rsync with --link-dest for efficient versioning:

#!/bin/bash
# daily-backup.sh
SOURCE="/home/"
DEST="/backup/"
LINK_DEST="$DEST/$(ls -td $DEST/backup-* | head -1)/"

rsync -avh --delete \
    --link-dest="$LINK_DEST" \
    "$SOURCE" "$DEST/backup-$(date +%Y-%m-%d)/"

This creates daily snapshots that only store changed files. Unchanged files are hard-linked.

Simple Backup Script

#!/bin/bash
# backup-home.sh
BACKUP_DIR="/media/backup/backup-$(date +%Y%m%d)"

mkdir -p "$BACKUP_DIR"

rsync -av \
    --exclude='.cache' \
    --exclude='.local/share/Trash' \
    --delete \
    /home/ "$BACKUP_DIR/"

echo "Backup complete: $BACKUP_DIR"

Why Borg?

• Deduplication: Only stores unique data chunks
• Compression: Built-in compression
• Encryption: Client-side encryption
• Backup mount: Mount backups as filesystems

Installing Borg

# Debian/Ubuntu
sudo apt install borgbackup

# macOS
brew install borgbackup

Borg Basic Usage

# Initialize repository (with encryption)
borg init --encryption=repokey /backup/borg-repo

# Create backup
borg create /backup/borg-repo::backup-{now} /home

# List backups
borg list /backup/borg-repo

# Mount backup
borg mount /backup/borg-repo::backup-2024-01-15 /mnt/restore

# Restore
borg extract /backup/borg-repo::backup-2024-01-15 --destination /restore

Borg Automation

#!/bin/bash
# borg-backup.sh
export BORG_PASSPHRASE='your-passphrase'

borg create \
    --compression lz4 \
    --exclude '*/.cache' \
    /backup/borg-repo::daily-{now} \
    /home

# Prune old backups
borg prune \
    --keep-daily=7 \
    --keep-weekly=4 \
    --keep-monthly=12 \
    /backup/borg-repo

Why Restic?

• Simple, clean CLI
• Multiple backends (local, S3, B2, SFTP, etc.)
• Encryption by default
• Deduplication

Restic Setup

# Install
sudo apt install restic

# Initialize repository
restic init --repo /backup/restic

# Or with password file
restic init --repo /backup/restic --password-file /etc/restic/password

Restic Commands

# Backup
restic -r /backup/restic backup /home

# List snapshots
restic -r /backup/restic snapshots

# Restore latest snapshot
restic -r /backup/restic restore latest --target /restore

# Check repository integrity
restic -r /backup/restic check

# Remove old snapshots
restic -r /backup/restic forget --keep-daily 7 --keep-weekly 4 --prune

Restic with Cloud Backends

# Backblaze B2
export B2_ACCOUNT_ID=your-id
export B2_ACCOUNT_KEY=your-key
restic -r b2:bucket-name:/path backup /home

# S3
restic -r s3:https://s3.amazonaws.com/bucket-name backup /home

Why Offsite Matters

Local backups protect against:

• Hardware failure
• Accidental deletion
• Ransomware (if disconnected)

Offsite backups additionally protect against:

• Theft
• Fire/flood/disaster
• Building destruction

Cloud Backup Services

• Backblaze B2: $6/TB/month, excellent for backups
• rsync.net: rsync-friendly, good for Borg/Restic
• Wasabi: $6/TB/month, no egress fees
• AWS S3: More expensive, very reliable

Encrypted Sync

# rsync to remote (over SSH)
rsync -avz -e ssh /local/backup/ user@remote:/backup/

# Use rclone for cloud sync
restic -r s3:backblaze:bucket-name backup /home

# rclone sync
rclone sync /local/ encrypted-remote:backup -v

Understanding RAID

• RAID 0: Striping (fast, no redundancy)
• RAID 1: Mirroring (exact copy)
• RAID 5: Striping + parity (1 drive failure tolerance)
• RAID 6: Double parity (2 drive failures)
• RAID 10: Mirrored + striped

RAID is NOT Backup

• RAID 1: If you delete a file, it's gone on both drives instantly
• RAID: Doesn't protect against controller failure
• RAID: Doesn't help if malware encrypts your data

When to Use RAID

• Uptime is critical (no rebuild time)
• Large datasets with frequent reads
• Combined with backups (RAID + backup = complete protection)

When to Image

• After fresh OS installation
• Before major system changes
• After system is working perfectly

Clonezilla

# Clonezilla live or installed
# Can clone:
# - Disk to disk
# - Partition to partition
# - Disk to image
# - Image to disk

# Command line example:
sudo clonezilla -c -e1 -j2 -md -r -fsck -p choose savedisk example_image sda

Timeshift (Linux)

# Install
sudo apt install timeshift

# Create snapshot via CLI
sudo timeshift --create --comments "Before upgrade" --tags D

# List snapshots
sudo timeshift --list

# Restore
sudo timeshift --restore --snapshot '2024-01-15_10-00'

MySQL/MariaDB

# Single database
mysqldump -u root -p dbname > dbname.sql

# All databases
mysqldump -u root -p --all-databases > alldbs.sql

# With compression
mysqldump -u root -p dbname | gzip > dbname.sql.gz

# Restore
mysql -u root -p dbname < dbname.sql

PostgreSQL

# Single database
pg_dump -U postgres dbname > dbname.sql

# All databases
pg_dumpall -U postgres > all_databases.sql

# Custom format (for point-in-time recovery)
pg_dump -U postgres -Fc dbname > dbname.dump

# Restore
pg_restore -U postgres -d dbname dbname.dump

MongoDB

# Single database
mongodump --db dbname --out /backup/

# With authentication
mongodump --db dbname --out /backup/ -u user -p

# Restore
mongorestore /backup/

Why Testing Matters

A backup you can't restore is useless. Test regularly:

• Verify backup integrity
• Ensure you can actually restore
• Know how long restore takes
• Find problems before you need to restore

Verification Scripts

#!/bin/bash
# verify-backup.sh

# Test Borg backup
borg check /backup/borg-repo

# Test Restic backup
restic -r /backup/restic check

# Test file backup
rsync -avn --checksum /source/ /backup/test-restore/

Document Your Restore Process

• Write step-by-step restore instructions
• Include all commands
• Note any dependencies
• Test periodically

Monitoring Basics

# Check last backup time
ls -la /backup/ | tail -5

# Check backup size change
du -sh /backup/*

# Log backup completion
echo "$(date): Backup complete" >> /var/log/backup.log

Alerting on Failure

#!/bin/bash
# backup-with-alert.sh
LOGFILE=/var/log/backup.log

if borg create /backup/repo::backup-{now} /data 2>> $LOGFILE; then
    echo "$(date): Backup succeeded" | tee -a $LOGFILE
else
    echo "$(date): Backup FAILED" | tee -a $LOGFILE
    # Send alert
    curl -s -X POST https://notify.example.com/webhook -d "message=Backup failed!"
fi

Disaster Recovery Planning

Ask yourself:

• What data can I not afford to lose?
• How fast do I need to recover?
• What disasters am I protecting against?
• Do I have offsite backups?

DR Scenarios

Single File Loss

Restore from latest backup. Time: Minutes.

Hard Drive Failure

Replace drive, restore from backup. Time: Hours.

Ransomware

Disconnect machine, clean install, restore from clean backup. Time: Days.

Building Destruction

Restore from offsite cloud backup to new hardware. Time: Days to weeks.

Conclusion

You've completed the Backup Mastery guide. You now know:

• The 3-2-1 backup rule
• Rsync for simple local backups
• Borg and Restic for advanced deduplication
• Cloud and offsite backup strategies
• RAID vs backup differences
• System imaging techniques
• Database backup methods
• How to test and monitor backups
• Disaster recovery planning

Remember:

• Automate your backups
• Test restores regularly
• Keep an offsite copy
• Document everything