dotlinux guide

The Complete Guide to Linux System Backups and Restores

In the world of Linux administration, data is the lifeblood of systems—whether it’s user files, application configurations, or critical system directories. Yet, data loss can strike unexpectedly: hardware failures, human error, ransomware attacks, or even accidental deletions. A robust backup and restore strategy is not just a best practice; it’s a critical line of defense against disaster. This guide demystifies Linux system backups and restores, covering fundamental concepts, essential tools, step-by-step workflows, and industry best practices. By the end, you’ll have the knowledge to design, implement, and maintain a reliable backup system tailored to your Linux environment.

Table of Contents

  1. Fundamental Concepts
  2. Essential Linux Backup Tools
  3. Step-by-Step Backup & Restore Workflows
  4. Common Practices
  5. Best Practices
  6. Troubleshooting Common Issues
  7. Conclusion
  8. References

Fundamental Concepts

Types of Backups

Understanding backup types helps you choose the right strategy for your needs:

  • Full Backup: Copies all selected data.
    Pros: Simple to restore. Cons: Time/space-intensive.
    Use Case: Baseline for incremental/differential backups.

  • Incremental Backup: Copies only data changed since the last backup (full or incremental).
    Pros: Fast, space-efficient. Cons: Restores require multiple backups (full + all incrementals).
    Use Case: Daily backups after a weekly full backup.

  • Differential Backup: Copies data changed since the last full backup.
    Pros: Faster than full, simpler restore (full + latest differential). Cons: Larger than incrementals over time.
    Use Case: Balancing speed and restore simplicity.

Key Terminology

  • Backup Target: Where backups are stored (e.g., external HDD, cloud, NAS).
  • RPO (Recovery Point Objective): Maximum acceptable data loss (e.g., 1 hour).
  • RTO (Recovery Time Objective): Maximum acceptable downtime (e.g., 4 hours).
  • Snapshot: Point-in-time copy of a filesystem (e.g., LVM, btrfs snapshots).
  • Deduplication: Eliminates redundant data to save space (e.g., BorgBackup).

Backup vs. Restore: Why Both Matter

A backup is only useful if you can restore from it. Many admins focus on creating backups but neglect testing restores—this is a critical mistake. Always validate that backups are intact and restores work as expected.

Essential Linux Backup Tools

Command-Line Tools (The Workhorses)

Linux excels at command-line backups—flexible, scriptable, and lightweight.

1. rsync (File-Level Synchronization)

rsync is a Swiss Army knife for backups, using delta-transfer to sync only changed files.
Use Case: Local/remote file backups, incremental syncs.

Basic Syntax:

rsync -av --delete /source/directory/ /backup/directory/
  • -a: Archive mode (preserves permissions, timestamps).
  • -v: Verbose output.
  • --delete: Remove files in backup that no longer exist in source.

Example: Backup /home to External Drive

# Mount external drive (verify with lsblk)
mount /dev/sdb1 /mnt/backup-drive

# Sync /home to the drive (incremental by default)
rsync -av --exclude=".cache" /home/ /mnt/backup-drive/home-backup/

# Unmount when done
umount /mnt/backup-drive

2. tar (Archiving)

tar creates compressed archives (e.g., .tar.gz, .tar.xz). Ideal for full system or directory backups.
Use Case: Offline archives, transferring backups.

Example: Create a Compressed Archive

# Backup /etc and /var/log to a gzip archive
tar cvzf /backups/system-$(date +%Y%m%d).tar.gz /etc /var/log
  • -c: Create archive.
  • -v: Verbose.
  • -z: Compress with gzip.
  • -f: Specify output file.

Verify Archive Integrity:

tar tvzf /backups/system-20240101.tar.gz  # List contents
tar xvzf /backups/system-20240101.tar.gz --verify  # Verify during extraction

3. dd (Block-Level Cloning)

dd copies raw data at the block level (e.g., disks, partitions).
Use Case: Disk cloning, full partition backups.

Warning: dd is powerful—incorrect device names (e.g., /dev/sda instead of /dev/sdb) can erase data!

Example: Clone a Disk to Image

# Create a disk image (replace sda with your source disk; run as root)
dd if=/dev/sda of=/backups/disk-image-$(date +%Y%m%d).img bs=4M status=progress

# Restore from image to a new disk (replace sdb with target disk)
dd if=/backups/disk-image-20240101.img of=/dev/sdb bs=4M status=progress

4. BorgBackup (Encrypted, Deduplicated Backups)

BorgBackup (or borg) combines encryption, deduplication, and compression. Perfect for secure, space-efficient backups.
Use Case: Encrypted offsite backups, versioned archives.

Example: Initialize a Borg Repository

# Install borg (Debian/Ubuntu: sudo apt install borgbackup)
borg init --encryption=repokey /mnt/backup-drive/borg-repo

Create a Backup (Archive)

borg create --compression zstd /mnt/backup-drive/borg-repo::"backup-{now:%Y%m%d}" /home /etc

Restore a File

borg extract /mnt/backup-drive/borg-repo::backup-20240101 home/user/documents/important-file.txt

Graphical Tools (User-Friendly)

For desktop users or those preferring GUIs, these tools simplify backups:

1. Timeshift (System Restore Points)

Timeshift mimics Windows System Restore, creating snapshots of the OS (excludes user files by default). Uses rsync or btrfs/LVM snapshots under the hood.
Use Case: Recovering from OS misconfigurations or failed updates.

Workflow:

  1. Open Timeshift → Select snapshot type (rsync/btrfs).
  2. Set backup location (external drive, network share).
  3. Schedule snapshots (e.g., daily, weekly).
  4. To restore: Boot from live USB → Open Timeshift → Select snapshot → Restore.

2. Deja Dup (GNOME Backup Tool)

Deja Dup is a simple GUI wrapper for duplicity, supporting encrypted cloud/local backups.
Use Case: Desktop user file backups (e.g., /home).

Step-by-Step Backup & Restore Workflows

1. System-Level Backup with dd (Disaster Recovery)

Scenario: Clone an entire disk for full system recovery.

Step 1: Identify the Disk

lsblk  # List disks (e.g., /dev/sda is the main disk)

Step 2: Create Disk Image

sudo dd if=/dev/sda of=/mnt/external-drive/full-system-backup.img bs=4M status=progress

Step 3: Restore to a New Disk
Boot from a live Linux USB, then:

sudo dd if=/mnt/external-drive/full-system-backup.img of=/dev/sda bs=4M status=progress

2. Incremental Backup with rsync + cron (Automated)

Scenario: Daily incremental backups of /home to a NAS.

Step 1: Create a Backup Script
Save as ~/scripts/home-backup.sh:

#!/bin/bash
BACKUP_SRC="/home"
BACKUP_DEST="/mnt/nas/home-backups"
DATE=$(date +%Y%m%d)

# Create hard-link-based incremental backup (uses --link-dest)
rsync -av --link-dest="$BACKUP_DEST/latest" "$BACKUP_SRC" "$BACKUP_DEST/$DATE"

# Update "latest" symlink to point to the new backup
ln -snf "$BACKUP_DEST/$DATE" "$BACKUP_DEST/latest"

Step 2: Make It Executable

chmod +x ~/scripts/home-backup.sh

Step 3: Schedule with cron
Run crontab -e and add:

# Run daily at 2 AM
0 2 * * * /home/user/scripts/home-backup.sh >> /var/log/home-backup.log 2>&1

3. Encrypted Backup with BorgBackup

Scenario: Securely back up to an offsite server with encryption.

Step 1: Initialize Remote Repo

borg init --encryption=repokey user@remote-server:/path/to/borg-repo

Step 2: Create Encrypted Backup

borg create --compression zstd user@remote-server:/path/to/borg-repo::"backup-{now:%Y%m%d}" /home /etc

(Enter the repo passphrase when prompted.)

Step 3: List Backups

borg list user@remote-server:/path/to/borg-repo

Step 4: Restore a Directory

borg extract user@remote-server:/path/to/borg-repo::backup-20240101 home/user/documents/

Common Practices

Scheduling Backups

Automate backups to avoid human error. Use:

  • cron: Simple time-based scheduling (e.g., daily/weekly jobs).
  • systemd-timers: More powerful alternative to cron (for complex schedules).
  • Tools like anacron: For systems that aren’t always running (e.g., laptops).

Storing Backups Securely

  • Offsite Storage: Use cloud providers (AWS S3, Backblaze B2) or a remote server.
  • Encryption: Encrypt backups at rest (e.g., Borg’s built-in encryption, gpg with tar).
    Example with gpg:
    # Encrypt a tar archive with a password
    tar cvzf - /home | gpg -c > /backups/home-$(date +%Y%m%d).tar.gz.gpg
    
    # Decrypt and extract
    gpg -d /backups/home-20240101.tar.gz.gpg | tar xvzf -

Testing Restores

Critical: Backups are useless if restores fail. Test monthly:

  • File-Level: Restore a single file to a temporary directory.
  • System-Level: Restore a VM or spare disk to verify bootability.

Example Borg restore test:

# Restore "important-file.txt" to /tmp/test-restore
borg extract --exclude='*' --include='home/user/important-file.txt' \
  user@remote-server:/path/to/borg-repo::backup-20240101 \
  --destination /tmp/test-restore

Best Practices

The 3-2-1 Rule

A golden rule for backup redundancy:

  • 3 Copies of data (original + 2 backups).
  • 2 Different Media (e.g., internal HDD + external SSD).
  • 1 Offsite Copy (protects against theft/fire).

Versioning & Retention Policies

  • Versioning: Keep multiple backup versions (e.g., daily for 1 week, weekly for 1 month).
  • Retention: Automatically prune old backups (e.g., Borg’s borg prune):
    # Keep daily backups for 7 days, weekly for 4 weeks, monthly for 6 months
    borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 \
      user@remote-server:/path/to/borg-repo

Minimizing Downtime

  • Use Snapshots: For live filesystems (e.g., databases), create a read-only snapshot first:
    # LVM snapshot example
    lvcreate --size 10G --snapshot --name root-snap /dev/ubuntu-vg/root
    mount /dev/ubuntu-vg/root-snap /mnt/snap
    rsync -av /mnt/snap /backup/  # Backup from snapshot
    umount /mnt/snap
    lvremove -y /dev/ubuntu-vg/root-snap
  • Avoid Peak Hours: Schedule backups during low traffic (e.g., midnight).

Troubleshooting Common Issues

Backup Fails: “No Space Left”

  • Check Target Free Space: df -h /backup/dest.
  • Enable Deduplication: Use Borg or rsync --link-dest to reduce size.

Corrupted Backup

  • Verify Integrity: Use rsync --checksum, tar --verify, or borg check.
    borg check user@remote-server:/path/to/borg-repo  # Check Borg repo integrity

Restore Takes Too Long

  • Use Incremental/Differential Backups: Avoid restoring from full backups if possible.
  • Parallelize Restores: Tools like borg support --jobs for faster extraction.

Conclusion

Linux backups are a cornerstone of system reliability. By combining the right tools (rsync, borg, dd), following the 3-2-1 rule, automating with cron, and testing restores, you can sleep easy knowing your data is safe. Remember: A backup is only as good as its restore. Start small, iterate, and make backups a habit!

References