XFS recovery planning
XFS can shut down a filesystem after detecting inconsistent metadata, checksum errors, I/O failures, or an unreplayable log. The safest path depends on both the filesystem state and the storage underneath it.
Understand the symptom
XFS uses a journal to replay recent metadata operations and checksums to detect invalid structures. A forced shutdown message may protect the filesystem from further writes. Repair utilities can rebuild consistency, but consistency is not the same as preserving every original name, path, or transaction. When XFS sits on LVM, RAID, SAN, or virtual storage, the entire stack and correct offsets must be mapped before repair.
What you may see
Kernel logs may name a directory, inode, btree, or buffer verifier that rejected stored metadata.
XFS can stop access after detecting corruption or persistent I/O errors.
The filesystem may require the original device to replay a valid journal before ordinary repair can proceed.
Underlying media or thin-pool problems can prevent a filesystem-only tool from completing safely.
Protect the source
The -L option can remove metadata changes that have not been committed to the main structures.
A partially successful repair can make later reconstruction harder if no image exists.
Operating on an incorrectly assembled logical volume can interpret unrelated sectors as XFS data.
Do this now
Prevent databases, containers, shares, and virtual machines from writing through the damaged filesystem.
Preserve dmesg, journal logs, mount errors, xfs_info output, and commands already attempted.
Record RAID, multipath, LVM, encryption, partitions, snapshots, and device identifiers.
Perform repair analysis on a copy whenever disks report resets, timeouts, or unreadable sectors.
NEPFOSYS process
NEPFOSYS maps the complete block path and evaluates whether the XFS log and geometry are coherent.
Readable source regions are preserved with errors and missing areas documented.
Allocation trees, directories, inodes, extents, and file content are evaluated away from the originals.
A clear next step
Start a case with the exact symptoms, incident timeline, prior attempts, encryption details, and the files that matter most. NEPFOSYS will route the case to the appropriate DFW intake or nationwide mail-in path.
Start with a case reviewQuestions, answered
No repair tool can promise that. It prioritizes a consistent filesystem and may reconnect, rename, or discard structures it cannot validate.
Media errors, controller resets, thin-pool exhaustion, bad memory, and interrupted writes can all produce invalid metadata.
A read-only test may still trigger journal behavior depending on state and options. Preserve logs and use a controlled copy when the data is important.
DFW local · Nationwide mail-in