Recover btrfs partition after accidental reformat

Recover btrfs partition after accidental reformat

[Emil]

Hi,

I did a boo boo and reformatted my btrfs partition with NTFS (used the wrong /dev/sdX). It was a single drive with standard options (metadata dup, data single) and it was the only partition of the drive.

I have not written any data to the ntfs partition.

Is there any chance of data recovery? The only thing I found was a backup superblock:

[bluemond@BlueQ ~]$ sudo btrfs insp dump-su -s 2 /dev/sdh1
superblock: bytenr=274877906944, device=/dev/sdh1
---------------------------------------------------------
csum_type               0 (crc32c)
csum_size               4
csum                    0x69883d2a [match]
bytenr                  274877906944
flags                   0x1
                        ( WRITTEN )
magic                   _BHRfS_M [match]
fsid                    6dc337f5-2146-4aa5-a9c1-8faf1e2994c5
metadata_uuid           6dc337f5-2146-4aa5-a9c1-8faf1e2994c5
label
generation              7004
root                    436338688
sys_array_size          129
chunk_root_generation   7002
root_level              0
chunk_root              22020096
chunk_root_level        0
log_root                0
log_root_transid        0
log_root_level          0
total_bytes             2000397864960
bytes_used              125869297664
sectorsize              4096
nodesize                16384
leafsize (deprecated)   16384
stripesize              4096
root_dir                6
num_devices             1
compat_flags            0x0
compat_ro_flags         0x3
                        ( FREE_SPACE_TREE |
                          FREE_SPACE_TREE_VALID )
incompat_flags          0x341
                        ( MIXED_BACKREF |
                          EXTENDED_IREF |
                          SKINNY_METADATA |
                          NO_HOLES )
cache_generation        0
uuid_tree_generation    7004
dev_item.uuid           0c86cfd6-fc28-4f99-9b4a-6bd3546aa523
dev_item.fsid           6dc337f5-2146-4aa5-a9c1-8faf1e2994c5 [match]
dev_item.type           0
dev_item.total_bytes    2000397864960
dev_item.bytes_used     131021668352
dev_item.io_align       4096
dev_item.io_width       4096
dev_item.sector_size    4096
dev_item.devid          1
dev_item.dev_group      0
dev_item.seek_speed     0
dev_item.bandwidth      0
dev_item.generation     0



I tried using photorec, but the btrfs partition was pretty fresh and I had a ntfs partition with lots of data before that so it finds all kinds of data from the old ntfs partition.

Re: Recover btrfs partition after accidental reformat

[Chris Murphy]

On Mon, Mar 7, 2022 at 1:10 PM Emil <broetchenrackete@gmail.com> wrote:
>
> Hi,
>
> I did a boo boo and reformatted my btrfs partition with NTFS (used the wrong /dev/sdX). It was a single drive with standard options (metadata dup, data single) and it was the only partition of the drive.

You'll have damaged files most likely but there's some chance that
with DUP metadata the file system can self-repair its way out of this
mistake.

You could check out
https://raid.wiki.kernel.org/index.php/Irreversible_mdadm_failure_recovery#Simple_using_of_overlays
for guidance on how to use device-mapper to make the drive partition
read-only, and redirect any recovery attempts (writes) to a file so
that it's all reversible. Or take a chance and just apply the changes
to the partition directly... thought it could make things worse.

My thought is to start out with wiping the NTFS signature only, and
making a backup of it (optional, sorta boilerplate but it sounds like
you don't care about this NTFS file system anyway since it was a
mistake).

wipefs -b -t ntfs /dev/sdXY

Next, check status of superblocks before repairing them:

btrfs rescue super -v /dev/sdXY

If there are damaged superblocks it should give you a choice to repair
them from a good superblock. You can do that. Next, try to mount it.
If you're on overlay, just mount it normally and see what happens. If
not, you might go more conservative with

mount -o ro /dev/sdXY

I'm actually not fully sure that this prevents all writes. i.e. if
there's DUP metadata, and btrfs finds corruption with one copy, pretty
sure it tries to write fixups from a good copy. The ro is a VFS mount
option, and enforces no writes from user space, but the kernel code
can still write. I think. So it's a small risk.

I'd probably do this with a current stable or mainline kernel, i.e.
5.15+. This also allows you the option to use combinations of the
rescue= mount options along with ro, in case too much metadata is
damaged for normal mount, you can sometimes skip over the broken
parts. If you're lucky, you might just end up with only some corrupt
files. This will definitely produce a *lot* of btrfs kernel messages,
you will get around 1/2 dozen at least per 4KiB block damaged.

Good luck!


-- 
Chris Murphy

Re: Recover btrfs partition after accidental reformat

[Emil]

Thanks for the tip with the overlay. Unfortunately recovering superblocks isn't working:


[bluemond@BlueQ btrfsoverlay]$ sudo btrfs rescue super -v /dev/mapper/sdh1
All Devices:
        Device: id = 1, name = /dev/mapper/sdh1

Before Recovering:
        [All good supers]:
                device name = /dev/mapper/sdh1
                superblock bytenr = 274877906944

        [All bad supers]:
                device name = /dev/mapper/sdh1
                superblock bytenr = 65536

                device name = /dev/mapper/sdh1
                superblock bytenr = 67108864


Make sure this is a btrfs disk otherwise the tool will destroy other fs, Are you sure? [y/N]: y
checksum verify failed on 22020096 wanted 0x00000000 found 0xb6bde3e4
checksum verify failed on 22020096 wanted 0x00000000 found 0xb6bde3e4
ERROR: cannot read chunk root
Failed to recover bad superblocks

[bluemond@BlueQ btrfsoverlay]$ uname -a
Linux BlueQ 5.16.12-arch1-1 #1 SMP PREEMPT Wed, 02 Mar 2022 12:22:51 +0000 x86_64 GNU/Linux

[bluemond@BlueQ btrfsoverlay]$ btrfs version
btrfs-progs v5.16.2

For some reason I can't find anything btrfs related in dmesg...

8 Mar 2022 00:29:30 Chris Murphy <lists@colorremedies.com>:

> On Mon, Mar 7, 2022 at 1:10 PM Emil <broetchenrackete@gmail.com> wrote:
>> 
>> Hi,
>> 
>> I did a boo boo and reformatted my btrfs partition with NTFS (used the wrong /dev/sdX). It was a single drive with standard options (metadata dup, data single) and it was the only partition of the drive.
> 
> You'll have damaged files most likely but there's some chance that
> with DUP metadata the file system can self-repair its way out of this
> mistake.
> 
> You could check out
> https://raid.wiki.kernel.org/index.php/Irreversible_mdadm_failure_recovery#Simple_using_of_overlays
> for guidance on how to use device-mapper to make the drive partition
> read-only, and redirect any recovery attempts (writes) to a file so
> that it's all reversible. Or take a chance and just apply the changes
> to the partition directly... thought it could make things worse.
> 
> My thought is to start out with wiping the NTFS signature only, and
> making a backup of it (optional, sorta boilerplate but it sounds like
> you don't care about this NTFS file system anyway since it was a
> mistake).
> 
> wipefs -b -t ntfs /dev/sdXY
> 
> Next, check status of superblocks before repairing them:
> 
> btrfs rescue super -v /dev/sdXY
> 
> If there are damaged superblocks it should give you a choice to repair
> them from a good superblock. You can do that. Next, try to mount it.
> If you're on overlay, just mount it normally and see what happens. If
> not, you might go more conservative with
> 
> mount -o ro /dev/sdXY
> 
> I'm actually not fully sure that this prevents all writes. i.e. if
> there's DUP metadata, and btrfs finds corruption with one copy, pretty
> sure it tries to write fixups from a good copy. The ro is a VFS mount
> option, and enforces no writes from user space, but the kernel code
> can still write. I think. So it's a small risk.
> 
> I'd probably do this with a current stable or mainline kernel, i.e.
> 5.15+. This also allows you the option to use combinations of the
> rescue= mount options along with ro, in case too much metadata is
> damaged for normal mount, you can sometimes skip over the broken
> parts. If you're lucky, you might just end up with only some corrupt
> files. This will definitely produce a *lot* of btrfs kernel messages,
> you will get around 1/2 dozen at least per 4KiB block damaged.
> 
> Good luck!
> 
> 
> -- 
> Chris Murphy

Re: Recover btrfs partition after accidental reformat

[Chris Murphy]

On Tue, Mar 8, 2022 at 3:20 PM Emil <broetchenrackete@gmail.com> wrote:
>
> Thanks for the tip with the overlay. Unfortunately recovering superblocks isn't working:
>
>
> [bluemond@BlueQ btrfsoverlay]$ sudo btrfs rescue super -v /dev/mapper/sdh1
> All Devices:
>         Device: id = 1, name = /dev/mapper/sdh1
>
> Before Recovering:
>         [All good supers]:
>                 device name = /dev/mapper/sdh1
>                 superblock bytenr = 274877906944
>
>         [All bad supers]:
>                 device name = /dev/mapper/sdh1
>                 superblock bytenr = 65536
>
>                 device name = /dev/mapper/sdh1
>                 superblock bytenr = 67108864
>
>
> Make sure this is a btrfs disk otherwise the tool will destroy other fs, Are you sure? [y/N]: y
> checksum verify failed on 22020096 wanted 0x00000000 found 0xb6bde3e4
> checksum verify failed on 22020096 wanted 0x00000000 found 0xb6bde3e4
> ERROR: cannot read chunk root
> Failed to recover bad superblocks

If both copies of the chunk root are damaged, then the file system is
toast. It's a critical tree, if it can't be read then none of the
addresses for file locations can be figured out. Most mkfs write a lot
of zeros on purpose to wipe away portions of previous file systems
that could tend to confuse the new one and so it would seem NTFS's
mkfs has zero'd too much.

I don't really have any good suggestions.

-- 
Chris Murphy