Thank you for that info Ducan! I did the restore on the whole drive and it errored out on me. I'll try the restore on some key files (audo mostly) and see what i can get off of it.
Is there a fix for the bad tree block error, which seems to be the root (pun intended) of all this? On Sat, Jun 11, 2016 at 8:18 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Bearcat Şándor posted on Sat, 11 Jun 2016 13:54:44 -0600 as excerpted: > >> I'm about to try a btrfs restore to see what it can do for me. Any >> pointers or help here? I don't want to fsck things up further. > > FWIW, btrfs restore doesn't write anything at all to the filesystem it's > restoring from -- it's read-only in that regard -- so you really don't > have to worry about it screwing up a filesystem further. > > But by the same token, btrfs restore may not do what you think it does. > It doesn't try to fix the filesystem. Rather, it's a way to try to > salvage anything you can off a filesystem that won't mount, or, as it > would be used here, that will mount but where files aren't showing up > properly so you can't just copy them elsewhere using normal means. It > writes the files it can salvage to some other filesystem, which of course > means that whatever filesystem you're writing the files to must have > enough room for the files to be written. > > Also note the various restore options. In particular, the restore > metadata option must be used if you want to restore the same ownership, > permissions and timestamp information. Otherwise, restore simply writes > the files as the user you're running it as (root), using the current > umask. Similarly, if you want to restore symlinks and extended > attributes, there's options for that, otherwise they aren't restored. > > And you won't necessarily be wanting to restore snapshots, as you should > have backups if needed for the history, and are likely most worried about > the current version of the files, so snapshots aren't restored unless you > use the appropriate option. > > Given that the filesystem is still mounted and most files are apparently > still readable normally, you may want to copy off what you can that way, > and only restore specific files using btrfs restore. Or you may not have > room on the destination filesystem to restore everything, and will need > to pick only the most important stuff to restore. That's where the > pattern-match option comes in. > > What I did here when I used restore (I had backups of course but they > weren't current) was use the metadata and symlinks restore options, and > simply restored everything. > > Note that if a particular directory has a lot of files, restore will > begin to think that it's looping to much and that it's stuck. It'll > prompt you to continue, and may prompt a *LOT*. Here I have multiple > independent small filesystems, so it wasn't a big deal, but you may need > to experiment with automating the "yes" if your filesystem is huge > (piping the output of the yes command to stdin, for instance, or similar > sysadmin prompt automation tricks). A number of folks have mentioned > that and requested a way to say "yes, really all, don't ask again", an > option that btrfs restore unfortunately doesn't have 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 > > -- > 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 -- Bearcat M. Şándor Feline Soul Systems LLC Voice: 872.CAT.SOUL (872.228.7685) -- 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
