Re: Recover btrfs partition after accidental reformat

[Emil <broetchenrackete@gmail.com>]

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