Re: Trying to recover data from SSD

[Konstantin Svist <fry.kun@gmail.com>]

On 8/20/21 19:56, Konstantin Svist wrote:
> On 8/11/21 18:18, Qu Wenruo wrote:
>>
>> On 2021/8/12 上午6:34, Konstantin Svist wrote:
>>> Shouldn't there be an earlier generation of this subvolume's tree block
>>> somewhere on the disk? Would all of them have gotten overwritten
>>> already?
>> Then it will be more complex and I can't ensure any good result.
>
> It was already pretty complex and results were never guaranteed :)
>
>
>> Firstly you need to find an older root tree:
>>
>> # btrfs ins dump-super -f /dev/sdb3 | grep backup_tree_root
>>                 backup_tree_root:       30687232        gen: 2317
>>  level: 0
>>                 backup_tree_root:       30834688        gen: 2318
>>  level: 0
>>                 backup_tree_root:       30408704        gen: 2319
>>  level: 0
>>                 backup_tree_root:       31031296        gen: 2316
>>  level: 0
>>
>> Then try the bytenr in their reverse generation order in btrfs ins
>> dump-tree:
>> (The latest one should be the current root, thus you can skip it)
>>
>> # btrfs ins dump-tree -b 30834688 /dev/sdb3 | grep "(257 ROOT_ITEM" -A 5
>>
>> Then grab the bytenr of the subvolume 257, then pass the bytenr to
>> btrfs-restore:
>>
>> # btrfs-restore -f <bytenr> /dev/sdb3 <restore_path>
>>
>> The chance is already pretty low, good luck.
>>
>> Thanks,
>> Qu 
>
>
> When I run dump-tree, I get this:
>
> # btrfs ins dump-tree -b 787070976 /dev/sdb3 | grep "(257 ROOT_ITEM" -A 5
> checksum verify failed on 786939904 wanted 0xcdcdcdcd found 0xc375d6b6
> checksum verify failed on 786939904 wanted 0xcdcdcdcd found 0xc375d6b6
> checksum verify failed on 786939904 wanted 0xcdcdcdcd found 0xc375d6b6
> Csum didn't match
> WARNING: could not setup extent tree, skipping it
>
> The same exact offset fails checksum for all 4 backup roots, any way
> around this?


*ping*

Any hope left here?