* Re: Mounting bad btrfs img file
2017-10-05 13:38 Mounting bad btrfs img file Eric Wolf
@ 2017-10-06 7:20 ` Duncan
0 siblings, 0 replies; 2+ messages in thread
From: Duncan @ 2017-10-06 7:20 UTC (permalink / raw)
To: linux-btrfs
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
^ permalink raw reply [flat|nested] 2+ messages in thread