On 06/ 3/16 04:31 PM, Jordan Hubbard wrote: > >> On Jun 3, 2016, at 1:47 PM, Richard Elling >> <richard.ell...@richardelling.com >> <mailto:richard.ell...@richardelling.com>> wrote: >> >> I agree with Jordan, mostly. However, there a way to know for sure… >> each label has a set of uberblocks. Use “zdb -lu” to see this information. >> If you can find a matching set of uberblocks for the right pool on >> enough drives, >> then it is possible, though not guaranteed, that you can get enough of >> a pool >> to recover. OTOH, if the set does not include enough common >> uberblocks, then >> you know the end has come. > > Thanks for the correction and follow-up, Richard. Indeed, there might > still be a faint shred of hope (though based on the pool topology he > pasted, at least, very little I’d say, still - hope is hope!). > > This also does kind of suggest that it might be in all of our mutual > (ZFS-based technology vendor) interests to collaborate on a “ZFS data > recovery FAQ”, just to pool our institutional knowledge on how to deal > with the worst-case scenarios like this (assuming any kind of mitigation > is possible at all) and perhaps improve the lives of all ZFS users in > distress just a bit. Checking The Google does suggest a paucity of such > information. This is the most Oracle appears to say, for example: > http://docs.oracle.com/cd/E19253-01/819-5461/6n7ht6r0o/index.html along > with this recent blog entry: > https://blogs.oracle.com/zfs/entry/zfs_data_and_pool_recovery > > Other snippets come from the FreeBSD and FreeNAS forums, since these > appear to be “popular” mainstream deployments right now (at least in > terms of # of google hits), but the advice is generally no better than > “import, then try to import harder!”. > > If no one else volunteers a location, I’d be happy to host the > information at https://wiki.freenas.org - account creation and editing > is open to the public. > > - Jordan >
It all really depends how far down the rabbit hole you want to go. For instance, if you used a block device from an existing pool to create a new pool but didn't write any data to it, the header will be trashed by the new pool, but there are a bunch of backup uberblocks from the old pool that likely won't have been overwritten. (as well as your precious data) By grubbing around on the disk with od/dd you can find those uberblocks (They have a structure defined in the ZFS on disk specification) and start nuking them with dd, which will force ZFS to "dig a little deeper" and possibly come up with an uberblock from the old pool. You might end up with something that is somewhat damaged, especially with data that was at the front of the disk, but chances are if you didn't write gigabytes of data to the new pool that you could conceivably recover the old pool. However, is that really realistic that we're going to write that sort of thing up and someone will be able to follow it as sort of a recipe without really understanding what they are doing? If someone is that clever they've probably already figured out how to do all of this. ------------------------------------------- openzfs-developer Archives: https://www.listbox.com/member/archive/274414/=now RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce53afa Modify Your Subscription: https://www.listbox.com/member/?member_id=28015062&id_secret=28015062-f966d51c Powered by Listbox: http://www.listbox.com
