On Mon, Dec 07, 2015 at 01:48:47PM +0000, Duncan wrote: > Alistair Grant posted on Mon, 07 Dec 2015 21:02:56 +1100 as excerpted: > > > I think I'll try the btrfs restore as a learning exercise, and to check > > the contents of my backup (I don't trust my memory, so something could > > have changed since the last backup). > > Trying btrfs restore is an excellent idea. It'll make things far easier > if you have to use it for real some day. > > Note that while I see your kernel is reasonably current (4.2 series), I > don't know what btrfs-progs ubuntu ships. There have been some marked > improvements to restore somewhat recently, checking the wiki btrfs-progs > release-changelog list says 4.0 brought optional metadata restore, 4.0.1 > added --symlinks, and 4.2.3 fixed a symlink path check off-by-one error. > (And don't use 4.1.1 as its mkfs.btrfs is broken and produces invalid > filesystems.) So you'll want at least progs 4.0 to get the optional > metadata restoration, and 4.2.3 to get full symlinks restoration support. >
Ubuntu 15.10 comes with btrfs-progs v4.0. It looks like it is easy enough to compile and install the latest version from git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git so I'll do that. Should I stick to 4.2.3 or use the latest 4.3.1? > > Does btrfs restore require the path to be on a btrfs filesystem? I've > > got an existing ext4 drive with enough free space to do the restore, so > > would prefer to use it than have to buy another drive. > > Restoring to ext4 should be fine. > > Btrfs restore writes files as would an ordinary application, the reason > metadata restoration is optional (otherwise it uses normal file change > and mod times, with files written as the running user, root, using umask- > based file perms, all exactly the same as if it were a normal file > writing application), so it will restore to any normal filesystem. The > filesystem it's restoring /from/ of course must be btrfs... unmounted > since it's designed to be used when mounting is broken, but it writes > files normally, so can write them to any filesystem. > > FWIW, I restored to my reiserfs based media partition (still on spinning > rust, my btrfs are all on ssd) here, since that's where I had the room to > work with. > Thanks for the confirmation. > > My plan is: > > > > * btrfs restore /dev/sdX /path/to/ext4/restorepoint > > ** Where /dev/sdX is one of the two drives that were part of the raid1 > > fileystem > > * hashdeep audit the restored drive and backup > > * delete the existing corrupted btrfs filesystem and recreate > > * rsync the merge filesystem (from backup and restore) > > on to the new filesystem > > > > Any comments or suggestions are welcome. > > > Looks very reasonable, here. There's a restore page on the wiki with > more information than the btrfs-restore manpage, describing how to use it > with btrfs-find-root if necessary, etc. > > https://btrfs.wiki.kernel.org/index.php/Restore > I'd seen this, but it isn't explicit about the target filesystem support. I should try and update the page a bit. > Some details on the page are a bit dated; it doesn't cover the dryrun, > list-roots, metadata and symlink options, for instance, and these can be > very helpful, but the general idea remains the same. > > The general idea is to use btrfs-find-root to get a listing of available > root generations (if restore can't find a working root from the > superblocks or you want to try restoring an earlier root), then feed the > corresponding bytenr to restore's -t option. > > Note that generation and transid refer to the same thing, a normally > increasing number, so higher generations are newer. The wiki page makes > this much clearer than it used to, but the old wording anyway was > confusing to me until I figured that out. > > Where the wiki page talks about root object-ids, those are the various > subtrees, low numbers are the base trees, 256+ are subvolumes/snapshots. > Note that restore's list-roots option lists these for the given bytenr as > well. > > So you try restore with list-roots (-l) to see what it gives you, try > btrfs-find-root if not satisfied, to find older generations and get their > bytenrs to plug into restore with -t, and then confirm specific > generation bytenrs with list-roots again. > > Once you have a good generation/bytenr candidate, try a dry-run (-D) to > see if you get a list of files it's trying to restore that looks > reasonable. > > If the dry-run goes well, you can try the full restore, not forgetting > the metadata and symlinks options (-m, -S, respectively), if desired. > > From there you can continue with your plan as above. > > One more bonus hint. Since you'll be doing a new mkfs.btrfs, it's a good > time to review active features and decide which ones you might wish to > activate (or not, if you're concerned about old-kernel compatibility). > Additionally, before repopulating your new filesystem, you may want to > review mount options, particularly autodefrag if appropriate, and > compression if desired, so they take effect from the very first file > created on the new filesystem. =:^) > > FWIW in the past I usually did an immediate post-mkfs.btrfs mount and > balance with -dusage=0 -musage=0 to get rid of the single-mode chunk > artifacts from the mkfs.btrfs as well, but with a new enough mkfs.btrfs > you may be able to avoid that now, as -progs 4.2 was supposed to > eliminate those single-mode mkfs.btrfs artifacts on multi-device > filesystems. I've just not done any fresh mkfs.btrfs since then so > haven't had a chance to play with it and see it personally, just yet. > > -- > 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 Thanks! Alistair -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
