On 8/11/21 18:18, Qu Wenruo wrote:

On 2021/8/12 上午6:34, Konstantin Svist wrote:

quoted

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?