206.2 Backup operations

Introduction

A backup is useful only if it can satisfy a defined restore. Decide what must be recovered, how much data loss is acceptable, and how quickly service must return before selecting tools.

What you should be able to do after this lesson:

• Identify data and metadata that need protection.
• Compare file, image, incremental, local, remote, and tape backups.
• Create and verify archives and rsync copies.
• Understand tape device behavior.
• Perform test restores and protect backup credentials.

Big Idea: Start with the Restore

“Back up the server” is not a complete requirement. Define the restore unit first: one file, one database, an application, or a bootable machine. That decision determines consistency, retained metadata, catalog requirements, media, frequency, and verification.

Define the Recovery Goal

Two common measures are:

• RPO: maximum acceptable amount of lost recent data
• RTO: maximum acceptable restoration time

These determine frequency, retention, and storage design.

Include configuration, application data, databases, keys, and automation needed to rebuild. Usually exclude reproducible caches and virtual filesystems such as /proc, /sys, and /run.

Archive Backups with tar

tar -czpf etc-backup.tar.gz /etc
tar -tzf etc-backup.tar.gz | head
tar -xzpf etc-backup.tar.gz -C /restore

Preserve permissions and ownership when required. Absolute paths, exclusions, extended attributes, ACLs, and SELinux labels require deliberate handling.

Synchronization with rsync

rsync -aHAX --numeric-ids /srv/data/ backup:/srv/backups/data/

Important behavior:

• a trailing slash on the source means copy its contents
• --delete makes destination removal mirror source removal
• --dry-run previews a risky synchronization

An rsync mirror alone may immediately reproduce accidental deletion. Combine synchronization with snapshots or versioned retention.

Block Images with dd

dd if=/dev/sda of=/backup/disk.img bs=4M status=progress conv=sync,noerror

dd copies blocks and will overwrite the destination without confirmation. Verify if and of carefully. Imaging a live, changing filesystem may not produce application-consistent data.

Tape Concepts

Rewinding devices such as /dev/st0 rewind after an operation; non-rewinding devices such as /dev/nst0 keep position. mt controls tape position and status.

Tape offers offline retention and high sequential capacity but has slower random restore access and requires media management.

CD-R and similar optical media can provide offline, write-once characteristics for small archives but have limited capacity and operational convenience. Disk is fast and easy to automate but remains vulnerable when permanently connected to the same failure or security domain.

Network Backup Systems

Tools such as Amanda, Bacula, Bareos, and BackupPC coordinate schedules, catalogs, clients, and retention. The product matters less than reliable monitoring and tested restores.

Verification and Restore

Verification can include:

• archive listing and checksums
• backup-job exit status and logs
• comparing selected files
• restoring into an isolated location
• booting or starting the restored service

Follow the 3-2-1 principle where practical: multiple copies, different media or failure domains, and at least one off-site or offline copy.

Guided Practice: Back Up and Restore a Small Tree

Create a disposable source tree as a normal user:

mkdir -p /tmp/lpic-backup/source/config
printf 'enabled=true\n' > /tmp/lpic-backup/source/config/app.conf
printf 'important data\n' > /tmp/lpic-backup/source/data.txt
tar -czpf /tmp/lpic-backup/archive.tar.gz -C /tmp/lpic-backup/source .
tar -tzf /tmp/lpic-backup/archive.tar.gz
sha256sum /tmp/lpic-backup/archive.tar.gz

Restore somewhere else rather than over the source:

mkdir -p /tmp/lpic-backup/restore
tar -xzpf /tmp/lpic-backup/archive.tar.gz -C /tmp/lpic-backup/restore
diff -ru /tmp/lpic-backup/source /tmp/lpic-backup/restore

The archive listing proves readability; the isolated restore and comparison prove more. Extend the exercise by changing the source and previewing an rsync -a --delete --dry-run so deletion behavior is visible before execution.

Troubleshooting Scenario

A nightly rsync job exits successfully, but ransomware-encrypted files from the source immediately replace the good destination copies.

The mirror worked exactly as configured but had no historical retention or isolated copy. Recover from an offline or versioned backup, protect backup credentials and deletion rights, and add restore tests. Synchronization alone is not a complete backup design.

Exam Focus

• Know what system directories and application data are required for the intended restore.
• Compare tar, rsync, dd, tape devices, optical media, and disks.
• Recognize /dev/st*, /dev/nst*, mt, and network backup systems such as Amanda, Bacula, Bareos, and BackupPC.
• Verification must include an actual partial or full restore.

Recap

• Design from RPO and RTO, not from a favorite command.
• Synchronization, versioned backup, and block imaging solve different problems.
• Protect keys and catalogs needed for restoration.
• A successful test restore is stronger evidence than a successful backup log.