NAS Symptom Recovery
Btrfs Corruption NAS Recovery
Your NAS reports Btrfs corruption, parent transid verify failed, or open_ctree failed. DSM may show Volume Crashed. The root cause can be a power loss during a write, an SMR drive timeout during rebuild, or a RAID member failure that cascaded into the filesystem layer. We image every drive first, then use read-only forensic tools to extract your data. No data, no fee.
What does Btrfs corruption mean on a NAS?
Btrfs corruption means the filesystem's copy-on-write B-trees have diverged, for example after a power loss, SMR timeout, or RAID rebuild error. Recovery uses read-only tools such as btrfs-find-root and btrfs restore after every drive is imaged with ddrescue or PC-3000. We do not run btrfs check --repair because it writes to the disk and destroys historical generation trees.
How does Btrfs corruption happen on a NAS?
Btrfs keeps its metadata in copy-on-write B-trees that point to your file data. When your NAS writes a file, it doesn't overwrite the old block in place. It writes the new data to a fresh location and updates the tree pointer.
Parent transid verify failed error
Btrfs gives each transaction commit an incrementing ID (transid). A parent block pointer contains the expected generation number of the child block. When the system reads the child, it verifies the generation matches. If the storage controller ignored write barriers and a crash interrupted the write, the parent may successfully commit transaction 10 to the platter while the child was last written at transaction 8. The kernel throws parent transid verify failed and refuses to mount.
SMR Drive Timeouts During Rebuild
Some NAS arrays are built from consumer SMR drives. These drives stall for 30 to 60 seconds when asked to do sustained writes because they must rewrite entire shingled bands internally.
The stall exceeds the Linux kernel SCSI command timeout (which defaults to 30 seconds), so the md layer ejects a physically healthy drive mid-rebuild. One dropped member in a RAID 5 array triggers a degraded state.
URE Math on Consumer Drives
Rebuilding a RAID 5 array requires reading every byte from every surviving drive. Consumer drives are specced for one unrecoverable read error per ~12.5 TB of data read. That's the manufacturer's worst-case spec, not a schedule. A 48 TB rebuild reads more than that, so hitting at least one unreadable sector is a real risk, but it's not a certainty. Most drives read far past the spec, and errors cluster on aging members.
What happens if a URE lands depends on the layer. Linux mdadm records the bad LBA in its Bad Block Log and keeps going. On a dual-parity layout with one drive down (RAID 6, SHR-2), the second parity reconstructs the sector outright. If your data is irreplaceable and you have no verified backup, we image every member member-by-member before any reconstruction rather than rebuild on degrading hardware.
Orphan Inodes and Crash Vectors
The NAS may have appeared to boot fine after the initial crash, then crashed again days later when a background task touched the damaged tree. Snapshot replication also fails because the Btrfs send operation cannot resolve paths for orphan inodes.
What does btrfs check --repair do to your data?
The myth that data recovery software can easily fix a corrupted Btrfs filesystem is wrong. btrfs check --repair writes to the disk. It does not preserve the existing CoW generation trees. When it encounters a block it cannot verify, it may zero it out or reassign pointers, destroying the historical versions of your data that a read-only approach could have recovered.
Safe Btrfs recovery is read-only. btrfs-find-root scans the device's metadata for older Root Tree candidates. btrfs restore extracts files from a damaged filesystem without writing a single byte back to the source drives. These are the tools we use after imaging.
Which B-trees does Btrfs keep on disk?
Btrfs keeps several B-trees. They include the Root Tree, Extent Tree, Chunk Tree, Checksum Tree, and the FS Tree. Four of these are pure metadata. Only the FS Tree references your actual files. Knowing which tree is damaged tells us which read-only path can still reach your data.
- Root Tree (metadata)
- The tree of tree roots. The superblock points straight at it. It holds the roots of the other trees except the Chunk Tree, and the superblock points at that one directly too. If the Root Tree node the superblock references won't verify, nothing else can be located. That's the usual source of an
open_ctree failedstop. - Extent Tree (metadata)
- Tracks every allocated block and its reference count across data and metadata. btrfs-progs rebuilds this tree from scratch under its own option,
--init-extent-tree, which is one of the reasons repair tooling never touches the original drives here. - Chunk Tree (metadata)
- Maps logical Btrfs addresses to physical device byte offsets, including which physical disk in the array holds each chunk. When this tree itself cannot be read, the kernel fails earlier, on the chunk root, with its own distinct error.
- Checksum Tree (metadata)
- Stores a separate checksum for data blocks. The default is crc32c. Metadata blocks carry their checksum inline in the b-tree node header instead, which is why a metadata block that fails its own header checksum halts traversal down that branch.
- FS Tree (your files)
- The filesystem or subvolume tree. It holds the inodes and directory items that name your files. A recovery that reaches a clean FS Tree generation reaches your data.
Superblock copies and the generation chain
Btrfs writes superblock copies at three fixed byte offsets: 64 KiB, 64 MiB, and 256 GiB. Each superblock holds the current generation (transaction) number, the Root Tree pointer, and the Chunk Tree pointer. The generation number chains downward from the superblock to the Root Tree to the subtree leaf nodes, and every step is verified by transid plus checksum.
Btrfs is copy-on-write. A new block is allocated and the parent pointer is updated, so older valid versions of the tree nodes survive on disk until something explicitly overwrites them.
This is why one corrupt internal node orphans an entire subtree. Traversal relies on a strict transid match plus a valid checksum at each node. If an internal node fails that verification, the kernel refuses to walk further down that branch, so every leaf below it becomes invisible even when those leaf nodes are physically intact on the platter.
The data is still there. The path to it is broken, and the read-only forensic tools exist to find an older generation of that path that still verifies.
How does read-only Btrfs recovery actually work?
We enumerate the historical tree roots that copy-on-write left on disk, then extract files from the newest one that still verifies. Two read-only tools do this: btrfs-find-root lists candidate roots, and btrfs restore walks a chosen root to copy files out without mounting and without writing to the source.
The first command scans the raw device and enumerates candidate Root Tree triples. Each triple is a bytenr (the block address of a historical Root Tree), its level in the B-tree, and its generation (transid). Because copy-on-write leaves older valid root-node versions on disk, several past transactions usually show up as candidates:
# Enumerate historical Root Tree candidates (read-only)
btrfs-find-root /dev/sdX
# Extract files from one chosen historical root.
# -t takes the BYTENR (block address) of a candidate
# that btrfs-find-root reported, not a generation number.
btrfs restore -t <bytenr> /dev/sdX /mnt/targetThe -t flag on btrfs restore takes the byte offset of a candidate root, so you point it at one of the bytenr values btrfs-find-root printed. It then walks that specific historical Root Tree and copies files to /mnt/target without mounting the filesystem and without writing a single byte back to the source. We start from the newest candidate generation and step back through older ones until the extracted FS Tree is consistent.
What we never run, and why
btrfs check --repair scans the device and writes its repairs back to it. That can overwrite the historical generation roots the read-only path depends on, so it is not a safe option and we do not use it.
We run these tools only against drive images, never against your original disks. Every member is imaged first with ddrescue or a PC-3000 Portable III, and the forensic work happens on the copies.
What do the btrfs rescue subcommands do, and are they safe on a NAS?
These four btrfs rescue subcommands (zero-log, chunk-recover, super-recover, and clear-space-cache) all write to disk, so they run only on a forensic clone or image, never on the original NAS drives. The tools that stay safe on the originals are btrfs check --readonly and btrfs-find-root, and btrfs restore is read-only. Those four are not the whole btrfs-rescue(8) suite either: it carries more subcommands than these, and one of them, btrfs rescue fix-data-checksum --readonly, only scans for data-checksum mismatches and reports them without writing to the device, so it is safe to run on the originals too.
btrfs rescue zero-log(writes to disk)- Clears the log tree, which is the fsync journal. It's meant for a mount that fails while it's replaying that log. It discards only the not-yet-committed fsync log, not the committed generations, but it still writes to the device to do it.
btrfs rescue chunk-recover(writes to disk)- Scans the raw device blocks for chunk headers to rebuild a damaged chunk tree, the logical-to-physical map. It is slow on large devices and cannot run during a
btrfs replaceor abalance. btrfs rescue super-recover(writes to disk)- Overwrites corrupted superblock copies with valid backups found at the fixed offsets
64 KiB,64 MiB, and256 GiB. btrfs rescue clear-space-cache v1(writes to disk)- Clears the v1 free-space cache.
Why the clone, not the NAS
Btrfs is copy-on-write. Every one of these subcommands still writes to the device. That's why they run on an image after every drive is cloned, and why the diagnostics we run on the source stay read-only.
For the general, non-NAS Linux case, the same subcommands and the same clone-first rule are covered on our Btrfs filesystem recovery page.
What do parent transid verify failed, open_ctree failed, and failed to read block groups mean?
parent transid verify failed means a metadata consistency check failed, and several things can cause that. open_ctree failed means a top-level tree such as the Root Tree couldn't be read. failed to read block groups is a read failure in the extent or block-group tree, or a block group that doesn't match its chunk. The message tells a technician where to look first.
parent transid verify failed- A parent node expects a newer generation than the child node actually has. The btrfs documentation says possible causes include a logical bug, a misdirected write, and storage that doesn't flush properly. To get past it, the read-only tools look for an older generation that still verifies.
open_ctree failed- The filesystem cannot be opened at all because a top-level tree node, usually the Root Tree or the Chunk Tree, could not be read or failed a level verify.
failed to read block groups- The block-group items could not be read. Btrfs reads those items from the extent tree, or from the dedicated block-group tree where that feature is enabled, so this message points at that read path or at a block group whose chunk mapping does not match, rather than at the FS Tree.
An open_ctree stop points at the Root or Chunk Tree entry point. A block-group read failure points at the extent or block-group tree.
DSM-level vs underlying RAID failure
DSM's Volume Crashed banner does not tell you whether the problem is at the RAID layer or the filesystem layer.
| Layer | Synology SHR Stack | Failure Signature |
|---|---|---|
| RAID | mdadm (software RAID) | Degraded array, drive ejected, out-of-sync event counts |
| Volume Manager | LVM2 | Volume group not found |
| Filesystem | Btrfs on LVM logical volume | open_ctree failed, parent transid verify failed |
A Synology SHR volume is mdadm at the bottom, LVM in the middle, and Btrfs or ext4 on top. QNAP QTS uses mdadm plus LVM plus ext4, and QuTS hero uses ZFS.
Neither QNAP OS uses Btrfs. TrueNAS uses ZFS. Unraid uses independent XFS or Btrfs filesystems per drive with parity protection, not striping. Each drive is readable on its own.
The layered diagnosis matters because the fix is different. If mdadm lost a superblock, the array can often be reassembled with mdadm --assemble --readonly. If Btrfs lost a generation tree, you need btrfs-find-root and btrfs restore on an image. A RAID rebuild works at the block layer and knows nothing about the damaged trees above it, so it does not fix a Btrfs problem and it writes to the members while you still need them.
RAID provides availability, not protection. A RAID array will survive a single drive failure in most modes, but it will not protect you from ransomware, accidental deletion, or filesystem corruption.
What does the recovery process look like?
We image every drive with ddrescue or a PC-3000 Portable III before any reassembly attempt. This is non-negotiable. If a drive has mechanical issues, it goes to the clean bench first. Once every drive is imaged to a working target, we reassemble the RAID in software on a Linux workstation.
- Image every member drive. We clone each drive with ddrescue or PC-3000 through a write-blocked interface. Bad sectors get mapped and skipped. If a drive has a mechanical fault, we stabilize it in the 0.02 micron ULPA-filtered clean bench before imaging it.
- Reassemble the RAID array. For Synology, we read the mdadm superblocks with
mdadm --examine, then assemble the array read-only withmdadm --assemble --readonly. We activate the LVM volume group and scan the resulting Btrfs volume. - Locate clean Btrfs generation roots.
btrfs-find-rootlists the older Root Tree candidates still on the image. - Extract files read-only.
btrfs restoreextracts files without writing to the source image. - Return data on new media. We copy the recovered data to a new drive and send it back to you. Nothing gets written back to your original disks.
This is mail-in service to our lab at 2410 San Antonio Street, Austin, TX 78705. You can call us at (512) 212-9111 during 10 AM - 6 PM to discuss your case. We do not charge a diagnostic fee. The evaluation is free. You pay only if we recover data you want back.
How much does Btrfs NAS recovery cost?
We price NAS recovery per member drive, plus a separate $400-$800 array reconstruction fee. Standard hard drives start at $100. If your array uses helium-filled drives, pricing follows the helium HDD schedule, which starts at $200.
Rush service adds $100. +$100 rush fee to move to the front of the queue. Donor drives are matching drives used for parts. Typical donor cost: $50–$150 for common drives, $200–$400 for rare or high-capacity models. We source the cheapest compatible donor available.
There is no diagnostic fee. If we cannot recover your data, there is no recovery fee.
- Low complexity
Simple Copy
Your drive works, you just need the data moved off it
Functional drive; data transfer to new media
Rush available: +$100
$100
3-5 business days
- Low complexity
File System Recovery
Your drive isn't recognized by your computer, but it's not making unusual sounds
File system corruption. Accessible with professional recovery software but not by the OS
Starting price; final depends on complexity
From $250
2-4 weeks
- Medium complexity
Firmware Repair
Your drive is completely inaccessible. It may be detected but shows the wrong size or won't respond
Firmware corruption: ROM, modules, or translator tables corrupted; requires PC-3000 terminal access
CMR drive: $600. SMR drive: $900.
$600–$900
3-6 weeks
- High complexity
Head Swap
Bench diagnosis found the read/write heads have to be replaced. Clicking can also come from firmware, the preamp, or the spindle
Head stack assembly failure. Transplanting heads from a matching donor drive on a clean bench
50% deposit required. CMR: $1,200-$1,500 + donor. SMR: $1,500 + donor.
50% deposit required
$1,200–$1,500
4-8 weeks
- High complexity
Surface / Platter Damage
Your drive was dropped, has visible damage, or a head crash scraped the platters
Platter scoring or contamination. Requires platter cleaning and head swap
50% deposit required. Donor parts are consumed in the repair. Most difficult recovery type.
50% deposit required
$2,000
4-8 weeks
Hardware Repair vs. Software Locks
Our "no data, no fee" policy applies to hardware recovery. We do not bill for unsuccessful physical repairs. If we replace a hard drive read/write head assembly or repair a liquid-damaged logic board to a bootable state, the hardware repair is complete and standard rates apply. If data remains inaccessible due to user-configured software locks, a forgotten passcode, or a remote wipe command, the physical repair is still billable. We cannot bypass user encryption or activation locks.
No data, no fee. Free evaluation and firm quote before any paid work. Full guarantee details. Head swap and surface damage require a 50% deposit because donor parts are consumed in the attempt.
- Rush fee
- +$100 rush fee to move to the front of the queue
- Donor drives
- Donor drives are matching drives used for parts. Typical donor cost: $50–$150 for common drives, $200–$400 for rare or high-capacity models. We source the cheapest compatible donor available.
- Target drive
- The destination drive we copy recovered data onto. You can supply your own, or we'll provide one. For larger capacities (8TB, 10TB, 16TB and above), target drives cost $400+ extra. All prices are plus applicable tax.
Sealed helium drives are on their own price list, $200–$5,000+. When a head swap or platter repair opens one, we refill it with helium. That adds $400–$800, and the donor has to be an exact match. Helium drive prices
Data Recovery Standards & Verification
Our Austin lab operates on a transparency-first model. We use industry-standard recovery tools, including PC-3000 and DeepSpar, combined with strict environmental controls to maintain drive integrity. This approach allows us to serve clients nationwide with consistent technical standards.
Localized Clean Zone
Open-drive work is performed in a 0.02 micron ULPA-filtered laminar clean bench.
Transparent History
Serving clients nationwide via mail-in service since 2008. Our lead engineer holds PC-3000 and HEX Akademia certifications for hard drive firmware repair and mechanical recovery.
Media Coverage
Our repair work has been covered by The Wall Street Journal and Business Insider, with CBC News reporting on our pricing transparency. Louis Rossmann has testified in Right to Repair hearings in multiple states and founded the Repair Preservation Group.
Aligned Incentives
Our "No Data, No Charge" policy means we assume the risk of the recovery attempt, not the client.
Technical Oversight
Louis Rossmann
Our engineers review all lab protocols to maintain technical accuracy and honest service. Since 2008, his focus has been on clear technical communication and accurate diagnostics rather than sales-driven explanations.
We believe in showing the bench rather than just describing it. Open-drive work runs on a 0.02 micron ULPA-filtered laminar clean bench, and we filmed it.
See the particle counter test at the benchFrequently Asked Questions
Common questions about Btrfs corruption and NAS recovery.
Can I run btrfs check --repair on my crashed NAS?
Why did my Synology NAS crash?
Is my data gone after Btrfs corruption?
How long does Btrfs NAS recovery take?
Can I just move my drives to a new NAS?
My NAS says "Volume Crashed." Is this Btrfs corruption?
Does Btrfs RAID 5/6 have write-hole bugs?
What does "parent transid verify failed" mean?
Should I run btrfs rescue on my NAS drives?
NAS showing Btrfs corruption?
Power down, label your drives, and ship them to us. Free evaluation. No data, no fee.