Skip to content

Restore a Backup Before You Need It

A successful backup command is not enough: check that you can restore the intended data into a new destination and use it. Start with disposable files, not a destructive rehearsal on your only working service.

Outcome: create a small archive, restore it to a fresh directory, and verify restored content and mode. You need Bash, GNU tar and coreutils on the Pi. Complete the isolation lesson first or begin with basic file-management skills. This lab contains no real credentials or valuable data.

Know what each protection does

Permissions decide which accounts may access a file. Encryption protects data under a key and threat model. A backup supplies another recoverable copy. None automatically replaces the others.

An archive beside the original on the same disk is useful for this exercise, not an independent disaster-recovery backup. A real plan must account for disk failure, deletion, ransomware, theft and recovery-key loss as applicable. The protection worksheet helps name those risks.

Run the complete disposable restore lab

Run the whole block as your ordinary user on the Pi. It creates a fresh private directory and never extracts over existing project/system files:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
(
    set -eu
    set -o noclobber
    umask 077
    restore_lab=$(mktemp -d /tmp/pi-security-restore.XXXXXXXX)
    printf 'Practice directory: %s\n' "$restore_lab"
    mkdir "$restore_lab/source" "$restore_lab/restored"
    printf 'Disposable settings: sample-rate=5\n' > "$restore_lab/source/settings.txt"
    chmod 600 "$restore_lab/source/settings.txt"

    tar -cz -C "$restore_lab/source" settings.txt > "$restore_lab/settings.tar.gz"
    (cd "$restore_lab" && sha256sum settings.tar.gz > SHA256SUMS)
    (cd "$restore_lab" && sha256sum -c SHA256SUMS)
    tar -tzf "$restore_lab/settings.tar.gz"
    tar -xzf "$restore_lab/settings.tar.gz" -C "$restore_lab/restored"

    cmp "$restore_lab/source/settings.txt" "$restore_lab/restored/settings.txt"
    test "$(stat -c %a "$restore_lab/restored/settings.txt")" = 600
    printf 'PASS: restored content and mode match the disposable source.\n'
    cat "$restore_lab/restored/settings.txt"
)

Expect settings.tar.gz: OK, an archive listing containing settings.txt, the PASS message and the sample line. cmp is normally silent when files match. Any earlier error means the test is incomplete, even if a partial archive exists.

Each run uses a new directory. The checksum records archive bytes, the listing confirms what is present, and the restore/content/mode checks verify the limited result we actually need. A checksum alone does not prove that a backup contains the right files.

Why this extraction is bounded

The archive was created by you immediately before extraction, with one known relative member, and the destination is new and empty. This is not permission to extract an arbitrary downloaded archive into /, your home directory, or a live project. Untrusted archive members, links and existing destinations require a different review.

The GNU tar manual explains extraction and its options. Do not add sudo simply to get an unfamiliar archive to extract. This lab intentionally does not restore ownership across users or exercise ACLs, extended attributes or a running database.

Practise a failure without risking the source

If the archive is damaged, checksum or extraction failure should stop this block before a success message. If the destination is wrong, a successful extraction can still be operationally wrong; inspect the actual result. Do not “recover” by overwriting a working directory before testing a separate restore.

To repeat, rerun the block rather than reusing a previous directory. To clean up, inspect the printed lab path and remove only its known sample files/archive/checksum and empty subdirectories. A file manager is sufficient. Do not recursively delete /tmp, a home directory or a real backup mount. Keeping this small private lab for later review is also reasonable.

Make a real recovery plan

For each application, record data locations, configuration, secrets, software versions, account IDs, backup consistency requirements, and a usable restore procedure. A live database directory cannot be assumed equivalent to a database-aware export. Keep encryption/recovery keys accessible to the authorized restorer without storing the only copy beside the protected device.

Use an independent destination with appropriate access and encryption, and test restoration without connecting the rehearsal to production data or sending real notifications. Measure whether the time and data loss meet your needs. The backup strategy guide and migration guide cover broader planning.

Finish the learning path

Return to your original worksheet. Can you now explain the running software, permitted accounts, reachable services, workload boundaries and recovery route? Choose one remaining question to investigate rather than applying every hardening option at once.

Checkpoint: why can a valid checksum coexist with an incomplete backup? Why does this same-disk lab not protect against a failed boot disk?

This completes the first practical pass through the six Security areas, not an audit or a guarantee against compromise. Continue with optional CVE case studies, the TPM introduction, or return to Security.

The disposable file restore and mode check passed on the verification Pi; see the verification scope. No real application database or failed disk was restored.

Donate