On 2017年12月29日 09:41, Stirling Westrup wrote:
> Okay, I ran the command 'btrfs ins dump-super -fa' on each of the four
> drives of the array, which are currently sda, sdb, sdc, and sde, and
> attached the results as log files.
>
> As you'll note, the one superblock for sde is an exact copy of the one
> for sdc, as I copy the first 4M of sdc to sde before starting the
> recovery of the bad drive (sde is as much of that drive as I could
> copy, which all my tools claim is close to 99.99% of the original).
Well, from the result of e.log, there are no backup supers at all.
So either there is a offset when the data is recovered, or you lost most
of your data.
The good news is, according to the correct supers of devid 1/3/4, at
least your system and meta profile is RAID1, and they should be at least
RO degraded mountable.
Yes, this means you could get the needed device UUID and hand craft a
superblock.
But I really doubt about the possibility to success.
If you really want to do that, there is needed steps for you:
1) Get device info from your existing fs
# btrfs ins dump-tree -t chunk </dev/sda>
And looking for the following thing:
------
item 1 key (DEV_ITEMS DEV_ITEM 2) itemoff 16185 itemsize 98
devid 2 total_bytes 10737418240 bytes_used 289406976
io_align 4096 io_width 4096 sector_size 4096 type 0
generation 0 start_offset 0 dev_group 0
seek_speed 0 bandwidth 0
uuid f1d9b288-7865-463f-a65c-ca8b1fbde09b
fsid 1dd513fb-45f8-404f-ae23-979e3acb78ad
------
Look for the key (DEV_ITEMS DEV_ITEM 2) and grab the "uuid"
"total_bytes" "bytes_used" (other fields are mostly fixed)
2) Fill the fields of dev_item of a good superblock.
If you feel it hard, I could help to do it if you provide the binary
dump of any valid superblock, with above tree dump info.
But as I mentioned before, the disk seems to be heavily damaged or have
an unexpected offset.
Recovery using such method can easily lead to csum error and most (if
not all) RAID0 based data will unable to be read out.
I strongly recommend to do a binary search for magic number "5f42 4852
6653 5f4d" to locate the real offset (if it's offset, not a toasted image)
Thanks,
Qu
>
>
> On Thu, Dec 28, 2017 at 7:22 PM, Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote:
>>
>>
>> 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
