I need advice on the safest way to recover current data from a two-device Btrfs cache pool and return it to service.

System:

- Unraid 7.3.2, kernel 6.18.38-Unraid

- Cache: 2 × Samsung 870 EVO 2TB

- Btrfs UUID: 076e9d85-575e-44d6-8e98-dd09cd1c1cb8

- Devices: /dev/sdi1 and /dev/sdj1

- Approximately 708 GiB used; pool was only 19% full

- Pool configuration is RAID0

- Docker and VM services are disabled

- Array autostart is disabled

- Latest Appdata Backup is September 1 and is stored safely on the array

Initial failure on September 13:

01:13:26:

ata2.00: exception Emask 0x10 ... action 0x6 frozen

ata2.00: irq_stat 0x08000000, interface fatal error

ata2.00: failed command: READ FPDMA QUEUED

Emask 0x10 (ATA bus error)

ata2: hard resetting link

01:13:37:

Multiple I/O errors on /dev/sdj following the link reset.

Immediately afterward:

BTRFS error (device sdi1): bad tree block start 17723136111638685486

BTRFS critical (device sdi1): corrupt node: root=5 block=896516096 slot=59, unaligned pointer

BTRFS error (device sdi1): block=896516096 write time tree block corruption detected

The cache then became read-only. Docker loop2 accumulated thousands of read errors, and loop3 also produced read errors.

SMART:

- Both SSDs pass

- Zero reallocated sectors

- Zero uncorrectable errors

- /dev/sdj has CRC_Error_Count 0

- /dev/sdi has CRC_Error_Count 1

- No SMART errors logged

Before shutdown:

btrfs device stats showed zero read/write/flush/corruption/generation errors for both /dev/sdi1 and /dev/sdj1.

I disabled Docker, VMs and autostart. The array initially hung while stopping because shfs remained open; shfs exited after SIGTERM, and the server was shut down cleanly.

With power removed, I reseated/cleaned the SATA data and power connections for the affected SSD: Samsung 870 EVO 2TB, cache device 2 (/dev/sdj at the time), serial ending 458E.

After reboot, both devices are detected correctly with the same Btrfs UUID. The array remains stopped.

First offline check:
btrfs check --readonly /dev/sdi1

It reported three free-space-tree errors:

free space info recorded 2 extents, counted 0

space_info 4 has 3 free space keys with no corresponding block group

block group[1487546056704 1073741824] did not have corresponding free space entry

block group[1488619798528 1073741824] did not have corresponding free space entry

block group[1489693540352 1073741824] did not have corresponding free space entry

I then ran:

btrfs rescue clear-space-cache v2 /dev/sdi1

A subsequent read-only check no longer reported the free-space-cache errors, but now reports:

parent transid verify failed on 900055040 wanted 2200004 found 2200003

Ignoring transid failure

ERROR: transid errors in file system

No --repair has been run.

The pool currently mounts successfully with:

mount -t btrfs -o ro,rescue=nologreplay /dev/sdi1 /mnt/cache-recovery

The top-level directories are visible:

appdata, data, domains, isos, obsidianvault, syslog and system.

What is the safest recommended next step?

My priority is:

1. Recover the current cache contents to an array disk.

2. Avoid btrfs check --repair unless specifically advised.

3. Rebuild or repair the cache pool and restore Docker/VM service.

4. Determine whether the ATA failure points to the cable, port/controller, power path or SSD.

I sincerely appreciate any help you can provide.

node-diagnostics-20260913-0909.zip

I’d prioritize copying the recoverable data off the RAID0 cache while it mounts read-only, then troubleshoot the SATA path/SSD; avoid any Btrfs repair operation until the data is safely backed up.

4 hours ago, phyzicist said:

parent transid verify failed on 900055040 wanted 2200004 found 2200003

These are typically fatal with btrfs, it means a device/controller lied about writes that weren't actually made. You can find some recovery options below, then reformat the pool

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#findComment-543490

Thanks, that aligns with my current plan.
I have not run any Btrfs repair operation, and the cache remains manually mounted read-only at /mnt/cache-recovery.

The practical issue is that the Unraid array is still stopped, so the array disks are not currently available as a recovery destination. What is the safest Unraid-supported way to make an array disk available for writing while ensuring the damaged cache pool is mounted only with ro,rescue=nologreplay?

For example, should I temporarily unassign the cache devices and start the array normally, or start in Maintenance Mode and manually mount an /dev/mdXp1 array disk? I do not want to guess and accidentally allow log replay or writes to the cache.

Once a destination is available, I intend to copy the approximately 708 GiB from /mnt/cache-recovery to a direct disk path such as /mnt/disk7/data/cache-recovery-20260912, preserving permissions, ACLs and extended attributes while logging any read errors.

Could you advise the safest sequence and recommended copy command?
I sincerely appreciate any help you can provide.

Thank you, JorgeB.
It is regrettable news, but I appreciate the clear diagnosis and recovery guidance.

My understanding of the plan is:

1. Do not run btrfs check --repair, a scrub, or otherwise mount the damaged pool read-write.

2. Keep the pool mounted read-only at /mnt/cashe-recovery using ro,rescue=nologreplay.

3. Copy all readable contents to a direct array-disk destination while preserving permissions, ACLs and extended attributes, and record any files that produce read errors.

4. Verify the recovered data before making further changes.

5. Reformat/recreate the cache pool and restore the recovered data or Appdata Backup.

6. Separately troubleshoot the underlying SATA path—data cable, port/controller and power connection—and test both SSDs before returning them to service.

The array is currently stopped while the cache is manually mounted read-only, so I still need to make an array disk available as the recovery destination without allowing Unraid to mount or write to the cache normally.

Would temporarily unassigning both cache devices, starting the array normally, and then manually mounting the cache read-only be the preferred approach, or is there a safer Unraid-supported method?

Please correct anything I may have misunderstood.
Sincere thanks again.

It's fine to start the array, the pool will show as unmountable, but its data will remain accessible under /mnt/cashe-recovery