On 2021/8/29 下午2:34, Konstantin Svist wrote:

On 8/28/21 16:30, Qu Wenruo wrote:

quoted

On 2021/8/29 上午7:16, Konstantin Svist wrote:

quoted

On 8/27/21 23:16, Qu Wenruo wrote:

quoted

On 2021/8/28 下午1:57, Konstantin Svist wrote:

quoted

On 8/20/21 19:56, Konstantin Svist wrote:

quoted

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

quoted

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 :)

quoted

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?

When without the grep, is there any output?

# btrfs ins dump-tree -b 787070976 /dev/sdb3
btrfs-progs v5.13.1
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
node 787070976 level 1 items 7 free space 486 generation 166932 owner
ROOT_TREE
node 787070976 flags 0x1(WRITTEN) backref revision 1
fs uuid 44a768e0-28ba-4c6a-8eef-18ffa8c27d1b
chunk uuid a8a06213-eebf-40d8-ab1a-914f621fbe1c
      key (EXTENT_TREE ROOT_ITEM 0) block 787087360 gen 166932
      key (277 INODE_ITEM 0) block 197491195904 gen 56511
      key (305 INODE_ITEM 0) block 778174464 gen 166929
      key (366 EXTENT_DATA 0) block 197491949568 gen 56511
      key (428 INODE_ITEM 0) block 36175872 gen 166829
      key (476 INODE_ITEM 0) block 787234816 gen 166932
      key (FREE_SPACE UNTYPED 99888398336) block 780812288 gen 166929

My bad, I forgot to add "--follow" option for "btrfs ins dump-tree"

So the full command is:

$ btrfs ins dump-tree -b 787070976 --follow /dev/sdb3

Then you should be able to find "(257 ROOT_ITEM".

# btrfs ins dump-tree -b 787070976 --follow /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
     item 13 key (257 ROOT_ITEM 0) itemoff 13147 itemsize 439
         generation 166932 root_dirid 256 bytenr 786726912 level 2 refs 1
         lastsnap 56690 byte_limit 0 bytes_used 1013104640 flags 0x0(none)
         uuid 1ac60d28-6f11-2842-aca2-b1574b108336
         ctransid 166932 otransid 8 stransid 0 rtransid 0
         ctime 1627959592.718936423 (2021-08-02 19:59:52)


# btrfs restore -Divf 786726912 /dev/sdb3 .
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
This is a dry-run, no files are going to be restored
checksum verify failed on 920748032 wanted 0x00000000 found 0xb6bde3e4
checksum verify failed on 920748032 wanted 0x00000000 found 0xb6bde3e4
checksum verify failed on 920748032 wanted 0x00000000 found 0xb6bde3e4
bad tree block 920748032, bytenr mismatch, want=920748032, have=0
ERROR: search for next directory entry failed: -5

This all zero means the data on-disk are wiped.

Either not reaching disk or discarded.

Neither is a good thing.

1st set of "checksum verify failed" has different addresses, but the
last set always has 920748032

Have you tried other bytenrs from find-root?

Thanks,
Qu