Help recovering "overlapped" BTRFS partitions

[PinNoodle]

I recently had problems messing up with my disk partitioning (a venture which I did manually, basically trying to move my partitions to a different order, as you can imagine it has gone wrong). By using Testdisk (software that recovers partitions), I was able to recover my swap partitions and the Manjaro partition from which I write this. The problem is that my largest partition, the Linux Mint one, cannot be mounted, allegedly because it is overlapping another partition. My problem is that any attempt to move or resize the mint partition to eliminate the overlap is frustrated because all the programs I try recognize overlapping partitions and refuse to edit their positions. The mint partition is at the start of the disk. How can I move my mint partition without losing it (after all it has some important files) eliminating this problem and being able to mount it again? I don’t need to be able to boot it if not possible, jut mount it to be able to recover the files. I’m familiar with the terminal and able to try any fix possible, i just don’t know what to do next to try and fix this, if possible at all.

It is worth mentioning that both Manjaro and Mint partitions are in BTRFS, and i left some unallocated space to be able to move the partition if needed. Thanks in advance. Following are some images of the current state of my disks:

dmesg output:

[Teo]

Please convert all your terminal pictures of text to real text (ever heard of copy-paste?) and paste here after you click the </> button.

[PinNoodle]

$ sudo fdisk -l                                                                                                                                                                    
Disk /dev/sda: 447,13 GiB, 480103981056 bytes, 937703088 sectors
Disk model: KINGSTON SA400S3
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x81962616

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1            2048   4390911   4388864   2,1G 82 Linux swap / Solaris
/dev/sda2  *      4392960 309544959 305152000 145,5G 83 Linux
/dev/sda3       521601024 937703423 416102400 198,4G 83 Linux


Disk /dev/nvme0n1: 238,47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: SAMSUNG MZALQ256HAJD-000L2              
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6220B5A6-A65D-4CBC-B9A6-59E00897BE36

Device             Start       End   Sectors   Size Type
/dev/nvme0n1p1      2048    534527    532480   260M EFI System
/dev/nvme0n1p2    534528    567295     32768    16M Microsoft reserved
/dev/nvme0n1p3    567296 498069503 497502208 237,2G Microsoft basic data
/dev/nvme0n1p4 498069504 500117503   2048000  1000M Windows recovery environment

$ sudo mount /dev/sda2 /run/media/drive                                                                                                                                            
mount: /run/media/drive: can't read superblock on /dev/sda2.
       dmesg(1) may have more information after failed mount system call.

$ sudo btrfs check /dev/sda2                                                                                                                                                    
Opening filesystem to check...
checksum verify failed on 1064960 wanted 0x00000000 found 0xb6bde3e4
checksum verify failed on 1064960 wanted 0x00000000 found 0xb6bde3e4
bad tree block 1064960, bytenr mismatch, want=1064960, have=0
ERROR: cannot read chunk root
ERROR: cannot open file system

$ sudo dmesg | grep BTRFS                                                                                                                                                          
[    1.570090] BTRFS: device fsid 03542615-4ae1-432f-b6cf-0c2f51011069 devid 1 transid 97679 /dev/sda2 scanned by (udev-worker) (163)
[    1.570298] BTRFS: device fsid e1772e86-7c31-4e43-a88b-ce17bc8ad783 devid 1 transid 180220 /dev/sda3 scanned by (udev-worker) (176)
[    6.547553] BTRFS info (device sda3): first mount of filesystem e1772e86-7c31-4e43-a88b-ce17bc8ad783
[    6.547568] BTRFS info (device sda3): using crc32c (crc32c-intel) checksum algorithm
[    6.547578] BTRFS info (device sda3): disk space caching is enabled
[    6.552477] BTRFS info (device sda3): bdev /dev/sda3 errs: wr 0, rd 0, flush 0, corrupt 2, gen 0
[    6.618916] BTRFS info (device sda3): enabling ssd optimizations
[    6.618921] BTRFS info (device sda3): auto enabling async discard
[    8.533942] BTRFS info (device sda3: state M): use zstd compression, level 3
[  339.069741] BTRFS info (device sda2): first mount of filesystem 03542615-4ae1-432f-b6cf-0c2f51011069
[  339.069770] BTRFS info (device sda2): using crc32c (crc32c-intel) checksum algorithm
[  339.069783] BTRFS info (device sda2): disk space caching is enabled
[  339.071165] BTRFS error (device sda2): bad tree block start, mirror 1 want 1064960 have 0
[  339.071192] BTRFS error (device sda2): failed to read chunk root
[  339.072272] BTRFS error (device sda2): open_ctree failed
[  378.280346] BTRFS: device fsid 03542615-4ae1-432f-b6cf-0c2f51011069 devid 1 transid 97679 /dev/sda2 scanned by mount (3867)
[  378.280846] BTRFS info (device sda2): first mount of filesystem 03542615-4ae1-432f-b6cf-0c2f51011069
[  378.280866] BTRFS info (device sda2): using crc32c (crc32c-intel) checksum algorithm
[  378.280873] BTRFS info (device sda2): disk space caching is enabled
[  378.282001] BTRFS error (device sda2): bad tree block start, mirror 1 want 1064960 have 0
[  378.282020] BTRFS error (device sda2): failed to read chunk root
[  378.282451] BTRFS error (device sda2): open_ctree failed
[  518.273843] BTRFS: device fsid 03542615-4ae1-432f-b6cf-0c2f51011069 devid 1 transid 97679 /dev/sda2 scanned by mount (3997)
[  518.274331] BTRFS info (device sda2): first mount of filesystem 03542615-4ae1-432f-b6cf-0c2f51011069
[  518.274350] BTRFS info (device sda2): using crc32c (crc32c-intel) checksum algorithm
[  518.274358] BTRFS info (device sda2): disk space caching is enabled
[  518.275442] BTRFS error (device sda2): bad tree block start, mirror 1 want 1064960 have 0
[  518.275459] BTRFS error (device sda2): failed to read chunk root
[  518.275832] BTRFS error (device sda2): open_ctree failed
[  559.982249] BTRFS: device fsid 03542615-4ae1-432f-b6cf-0c2f51011069 devid 1 transid 97679 /dev/sda2 scanned by mount (4090)
[  559.987331] BTRFS info (device sda2): first mount of filesystem 03542615-4ae1-432f-b6cf-0c2f51011069
[  559.987393] BTRFS info (device sda2): using crc32c (crc32c-intel) checksum algorithm
[  559.987409] BTRFS info (device sda2): disk space caching is enabled
[  559.989195] BTRFS error (device sda2): bad tree block start, mirror 1 want 1064960 have 0
[  559.989217] BTRFS error (device sda2): failed to read chunk root
[  559.989633] BTRFS error (device sda2): open_ctree failed
[ 1380.447758] BTRFS: device fsid 03542615-4ae1-432f-b6cf-0c2f51011069 devid 1 transid 97679 /dev/sda2 scanned by (udev-worker) (4482)
[ 6507.336698] BTRFS info (device sda2): first mount of filesystem 03542615-4ae1-432f-b6cf-0c2f51011069
[ 6507.336720] BTRFS info (device sda2): using crc32c (crc32c-intel) checksum algorithm
[ 6507.336728] BTRFS info (device sda2): disk space caching is enabled
[ 6507.338574] BTRFS error (device sda2): bad tree block start, mirror 1 want 1064960 have 0
[ 6507.338614] BTRFS error (device sda2): failed to read chunk root
[ 6507.338934] BTRFS error (device sda2): open_ctree failed
[ 6647.934067] BTRFS: device fsid 03542615-4ae1-432f-b6cf-0c2f51011069 devid 1 transid 97679 /dev/sda2 scanned by mount (13398)
[ 6647.934547] BTRFS info (device sda2): first mount of filesystem 03542615-4ae1-432f-b6cf-0c2f51011069
[ 6647.934567] BTRFS info (device sda2): using crc32c (crc32c-intel) checksum algorithm
[ 6647.934574] BTRFS info (device sda2): disk space caching is enabled
[ 6647.935887] BTRFS error (device sda2): bad tree block start, mirror 1 want 1064960 have 0
[ 6647.935907] BTRFS error (device sda2): failed to read chunk root
[ 6647.936245] BTRFS error (device sda2): open_ctree failed

[dgdg]

So, I’ll start with the disclaimer: without knowing what happened to the partitions before you ran Testdisk, and what exactly Testdisk did, it’s kind of impossible to know what state things are in. Clearly Testdisk must have done some resizing because the partitions are no longer overlapping, but beyond that it’s unknown. In general, the first rule of data recovery for most people is “stop touching things, get expert help”.

So first thing: If there are genuinely important files on the disk (as in there are difficult consequences for losing the data), you probably should stop touching things and get expert help. That likely rules out the random advice from this forum - you should make enquiries with data recovery companies and try their services instead. If what you want to recover isn’t that important, read on.

Firstly, I would recommend taking a disk image of your drive for recovery purposes, assuming that you have the storage available. Most partition managers can do this; just boot from a USB, take a disk image. This way, if something goes wrong, you can at least get back to your current state.

In terms of fixing things, the best thing I can suggest is running btrfs rescue chunk-recover /dev/sda2. According to the docs, that’s a good starting point for chunk root problems - although it will take a while. That might get the partition to a state where it can be mounted. If it does, back up all files you want - although note that it’s possible there has been some data loss, so hopefully you can get the important files at least.

After that, if you have gotten all your important files out, I’d recommend just deleting the old partition and starting over. If you haven’t managed to get your files out, then it’s probably time to find a data recovery service. Make sure to give them the disk image you backed up earlier, and explain what’s happened and what you did in detail.

[PinNoodle]

Well, besides a typical Linux mint installation this partitions contain some old projects from my graduation, which would be cool to have for archival purposes but certainly are not a life or death situation, that’s why I don’t believe is worth to pay the prices of a data recovery service to have a dozen of project files back, so I’m happy to try the solution that someone more experienced than me can provide here.

When i tried to move the mint partition I somehow ended up corrupting the disk entirely and Testdisk was able to bring the old structure back, with all partitions working but the Linux mint one. I can’t say exactly what was done but it did in fact brought the data on the disk back to accessibility.

Running the command that you provided resulted in:

$ sudo btrfs rescue chunk-recover /dev/sda2                                                                                                                                   
Scanning: DONE in dev0                        
no recoverable chunk

I assumed that there will be no issue running this from my Manjaro partition. Should i try it from a live environment?

[dgdg]

You could try, but I suspect there’s little point in doing so. It’ll be a similar version of btrfs-progs, after all.

The next thing to try would be running undelete-btrfs on the partition. That’s a frontend to btrfs restore which may be able to salvage some specific files (like, for example, the /home/ directory).

As a last desperate attempt, you could also try the following commands:

# Try to mount with backup root
mkdir mount
mount -o rescue=usebackuproot /dev/sda2 mnt
# Try to recover super blocks
sudo btrfs rescue super-recover /dev/sda2 

However, my take on this is that it really doesn’t look good.

[PinNoodle]

The script you provided was not able to find data

=====================================================
| Undelete-BTRFS | Dry-run results | Depth-level: 2 |
=====================================================
Path entered: home/.* 
Regex generated: '^/(|home(|/.*))$' 
Depth-level: 2

No data found :(
Unable to find any data with the provided path at any depth level, please verify the entered path and try again
Keep in mind that directory paths must end with a '/' 
For more rules/examples see https://github.com/danthem/undelete-btrfs

Press Enter to return to start...

nor trying to mount /dev/sda2 with the rescue option or recover the superblocks

$ sudo mount -o rescue=usebackuproot /dev/sda2 mnt                                                                                                                   
mount: mnt: can't read superblock on /dev/sda2.
       dmesg(1) may have more information after failed mount system call.

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

looking at the dmesg output again which is very similar to the above one I noticed that the mount process looks for a value that cannot be found hence the “want” and “have” denominations. Is there a way to forcefully provide the wanted value so the mount command will proceed? I can deal with something more low level if needed.

[ 6647.935887] BTRFS error (device sda2): bad tree block start, mirror 1 want 1064960 have 0
[ 6647.935907] BTRFS error (device sda2): failed to read chunk root
[ 6647.936245] BTRFS error (device sda2): open_ctree failed

[Kobold]

@PinNoodle

(after all it has some important files)

If it had important files, you should had a backup.

[dgdg]

I’m afraid I’d label this situation as almost entirely hopeless now.

It very much looks like at some point the Mint partition has been destroyed somehow. This could have been by being overwritten, or it could have been by being marked as unused and the SSDs trim mechanism deleting the data. The reason why I say this is that none of the scripts or commands are even able to identify the partition as having any BTRFS data on it.

To answer the question about want/have in the dmesg output, this is just checksum data. Correctly formatted BTRFS blocks have checksums for error detection. Tools like undelete-btrfs scan through every potential block and look to see if they look like a valid BTRFS block; the fact that it said No data found :( suggests that there are no blocks that have valid checksums, which basically means nothing can be recovered.

The only possible way I can think that there might be valid data is if you’ve somehow misremembered the partition type of the Mint partition and it’s actually ext4 or something else. But assuming it is indeed BTRFS, then I think this is the point at which this becomes a learning experience on the importance of backups, I’m afraid.

[Nachlese]

@PinNoodle

but it did in fact brought the data on the disk back to accessibility.

Maybe I don’t understand - but at this point I’d access it and save it to somewhere else.

[PinNoodle]

@Nachlese

Maybe I don’t understand - but at this point I’d access it and save it to somewhere else.

Everything is back except the mint partition, that was what i meant to say.

@dgdg

The only possible way I can think that there might be valid data is if you’ve somehow misremembered the partition type of the Mint partition and it’s actually ext4 or something else.

I’m sure that this is indeed a BTRFS partition, but if there’s no hope for me I’ll just wipe this partition though. But anyway thanks for your time and efforts on helping me!

[dgdg]

Yeah, I’m afraid I can’t see a sensible way forward.

If you’re desperate, you could try using grep or similar to search the entire disk (including the unallocated space) for some string that you know is in a file you want to recover - i.e. literally opening the entire disk as a file from a live USB and searching. However, the problem is that SSDs preemptively wipe sectors and you’ve been using the device - never mind the difficulty of recovering files if you get a hit.

In any case, if this thread is done, please mark something as a “solution” so it can be closed.

[soundofthunder]

If you wish to keep any data from the partition, you could likely image it, assuming (as @dgdg previously mentioned) that you have sufficient storage space (elsewhere) to store the image.

The Disks app should be useful for this:

sudo pacman -S gnome-disk-utility

The partition does not need to be mounted during imaging. Once it’s completed, you should verify that you can open/mount the image. With any luck you can simply drag the files from the image at your leisure; and delete the original partition completely.

Of course, imaging success would depend on the state of the partitions, which seems to be unknown to any great certainty.

Good luck.

[dgdg]

@soundofthunder

Once it’s completed, you should verify that you can open/mount the image

Please read the rest of the thread - the partition seems to be completely borked. All reasonable steps to mount and recover any data from the partition have failed so far, and as I said, the most likely explanation is that all data in the partition has been destroyed by some mechanism (overwriting or SSD trimming).

Of course, backing things up is a good idea in general, but right now it feels like shutting the stable door after the horse has bolted. And in any case, that backup isn’t going to open.

[soundofthunder]

@dgdg

And in any case, that backup isn’t going to open.

I agree the confidence isn’t high, but still possible; and a resultant image might still be accessible. It can certainly do no harm at this point. You even suggested it yourself.

@dgdg

I would recommend taking a disk image of your drive for recovery purposes, assuming that you have the storage available.

In any case, the partition sizes are fairly large, which might also make the attempt more trouble than it’s worth.

Yes, I read the rest of the thread.

[PinNoodle]

I’ll try the imaging method and see what i can find, but I’ll need some days to get the disk space need for imaging as i don’t have any spare drivers laying around, so please don’t close this thread yet.

[soundofthunder]

@PinNoodle

I’ll try the imaging method and see what i can find, but I’ll need some days to get the disk space need for imaging as i don’t have any spare drivers laying around, so please don’t close this thread yet.

The thread should stay open at least until you mark a post as the solution, so, no problem there. I hope you have some success.

Cheers.

[Molski]

I’m sure you understand what happened now. (I was following this before.) But if you overlap a partition, and do something like boot it once, the one underneath will get corrupted. How bad just depends.

What do you need from the drive? Unfortunately, btrfs doesn’t have the amount of tools for this purpose compared to MS filesystems and even ext#. But there are tools out there that will try to recover data in reverse, by reading the data blocks, then attempting to put the metadata and structure around it.

I have no idea if this works, and I would be surprised it is did (it was just first result), but something like: https://github.com/shujianyang/btrForensics

Even then, these are shots in the dark, especially with btrfs, as it’s a newer and not quite as common. Unlike the ones made for filesystems like FAT32.

[PinNoodle]

So, after dabbling for a while with this I’ve decided to call it quits.

I’ve learned some things along the way, the main one being to take disk and partition management with care. Even more than a backup I ended up in this situation for being reckless while dealing with my partitions. Thankfully computing has evolved to the point where my damage was just collateral, and the files that really mattered were safe (by luck or because they were in a less affected area of the disk).

Anyway, if this post is being of any use I will try to explain what I’ve done so far.

The imaging process was done just fine, but any attempt at recovery was fruitless and dealing with the hex is not some easy feat. In fact I was being increasingly discouraged by understanding that the filesystem was damaged at a binary level, turning it into a impossible venture to recover, at least by the methods I was capable to try, especially because BTRFS being in a messy state didn’t made me any favors while trying to determine where a file ends and other starts.

I can’t explain exactly why it happened but during the first recover of the damaged partitions with testdisk, it probably tried to write beyond the limits of my disk, and I say this because even after formatting the damaged partition and putting new files on it, when opening a disk management tool (like gparted for example) I still face the following warning, despite all partitions being now perfectly readable.

This pop-up is shown twice before gparted let me use it, witch hints me that there is something written beyond limits both at the start and at the end of my SSD.

Yes, i could have came here with the hex of the disk and more information asking for more help but I believe that at this point that would just be a waste of time in a venture for files that at the end of the day are just a bunch of college project files, witch if I really want to, I can just recreate (would take some time but still). Maybe the worst part is the cinnamon interface tweaks and visual changes that if I ever decide to install again will have to do from scratch, and this is sad because I’ve had invested a lot of time customizing it.

So, in any case thanks to everyone for your time and efforts in trying to help me.