← Linux administration for operations
10 / 12 · 45 MIN

Recover filesystems and publish data safely

Distinguish mounts, data identity, atomicity, and durability before repairing, publishing, or accepting a restore.

Confirm where writes land

An existing directory does not prove that the expected volume is mounted. Connect the application path to mount source, type, options, and context. findmnt --target identifies the filesystem containing a path; a valid response may be exactly the wrong root filesystem. In an isolated application, the host view may differ from the process view. Define a startup condition representing required mounts and still confirm data identity. RequiresMountsFor helps with dependency and ordering but does not certify that the volume contains the correct operation set or expected version.

Preserve hidden data and actual capacity

If the application wrote into the directory before mounting, the data may become hidden when the correct volume is mounted over it. Do not conclude that it was deleted or experimentally unmount an active service. Preserve both sets, plan controlled access to the underlying view, and reconcile identifiers. When planning copies, distinguish apparent size from allocated space: a sparse file may occupy much less than its logical size. A tool that materializes sparse regions can change capacity requirements. Record measurement units and exercise restoration using the same copying behavior.

Publishing a name does not guarantee persistence

A producer can prepare and validate a temporary file on the destination filesystem before replacing the public name with rename. This controls visibility of the new object, but already-open descriptors may continue reading the old one. Name atomicity does not alone cover abrupt failures: persistence design needs to consider file synchronization, the directory, operation results, and storage guarantees. A checksum checks observed content rather than forcing persistence. If the contract forbids replacing an existing delivery, checking before renaming leaves a race; choose a compatible atomic primitive and handle conflict.

Repair the right format under the right conditions

Filesystem identification comes before tool selection. e2fsck belongs to the ext family; xfs_repair has its own semantics and preconditions. A runbook copied from another service is not compatibility evidence. Plan data protection, device availability, consumer downtime, and recovery if repair fails. Even an inspection without writes on a mounted filesystem may not provide a valid result because the view is changing. On XFS, zeroing the log with -L may lose changes and data; it is not a neutral attempt. Consult the installed version and involve appropriate expertise before executing destructive actions.

Accept the service, not just the files

Write the criterion before the exercise: operation population, recovery interval, dependencies, account identity, and functional checks. If restoration started at 10:00 and 200 of 10000 instructions remain missing at 11:05, a complete-recovery objective of 60 minutes was missed. The API starting at 10:42 is a stage, not the complete outcome. Keep actual timings, pending identifiers, and hypotheses still open. Temporary acceptance of degraded capability should be decided by the appropriate authority with limits and a deadline, without retrospectively changing the measured exercise outcome.

findmnt --target /srv/ledger --output TARGET,SOURCE,FSTYPE,OPTIONS
findmnt --json --target /srv/ledger --output TARGET,SOURCE,FSTYPE,OPTIONS
df -h /srv/ledger
df -i /srv/ledger
IN PRACTICE

Fictional example: 300 files were written on the root filesystem and 900 appear on the dedicated volume. Since identifier overlap has not been analyzed, do not declare 1200 unique deliveries. Containing writes and preserving both sets precede reconciliation and approved resumption.

Common pitfalls

Confusing a directory with a mount, hiding with deletion, apparent size with allocation, rename with persistence, or structural checking with business recovery.

Related topics: Interpret services and logs with systemd · Distinguish space, inodes, and mounts · Interpret CPU, memory, and I/O waiting · Maintenance and demonstrated recovery

Take this idea with you

Identify the object and context, preserve recovery options, and validate data and functionality before declaring success.

Create account

Reference: findmnt(8) · DR Linux 2026.4; networking and Bash manuals reviewed 2026-10-01; cgroup v2 and upstream systemd manuals reviewed 2026-10-01; RHEL 10 examples; Linux man-pages 6.19; OpenSSL 3.5