Re: Any news about rescue data from a raid5 in the last years?

[Zygo Blaxell <ce3g8jdj@umail.furryterror.org>]

On Tue, May 26, 2020 at 04:44:25AM +0200, Michael Thomas wrote:
> Hey,
> 
> I just wanted to ask if it's maybe possible to restore data from an old,
> failed, raid5 btrfs fs. There are some files on it which I lost lately and
> before I format the drives I wanted to give it another shot after some (6?)
> years.
> I'm not sure what I tried before, but there are 3 drives there, was 4 before
> but 1 died (and this seems to be the problem of the disaster).
> I tried to add 1 new, but that didn't worked.
> So, there are 3 devices and as far as I understand, there are still no good
> tools to rescue data from them, are they? btrfs restore and other seems only
> compatible with 1 drive.
> 
> But maybe someone can give me a hint what I can try before giving up.
> 
> If I try to mount:
> mount -o degraded,subvol=data,ro,device=/dev/mapper/sdb,device=/dev/mapper/sdd,device=/dev/mapper/sde
> /dev/mapper/sde /mnt/test
> 
> dmesg give this errors:
> BTRFS warning (device dm-4): suspicious: generation < chunk_root_generation:
> 176279 < 176413
> BTRFS info (device dm-4): allowing degraded mounts
> BTRFS info (device dm-4): disk space caching is enabled
> BTRFS warning (device dm-4): devid 4 uuid
> 16490fb1-df5e-4c81-9c07-4f799d0fc132 is missing
> BTRFS warning (device dm-4): devid 5 uuid
> 36436209-c0d4-4a5e-9176-d44c94cb4b39 is missing

That's 2 missing disks.  Assuming that is accurate (were there 5 in
total?), it is not likely recoverable with raid5.

raid5 tolerates only one disk failure--two or more failures, and you'll
only be able to get 64K contiguous chunks of data without any idea
what files they belong to.

If the messages are _not_ accurate, you might have a corrupted superblock
on one of the disks that is making 'btrfs dev scan' fail.  If you can
identify which disk that is, 'btrfs rescue super-recover' might help
(though it sounds like you already tried and it didn't).

> BTRFS critical (device dm-4): corrupt leaf: block=1095416938496 slot=151
> extent bytenr=1095389085696 len=16384 invalid generation, have 176581 expect
> (0, 176280]
> BTRFS error (device dm-4): block=1095416938496 read time tree block
> corruption detected

You may have more luck with kernel 4.19, which is a LTS kernel without
the read time tree block corruption detector; however, that won't be able
to read past the corrupted tree block, it will only let you mount the
filesystem to try to salvage other data.

> BTRFS critical (device dm-4): corrupt leaf: block=1095416938496 slot=151
> extent bytenr=1095389085696 len=16384 invalid generation, have 176581 expect
> (0, 176280]
> BTRFS error (device dm-4): block=1095416938496 read time tree block
> corruption detected
> BTRFS warning (device dm-4): failed to read root (objectid=4): -5
> BTRFS error (device dm-4): open_ctree failed
> 
> (usebackuproot changed nothing and super-recover prints "All supers are
> valid, no need to recover")
> 
> Do you have any hint, advice to get (some of) this data back?
> 
> 
> Best,
> Michael