On 2017年12月29日 07:09, Stirling Westrup wrote: > Using "btrfs rescue super-recover" is of no use since there are no > valid superblocks on the disk I need to fix. Btrfs has normally 1 primary superblock and 1 or 2 backup superblocks. super-recover is going to read the backup superblocks and use them as the base to recover primary superblock. If super-recover can't even find the backups, then the disk is more damaged than you have expected. > In fact, it's even worse, > because the only even partly valid superblock is a copy of the one > from drive sdd, which is a perfectly valid drive. What I need to do > (as far as I can tell) is: > > 1) Patch the UUID_SUB and device number of sdf to make it distinct > from sdd. Or just generate an entirely new superblock for sdf which > indicates it is device 2 in the 4-device BTRFS (rather than device 1 > which it now thinks it is). You need your device UUID, which can be found in device tree. (Only if you could mount the fs in RO and degraded mode, then you're still OK to read it out) You're looking for this part of "btrfs ins dump-super" output: ------ ... cache_generation 8 uuid_tree_generation 8 dev_item.uuid f1d9b288-7865-463f-a65c-ca8b1fbde09b <<<<< dev_item.fsid 1dd513fb-45f8-404f-ae23-979e3acb78ad [match] dev_item.type 0 dev_item.total_bytes 10737418240 ... ------ > > 2) Recover (somehow) whatever other information from the superblock > that is missing. > Just as I said, if your backup super is also corrupted, there is little chance to recover. To verify if the backups are still alive, please paste the output of "btrfs ins dump-super -fa". (Even you think super-recover is of no use, the output can still help) Thanks, Qu > > > On Thu, Dec 28, 2017 at 7:11 AM, Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: >> >> >> On 2017年12月28日 19:41, Nikolay Borisov wrote: >>> >>> >>> On 28.12.2017 03:53, Qu Wenruo wrote: >>>> >>>> >>>> On 2017年12月28日 09:46, Stirling Westrup wrote: >>>>> Here's my situation: I have a network file server containing a 12TB >>>>> BTRFS spread out over four devices (sda-sdd) which I am trying to >>>>> recover. I do have a backup, but it's about 3 months old, and while I >>>>> could certainly rebuild everything from that if I really had to, I >>>>> would far rather not have to rerip my latest DVDs. So, I am willing to >>>>> experiment if it might save me a few hundred hours of reconstruction. >>>>> I don't currently have another 12 TB of space anywhere for making a >>>>> scratch copy. >>>>> >>>>> A few days ago sdb developed hard errors and I can no longer mount the >>>>> filesystem. sdb is no longer even recognized as a valid btrfs drive. >>>>> However, when I ran ddrescue over the drive I managed to make a clone >>>>> (sdf) which contains all but 12K of the original drive. However, those >>>>> missing 12K are all in the various superblocks, so the cloned drive is >>>>> still unreadable. >>>>> >>>>> In the hopes that I was only missing a few bits of the superblocks, I >>>>> started out by dd-ing the first 4M of sdd into sdf in the hopes that >>>>> ddrescue would overwrite much of the superblocks, and the final bits >>>>> from sdd would make things usable. >>>>> >>>>> No such luck. I now have a drive sdf which claims to be identical to >>>>> sdd but which is a clone of sdb. In case it matters, sda and sdc are >>>>> each 4TB while sdb and sdd are each 2TB drives; sde is my boot drive >>>>> and sdf is a 2TB clone of sdb. >>>>> >>>>> What I need to do is to somehow patch sdf's primary superblock so it >>>>> contains the correct device number and UUID_SUB for sdb, so that I can >>>>> attempt some sort of recovery. Right now my linux is (understandably) >>>>> quite confused by the situation: >>>> >>>> Did you tried "btrfs rescue super-recover"? >>>> >>>> Remember to use the devel branch from git, as there is a small bug >>>> prevent it report correct result. >>> >>> Unforutnately my patchset which fixes super-recover is still not merged, >>> so he needs to grab the patches from the mailing list and compile the >>> btrfs tools himself. The patch in question can be found here: >>> >>> https://patchwork.kernel.org/patch/10092471/ >> >> And just in-case, "btrfs insp dump-super -fa" output could greatly help >> us to check if the backup superblocks are really good. >> > >
Attachment:
signature.asc
Description: OpenPGP digital signature
