On Mon, Apr 12, 2010 at 08:01:27PM -0700, Peter Tripp wrote: > So I decided I would attach the disks to 2nd system (with working fans) where > I could backup the data to tape. So here's where I got dumb...I ran 'zpool > export'. Of course, I never actually ended up attaching the disks to another > machine, but ever since that export I've been unable to import the pool at > all. I've ordered a replacement 1TB disk, but it hasn't arrived yet. Since I > got no errors from the scrub I ran while the array was degraded, I'm pretty > confident that the remaining 3 disks have valid data. > > * Should I be able to import a degraded pool?
Did you try with -f? I doubt it will help. > * If not, shouldn't there be a warning when exporting a degraded pool? Interesting point. > * If replace 1TB dead disk with a blank disk, might the import work? Only if the import is failing because the dead disk is nonresponsive in a way that makes the import hang. Otherwise, you'd import the pool first then replace the drive. > * Are there any tools (or commercial services) for ZFS recovery? Dunno about commercial services, zpool and zdb seem to work most of the time. > I read a blog post (which naturally now I can't find) where someone > in similar circumstances was able to import his pool after restoring > /etc/zfs/zpool.cache from a backup before the 'zpool > export'. Naturally this guy was doing it with ZFS-FUSE under Linux, > so it's another step removed, but can someone explain to me the > logic & risks of trying such a thing? Will it work if the > zpool.cache comes from 1day/1week/1month old backup? If you have auto-snapshots of your running BE (/etc) from before the import, that should work fine. Note that you can pass import an argument "-c cachefile" so you don't have to interfere with the current system one. You'd have to do this on the original system, I think. The logic is that the cachefile contains copies of the labels of the missing devices, and can substitute for the devices themselves when importing a degradedd pool (typically at boot). This is useful enough that i'd like to see some of the reserved area between the on-disk labels and the first metaslab on each disk, used to store a copy of the cache file / same data. That way every pool member has the information about other members necessary to import a degraded pool. Even if it had to be extracted first with zdb to be used as a separate zpool.cache as above, it would be helpful for this scenario. -- Dan.
pgpc2zztGllcm.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
