Sonic posted on Mon, 03 Aug 2015 22:20:38 -0400 as excerpted: > I'm thinking this is a lost cause. Also thinking I need to provide for > some redundancy in the future :-) > > Any other suggestions before I give up the ghost on this?
I don't remember you saying anything about trying btrfs restore. I'm not sure it can do anything for this case, and it definitely requires enough additional space on some other filesystem to store the data it restores, but if you had stuff on there you'd really like to get back, it's worth a shot, and if you're going to be backing up in the future, you'll need the additional devices for the backup in any case, so might as well get 'em now, mkfs them to whatever (doesn't have to be btrfs since all you're doing is using it as a place to store the files, it's the one you're restoring /from/ that's btrfs), mount 'em, and try restoring to them. Worst-case, it doesn't work and you have your set of backup devices already prepped and ready to go. Best-case, it recovers pretty much everything. But I am guessing restore won't be able to do anything on it's own, you'll need to try btrfs-find-root, and feed the bytenr from roots it finds into restore until you get something useful. Take a look at the link and brief instructions I posted in my first reply. Of course, if btrfs-find-root doesn't show you any roots (these are the filesystem master roots), or if fed those roots using -t <bytenr>, btrfs restore --list-roots (these are the various subtree roots) doesn't give you anything worthwhile, then it /would/ appear you're looking at a lost- cause... unless anyone else has a bright idea at this point. -- 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
