Linux / Intermediate: system administration reasoning / Lesson 12

Understand storage and test restoration

Connect filesystems, mounts, capacity, archives, and backup recovery without experimenting on real disks.

About 4 min readContent reviewed 2026-10-23

On this page

Lesson goals

Distinguish devices, filesystems, and mount points.
Investigate byte capacity and inode availability.
Design backups around verified restoration.

A pathname sits above several storage layers

A block device can contain partitions, logical volumes, encryption layers, and filesystems. A filesystem organizes files; a mount attaches its directory tree at a pathname. Mounting over a nonempty directory hides those original entries until the mount is removed; it does not delete them. lsblk describes block relationships, while findmnt describes the currently mounted view. Network and memory-backed filesystems do not necessarily correspond to local disks. Never infer a formatting target from a remembered device name, because discovery order and virtual-machine configuration can change.

Capacity has more than one limit

df reports filesystem allocation and available space for a selected path; du estimates usage reachable through directory entries. They answer different questions and can disagree. A deleted file that remains open can consume blocks without appearing in a directory walk. Reserved blocks, snapshots, compression, sparse files, and permission limits also affect comparisons. Many filesystems also limit inode availability, so millions of tiny files can exhaust object slots while bytes remain. Use df -i where supported and avoid assuming that deleting one large file fixes every no-space error.

bash Identify the filesystem for a lab path

findmnt --target /tmp
df -h /tmp
df -i /tmp

These read-only commands map /tmp to its mount and show byte and inode information where supported. Actual capacities are machine-specific and are not example constants.

Persistent mounts need stable identity

/etc/fstab describes intended filesystem mounts on many distributions. UUID-based identifiers can be more stable than changing device names, but cloning a filesystem can duplicate identifiers and require review. Options influence behavior such as read-only access and whether execution or device interpretation is permitted. A bad required mount can interrupt boot, so review documentation and recovery access before changing persistent entries. Filesystem checks and repair have filesystem-specific prerequisites and may require an unmounted volume. This course studies the decision process and never runs a repair or formatting command on the host.

An archive is a transport container

tar can package a directory tree into one archive, but creating the archive is only the first step. Decide which ownership, permissions, links, ACLs, and extended attributes must survive; options and restore privileges matter. An archive of changing application files may be internally inconsistent, especially for databases. Use the application’s supported export or snapshot coordination mechanism. Before extraction, inspect member names and use a new directory because an untrusted archive can contain dangerous paths or links. A checksum detects changed bytes against a trusted value; it does not establish provenance by itself.

bash Create and verify a synthetic archive restoration

lab=$(mktemp -d)
mkdir "$lab/source" "$lab/restore"
printf '%s\n' 'synthetic record' > "$lab/source/note.txt"
tar -cf "$lab/notes.tar" -C "$lab/source" note.txt
tar -tf "$lab/notes.tar"
tar -xf "$lab/notes.tar" -C "$lab/restore"
cmp "$lab/source/note.txt" "$lab/restore/note.txt"

The archive contains only note.txt created by this example. cmp prints nothing and returns zero when restored bytes match. This demonstrates content restoration, not every metadata guarantee.

A backup succeeds when restoration succeeds

Define what data matters, how much recent work may be lost, and how quickly service must return. Keep independent copies across failure domains; a second directory on the same failing disk is weak protection. Encryption protects confidentiality only if recovery keys remain available to authorized people. Schedule restore drills into an isolated destination, verify both content and required metadata, and check that the application can use the restored state. Record failures and retention decisions. A green backup job without a demonstrated restore path is incomplete operational evidence.

Common errors and fixes

df and du are assumed interchangeable

Why it happens: Filesystem allocation was confused with reachable file usage.
How to fix it: Check mount boundaries, open deleted files, and filesystem features.
Prevent it next time: State what each measurement includes.

Free bytes hide inode exhaustion

Why it happens: Only byte availability was inspected.
How to fix it: Inspect inode usage on the affected filesystem.
Prevent it next time: Monitor object counts and retention of small files.

Backup archive exists but cannot restore

Why it happens: Creation was verified without data or metadata recovery.
How to fix it: Run an isolated restore drill and inspect its result.
Prevent it next time: Make restore verification part of the backup contract.

Check your understanding

1. A million small files trigger no-space errors despite free gigabytes. What should be checked?

Show worked solution

Identify the filesystem containing the failing path and inspect inode availability, quotas, and applicable limits. If inodes are exhausted, investigate the file-producing process and retention policy. Freeing a large file may release many bytes but only one inode.

2. What must a restore drill prove beyond tar successfully listing an archive?