Mounting bad btrfs img file

Mounting bad btrfs img file

[Eric Wolf]

My OS drive had issues with metadata (disk full even though it wasn't
etc), and so I reinstalled my OS and now I'm learning that my backup
img is bad. What steps should I go through to fix it?


$ sudo mount -o
offset=8999927808,loop,recovery,ro,nospace_cache,nospace_cache
/data/Backup/Nephele.img /mnt

mount: wrong fs type, bad option, bad superblock on /dev/loop0,

       missing codepage or helper program, or other error


       In some cases useful info is found in syslog - try

       dmesg | tail or so.

nephele@Nephele:/data/Backup$ dmesg | tail

[48539.443711] BTRFS error (device loop0): parent transid verify
failed on 98021605376 wanted 85976 found 85978

[48539.473837] BTRFS error (device loop0): parent transid verify
failed on 98021605376 wanted 85976 found 85978

[48539.485032] BTRFS: failed to read tree root on loop0

[48539.494782] BTRFS error (device loop0): parent transid verify
failed on 98049490944 wanted 85975 found 85981

[48539.510541] BTRFS error (device loop0): parent transid verify
failed on 98049490944 wanted 85975 found 85981

[48539.523464] BTRFS: failed to read tree root on loop0

[48539.526374] BTRFS error (device loop0): parent transid verify
failed on 98020917248 wanted 85974 found 85979

[48539.545628] BTRFS error (device loop0): parent transid verify
failed on 98020917248 wanted 85974 found 85979

[48539.560595] BTRFS: failed to read tree root on loop0

[48539.589038] BTRFS: open_ctree failed

Re: Mounting bad btrfs img file

[Duncan]

Eric Wolf posted on Thu, 05 Oct 2017 09:38:18 -0400 as excerpted:

> My OS drive had issues with metadata (disk full even though it wasn't
> etc), and so I reinstalled my OS and now I'm learning that my backup img
> is bad. What steps should I go through to fix it?

Ugh...  Looks like you just got hit by the second sysadmin's rule of 
backups:  A backup isn't a backup until it's tested.  A would-be backup 
that's not tested isn't a backup, only a potential backup, because a 
backup isn't complete until you've verified that you can restore from it.

> $ sudo mount -o
> offset=8999927808,loop,recovery,ro,nospace_cache,nospace_cache
> /data/Backup/Nephele.img /mnt
> 
> mount: wrong fs type, bad option, bad superblock on /dev/loop0,

> nephele@Nephele:/data/Backup$ dmesg | tail
> 
> [48539.443711] BTRFS error (device loop0): parent transid verify failed
> on 98021605376 wanted 85976 found 85978

Those transids aren't too far apart, good. =:^)

You're already trying ro,recovery (which BTW is deprecated, replaced by 
usebackuproot), the first suggestion.

While various repair options can be tried, that's best done with a 
(tested) backup available.  Since this /is/ your backup and you don't 
have a working copy...

I'd suggest trying btrfs restore.  This command will attempt to restore 
files from the unmounted filesystem, writing them to a suitable 
location.  Obviously that means you need another operational filesystem 
available to write to, with a suitable amount of space available.  The 
nice thing about restore is that unlike check with the repair option or 
similar fix-or-make-worse options, while restore /does/ need space to 
restore the files to, it doesn't actually write anything to the 
filesystem it's restoring from, so it won't damage it further. =:^)

With luck restore will work in "simple" mode, and the fact that your 
wanted transids are close to those found gives you a pretty good chance 
simple mode will work just fine.  If it doesn't, then you have to try 
manual mode, giving restore more information, found via btrfs-find-root 
and fed to restore using -r.  There's a page on the wiki describing 
restore usage in this mode, tho it may not be entirely current so some 
additional translation of terms, etc, may be necessary.

https://btrfs.wiki.kernel.org/index.php/Restore

Note that in either mode you'll probably want the options to restore user 
permissions, symlinks, etc, not just the raw files.  Without these 
options you'll get the files, but written using normal user (root in this 
case) and umask settings, and symlinks won't be restored.  My own last 
usage was before these options were available, and I had to restore user/
group and perms metadata manually, as well as symlinks.  Also, note the 
dry-run option.  You can use this to see if it looks like restore will 
work (if it looks like it's going to be able to get most of your files) 
before actually trying it live.

Once you have your files restored if possible, or have given up on btrfs 
restore, you can try other stuff on the broken filesystem, or simply give 
up and wipe it to start over.  Since I have (tested) backups (altho they 
may not always be as current as I'd like, the reason I've had to try 
restore here, generally with good luck), I may try a couple fairly simple 
things like btrfs check --repair, but if that doesn't work, I generally 
wipe and restore from backups, so I don't have experience with the real 
complicated stuff.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman