Filesystem Structure and Metadata Recovery Tools

No single tool reconstructs a damaged filesystem end to end — partition inspectors, metadata parsers, structure viewers, journal analysis, filesystem-aware recovery software and carving each answer a different layer's question.

Seven tool roles, one filesystem stack

• Partition structure inspectors read GPT and MBR directly, compare primary and backup GPT copies, and locate candidate filesystem boundaries without writing anything — the first step covered in Partition Table Recovery and Filesystem Discovery.
• Filesystem metadata parsers read MFT records and their attributes, ext4 inodes and extent trees, or APFS objects and B-trees directly, independent of whatever the OS's own mount logic currently shows.
• Hex editors and structure viewers verify offsets, inspect raw signatures, and compare metadata copies or generations byte for byte; see Hex Editors & Disk Structure Viewers.
• Journal and change-log analysis tools read NTFS USN journal records, ext4 JBD2 state, or equivalent transaction/timeline data — useful for context and chronology, never for restoring content the journal itself was never designed to hold; see Filesystem Journals and Crash Consistency.
• Filesystem-aware recovery software reconstructs directory trees, finds orphaned metadata, rebuilds extent mapping and processes multiple metadata copies or generations to choose the most credible one.
• Carving tools fall back to content-signature scanning only once metadata-aware reconstruction genuinely cannot resolve a file, per File-System Recovery vs. File Carving.
• Vendor and native repair utilities — CHKDSK, fsck/e2fsck, fsck_apfs, Disk Utility's First Aid — exist to make a filesystem internally consistent and usable again, which is a genuinely different objective from preserving every recoverable structure along the way.

Repair utilities are their own category, not a first resort

Repair utilities can delete invalid references, truncate files, reconnect orphans, free allocated blocks, rewrite trees and bitmaps, and replay logs — all in service of making the filesystem consistent, not in service of maximizing what a careful recovery process could still extract. For a source that still needs to be recovered from, consistency repair should not precede imaging and extraction unless the consequences of running it first are already understood and accepted.

Related: Partition Table Recovery and Filesystem Discovery · NTFS MFT, Allocation and File Reconstruction · Allocation Metadata, Orphaned Files and Lost Space · File-System Recovery vs. File Carving · Hex Editors & Disk Structure Viewers · Repair vs. Recovery