... Didn't read all of your original post originally, because I haven't been into those internals. Now that I have, I see it seems to be using 6 devices, so you might have to use 1 hard drive 6*size of partition (others can say if this will work), or 6 other hard drives to make the backups. Although, I'm not sure what raid configuration there may be, which could reduce the number of copies you had to make.
On Tue, Dec 15, 2015 at 10:59 PM, Michael Darling <darli...@gmail.com> wrote: > > Or, even better yet, just unplug the drive completely and let someone more > knowledgeable with btrfs say my dd suggestion works, as long as you don't > mount either when they're both plugged in. I know the urge to just work on > something, but bad recovery attempts can make recoverable data lost forever. > > On Tue, Dec 15, 2015 at 10:56 PM, Michael Darling <darli...@gmail.com> wrote: >> >> First thing first, if the file is as important as it sounds like. Since >> there's no physical problem with the hard drive, go get (or if you have one >> laying around, use) another hard drive that is at least as big as the >> partition that file was on. Then completely unmount the original partition. >> Do a dd copy of the entire partition it was on. >> >> Then DO NOT mount either partition. You do NOT want to mount a btrfs >> partition when there's a dd clone hooked up, because the UUID's are the same >> on both. >> >> Turn off the machine, pull the new backup copy, then go back to work on >> recovery attempts. If recovery goes wrong, restore the fresh backup copy by >> another dd. Make sure again to NOT mount either while more than one copy is >> plugged in. >> -- 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
