Tools & conceptsTechnicalUpdated October 17, 2026 · Data Recovery Cases Editorial Team

RAID, NAS and SAN Reconstruction Tools

No single tool reconstructs a RAID, NAS or SAN stack end to end. The useful choice is made by entry point: at which layer the system still hands over a usable object, which capability works at that layer, and what that layer still depends on — members, metadata, controller, keys — rather than by a “RAID” or “NAS supported” label.

In short

Remote access to a running NAS and member-level reconstruction are different capabilities; a “NAS supported” claim does not prove both.
Member images preserve the bytes that could be read; they do not make members mutually consistent.
A native metadata parser yields candidates and evidence, not a guaranteed copy of the original array.
Compare counters within their own technology and array; the largest number is not automatically right.
An assembled array can still be ciphertext; RAID capability does not replace a missing key or KMS.
Reading existing logs differs from running tests, checks or support collection that act on the system.

Choose by entry point and representation

A running NAS can expose shares or volumes over the network; the same data also exists as raw member disks, as a logical volume assembled from those members, and, where encryption is in use, as plaintext only after an unlock. Each representation is a different starting object, and tools differ in which ones they accept. Remote logical access works with whatever the still-functioning appliance exposes and does not, by itself, reconstruct the RAID or pool underneath; member-level reconstruction starts from disks or images and has to rebuild every layer it needs. A product page saying “NAS supported” does not establish that both modes exist, that a layout can be entered manually when metadata is missing, or that the upper pool or volume layer of that specific system is understood. Remote NAS Recovery vs. Member-Level Reconstruction explains the two entry points and what each depends on.

Encryption is a separate dependency. RAID capability does not open self-encrypting drives, controller-managed encryption or software volume encryption, and it does not restore a key-management dependency that is no longer available; a correct geometry over encrypted members produces correctly ordered ciphertext. See SED and RAID Controller Encryption: Preserving Access.

Scroll horizontally to see the full table →

Capabilities by starting representation. Whether a given product covers a row, and for which models, layouts and versions, has to be confirmed from its own current documentation.
Starting object	Capability needed	Reads / writes / load	Output	Limit or unknown to confirm
Shares or volume exposed by a running NAS	Remote logical access or scan	Reads through the appliance; the appliance keeps running and carries the load	Files, or a copy of the exposed volume	Depends on the appliance staying stable and unlocked; does not rebuild the RAID or pool beneath it
Raw member disks	Member imaging	Reads each member; writes only to the destination	Per-member images with logs of unread areas and timing	Preserves available bytes and records acquisition uncertainty; no guarantee of one consistent generation
Member images	Metadata inspection or native parsing	Reads metadata regions on the images	Candidate member identity, role, state, generation and offsets	Metadata may be stale, incomplete or conflicting; the specific format and version must be supported
Member images	Generic geometry reconstruction	Reads images; writes a virtual device or output file	A candidate assembled logical volume	A readable result is not proof of the original array; identity, state, geometry and upper mappings still need checking
Assembled logical volume	Volume, pool, thin or LUN mapping	Reads volume and allocation metadata	Logical volumes, a LUN address space, snapshot views	Needs support for the actual stack and its version, not for a list of technology names
Copy-on-write pool or file system	Btrfs- or ZFS-aware inspection	Reads trees, roots, checksums and generations	A file-level view of a chosen generation or snapshot	Which features and versions are understood varies by product
Encrypted volume or members	Unlock with an available, authorised key	Depends on the encryption layer	Plaintext	Geometry and pool support do not replace a missing key, controller or KMS dependency
Running controller or appliance	Reading or exporting existing configuration and logs	Reads records the system already holds	Configuration, event history, member state as reported	Active tests, checks and some support collection routines can add I/O or change state

Member imaging preserves bytes, not consistency

Member imaging tools preserve unstable disks so that later work runs on copies — the category covered in Disk Imaging & Cloning Tools and Recovery Copies. What a set of images preserves is the bytes each member returned, plus a record of what could not be read and when. It does not make the members mutually consistent: a member that dropped out earlier carries an older generation, and members of a live system imaged one after another are not captured at the same moment. Whether a consistent generation exists is a question for the analysis that follows, as in Storage Metadata Generations and Consistency and Live Systems, Snapshots and Consistent Recovery Copies.

Geometry search and native parsing are separate capabilities

Generic geometry reconstruction answers one question: given a disk order, stripe size, parity rotation and data offset, does the result read as a plausible block device? Native metadata parsing reads the system’s own on-disk structures — Linux md superblocks, LVM metadata, a hardware controller’s configuration area — and reports what they claim. The two capabilities can sit in the same product, and neither result is final by itself. A parser finds candidates and evidence, but metadata can be stale, incomplete or conflicting, and a parser has to support the exact format it meets: the Linux kernel’s md documentation alone lists several superblock formats, newer ones “in varying locations”, as well as externally managed metadata handled by user space (kernel md documentation, “Superblock formats” and the metadata_version attribute). Hex editors and structure viewers let an analyst compare those copies byte for byte; see Hex Editors & Disk Structure Viewers.

Whichever capability produced an assembly, the result still needs checking: which physical member each image came from, the role and state each one held, which generation the set represents, whether the geometry is the original one, and whether the upper volume and file-system mappings agree. Counters such as event counts, sequence numbers or transaction generations are compared within their own domain — among members of the same array, under the same metadata format or controller — not expected to match across technologies, and the largest value is not selected automatically, because a member that kept running alone can carry the highest counter and still hold the least useful state. RAID Metadata, Member State and Foreign Configurations covers how to read them.

Upper layers: support the stack you actually have

LVM, thin provisioning, snapshots, Btrfs and ZFS are not one mandatory ladder that every system climbs. A given NAS or SAN may use some of them, none, or a vendor-specific combination; ZFS, for example, normally provides its own redundancy and volume management rather than sitting on a separate RAID layer. What matters is that the tool supports the stack actually present, in its version, not that its feature list names every technology. Once a pool uses thin provisioning or snapshots, reconstructing the RAID or LVM layer underneath is necessary but not sufficient: the pool’s own allocation metadata has to be mapped too, or the recovered blocks describe the wrong logical addresses even though every physical sector reads back. See LUN, Thin Provisioning and Snapshot Recovery and Reconstructing NAS Storage Stacks.

Vendor diagnostics: reading records versus acting on the system

NAS management pages, RAID controller utilities and SAN management software hold evidence that may not exist anywhere else: configuration, event history, member state as the controller saw it. Reading or exporting configuration and logs that already exist, on a system that is running and stable, is a different action from running a diagnostic test, a consistency check or patrol read, or a support-collection routine whose documentation says it gathers data actively; the latter can add I/O or change state, so what a given export actually does has to be checked in that product’s documentation rather than assumed either way. On a system that is off, failing or unstable, collecting a field is not a reason to power it on or start anything; Documenting RAID and NAS Systems Before Drive Removal sets out what to gather and what to leave as unknown.

Import, clear, initialise, rebuild and scrub are not diagnostics. Even a redundancy “check” is an active operation: the kernel md documentation describes it as reading all blocks and notes that a repair may also happen for some RAID levels, and it describes md refusing by default to start a RAID 5 or 6 array that is both dirty and degraded because it could hold undetectable corruption (kernel md documentation, sync_action and “Boot time assembly of degraded/dirty arrays”). The original controller, enclosure, configuration and key dependencies are kept as evidence and as access paths; a software geometry built on images does not replace them.

Practical rule

Use the least powerful capability that answers the current question. Metadata inspection and virtual reconstruction on images come before anything that writes to a member, changes controller or array state, or repairs a file system in place.

Technical references: Linux kernel: RAID arrays (md) — superblock formats, sync actions, dirty/degraded start. Checked in the “latest” documentation build (7.3.0-rc7) in October 2026; it describes Linux md only and is not a recovery procedure for originals or for other controllers.