How do I recover a BTRFS partition that will not mount?

Solution 1:

Easiest way

btrfs-zero-log /dev/sda5

Your getting that issue because a transaction(write or delete) is stuck in the journal log and the disk doesnt match it.

How it works:

So when data is written 1st its written to journal then to disk (or at same time, but journal just saves metadata about the upcoming write - not sure... need more research on that part)...

Anyhow if you turn off the system in the middle of this write/delete or do something that hickups the system (dismount the USB that holds your btrfs mount point), then when it returns that mount will not work it will fail (dmesg and btrfsck will show you the errors in more detail)...

Looking at dmesg you will see those same transid messages.

You will see something like this:

parent transid verify failed on 109973766144 wanted 1823 found 1821

It means that btrfs wanted transid 1823 (That was on the journal) but on the disk it saw 1821. So the disk was 2 transactions away from being in sync with journal. I personally would risk a brtfs-zero-log here just because its only 2 transactions. But to be 100% safe if this is your only data (by the way if you have critical data you should NEVER EVER have only 1 copy of it, always have a copy/backup in a safe other location - blaming the creators of btrfs wouldnt justify against the persons own lack of responsibility of not having a backup - btrfs is not backup solution, its a filesystem - nothing is a true backup solution besides having a copy of it else where - not even parity or mirrored drives, a true backup is sitting somewhere underground in the Alps while its active copy is in your office in Texas)

parent transid verify failed on 31302336512 wanted 62455 found 62456

Here the journal is wanting 62455 but the disk is one ahead at 62456, so in your case i would just clear the journal. Journal didnt update this time. Again I told you bout being safe thing, if its your only data and its mega critical (shame on you), and I would do the below operations first to be safe.

Running a btrfsck /dev/sda5 (which by the way just does a readonly check so its completely safe, its only btrfsck options that you have to worry about) will also show you those messages.

But beware if that data is critical, i would first do (As the other gents said)

mount -t btrfs -o rootflags=recovery,nospace_cache /dev/sda3 /mnt/sda3

mount -t btrfs -o rootflags=recovery,nospace_cache,clear_cache /dev/sda3 /mnt/sda3

mount -t btrfs -o recovery,nospace_cache,clear_cache /dev/sda3 /mnt/sda3

Then cp or rsync all of your files over to safe location, then when safe do the btrfs-zero-log, if its a successful operation you just wasted alot of time backing up your system (but if its not successful, you just saved your arse)

Then if the mounts failed do a btrfs restore (dump of the system, as I understand its a resumeable operation, however it keeps asking for Y or y every now and again so watch the output)

btrfs restore /dev/sda5 /USB

Then when safe (when btrfs restore is done) do the btrfs-zero-log, if its a successful operation you just wasted alot of time backing up your system (but if its not successful, you just saved your arse)

You can run screen first

screen /bin/bash

btrfs restore /dev/sda5 /USB

SCREEN SIDE NOTE

To detach (command will still run): CONTROL-a then type ":detach" without the quotes then press ENTER

Another way to detach: Then close out of putty or your terminal and it will detach (the command / restore will still run).

To check up on it, just screen back to it:

screen -x

screen -x will attach to sessions, even if detached, and unlike -h says, it will attach even if its already attached as well)

If you have several screens, screen -x will tell you need to be more specific to attach to the session:

screen -ls

ls for list all sessions, easy to remember that.

to see the PID you can also do this:

ps aux | grep screen

Once you find out your PID, then run screen like this:

screen -x PID

That will attach to a specific session. You can have several sessions/puttys attached to the same screen (they will output the same text, you can type commands in one, and they will be mirrored on the other putty)

Solution 2:

Mount on boot using root fs mount options:

rootflags=recovery,nospace_cache

or

rootflags=recovery,nospace_cache,clear_cache

The full list of btrfs mount options should be here https://btrfs.wiki.kernel.org/index.php/Mount_options and other things may be useful also, such as noatime,nodatacow (fixed a kernel bug for me giving me a chance to copy my files).

Add it to your grub.cfg / menu.lst, or type it in when booting.

The nospace_cache stuff will make things terribly slow. Just boot up, wait (long), shut down, and boot normally.

I had the same thing a few days ago, and the above fixed it. But also afterwards, there were some space issues... the space reported is not 100% but it can still say out of space.

==

I think you can also add the same options in your fstab, for example:

UUID=0237alksfadg-lhdfkj3624-4fdfjb-9dsfe2d-dfddaf /home btrfs defaults,recovery,nospace_cache,clear_cache,subvol=@home 0  
 2

If you were trying to recover a /home directory mounted over a partition with UUID=0237alksfadg-lhdfkj3624-4fdfjb-9dsfe2d-dfddaf.

Solution 3:

Peter's answer solved the problem for me, although not on Ubuntu. I had a /home partition btrfs'd that got of course corrupted. The system would not boot up because it was on fstab. I entered maintenance mode, hashed out the line with that partition, and booted up normally( I had a spare ext4 partition I could use as /home).

I mounted the partition manually with the following command :

mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3 and was actually able to save my data. Although it did not take that long to mount it. So THANKS Peter.