What is actually inside a NAS. And why the drives cannot simply be read in a PC.

Open a Synology, a QNAP, a ReadyNAS or a Buffalo and there is a small board with an ARM or Intel processor, some memory, a network port and a row of SATA connectors, running a Linux the maker has dressed in its own web interface. The operating system lives on a small partition mirrored across every drive, or on a flash chip on the board, or both. Your data lives on the large partitions behind it, and the description of how those partitions were joined into a volume lives on the drives too, in metadata written by mdadm and LVM. The unit can die completely and the drives still know what they were.

mdadm, and the RAID it makes.

mdadm is Linux's software RAID. It takes the data partitions from several drives and joins them into one block device: mirrored in RAID 1, striped with a parity block per stripe in RAID 5, with two parity blocks in RAID 6. Each member carries a superblock recording the array's identity, its order in it, the chunk size, the parity layout, and an event count that goes up every time the array is written, which is how the bench knows which drive dropped out first. A member that stops answering is marked failed and the array carries on degraded until another does.

LVM, and the maker's names.

Synology's SHR, Netgear's X-RAID and TerraMaster's TRAID exist to use drives of different sizes fully. Each slices the drives into equal pieces, builds an mdadm array per slice size, and joins the arrays into one volume with LVM, the Linux logical volume manager, which keeps its own map. QNAP uses LVM too, for its storage pools and the thick and thin volumes inside them, where a thin volume's blocks are scattered across the pool and found only through the thin-pool metadata. All of it is reconstructed layer by layer from the images, in the order the unit built it.

Btrfs, ext4, XFS and ZFS.

On top sits the file system. ext4 is the plain choice, with a journal and backup copies of its superblock; Btrfs, Synology's and ReadyNAS's default, checksums its metadata and keeps snapshots, which is why a Synology volume that lost a rebuild can often be read from a snapshot, and why a Btrfs damaged by a power cut is repaired from its checksummed copies rather than guessed at; XFS, on Buffalo, replays a log. ZFS, on TrueNAS and QuTS hero, does all of that and more: it writes nothing in place and keeps a history of pool states on every disk, so a pool that will not import at its latest state usually imports read-only at an earlier one. Drobo's BeyondRAID is the one layout that is none of these, and is reconstructed from images by other means.

Why a PC offers to format the drives.

Take a NAS drive out and plug it into Windows or macOS and it shows as an unknown partition, or as several, and the computer offers to initialise it. It cannot read a Linux RAID member, and it certainly cannot read one member of a striped set. Initialising writes a new partition table over the metadata that describes the set, which is the one thing the recovery most needs. The answer to the prompt is always no.

Why a rebuild reads every sector.

When a drive fails in RAID 5, the unit can carry on serving files by computing the missing drive's data from the others, one stripe at a time as needed. A rebuild does that for every stripe on the drive, in order, to write the missing drive onto a replacement, and to do it the unit reads every sector of every survivor, including the sectors nobody has touched in years and the ones a survivor has been quietly working around. On drives bought together and aged together, that is where the second failure is found; the survivor throws an unrecoverable read error, the unit drops it, and a degraded set is a crashed one.

Imaging every member.

The bench does not rebuild. It images every drive, sector by sector, on equipment that controls how long a read may take and how many times it is retried, the healthy drives at full speed and the weak ones slowly with their bad areas last, in clean air with new heads where a drive needs them. The drive that dropped out first is imaged too, because it holds every stripe written before it dropped. From then on the originals are not touched.

Virtual reconstruction.

The array is then assembled in software from the images: the superblocks give the order, chunk size and parity layout; LVM's metadata gives the map; a reshape interrupted by a power cut is honoured at the point it reached. The file system is repaired on that virtual volume, with Btrfs's checksums or ZFS's history used to choose good metadata over bad, and mounted read-only. Encrypted volumes are unlocked there with your key. LUNs and VM disks are extracted from the volume and opened as disks in their own right. Nothing done here can make the originals worse, and if a step fails it is simply tried another way.

Where the keys live.

Synology's encrypted shared folders, Asustor's folder encryption and QNAP's older folder encryption wrap files with eCryptfs and unlock with the folder's password or an exported key file. Synology's encrypted volumes from DSM 7.2, QNAP's and TerraMaster's volume encryption and TrueNAS's datasets use LUKS or ZFS's own encryption, unlocked by a passphrase, a key file or a key vault on the unit's system partition. A reinstall that rewrote the system partition took the vault with it, and without a saved recovery key the volume stays locked. Nobody, including us, has a way round that, and we say so at the free look.

What ransomware leaves.

Deadbolt, Qlocker and eCh0raix arrive through internet-facing services and work through the file system, file by file. They never see the mdadm arrays, the LVM map or the snapshots beneath the volume, and that is what comes back: snapshots taken before the attack, the originals Qlocker deleted after archiving them, the tails of large files Deadbolt only partly encrypted, and shares the malware never reached. Encrypted files without the key stay encrypted. The unit that is powered down with its network cable out, and not updated, reset or reinstalled, keeps all of that intact for the bench.

Where that leaves your NAS.

Nearly every NAS that reaches us has lost a drive, two drives, its unit or its system, with the data intact on the platters and the metadata intact beside it, and nearly every one is reassembled from images and its files sent home. A smaller number arrive after a rebuild, a reinstall, a reset or a forced import, and those recover less. The free look tells you which yours is, and what it will cost, before anything chargeable happens.