From owner-freebsd-fs@FreeBSD.ORG Wed Apr 23 16:20:59 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F7DFBB9 for ; Wed, 23 Apr 2014 16:20:59 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C6B4019EB for ; Wed, 23 Apr 2014 16:20:58 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id c11so985751lbj.17 for ; Wed, 23 Apr 2014 09:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YmpNVjfcea0Qv0oz46EYdPe8sq1EbAJI1q7xc7yT8YY=; b=YuwgRM2sk0SwCJRcZ4hRsqaApBYliiI4Mzb1/9u23QH8jDjQ52DUeiRfcNuwkSwtZD 2g3lTj/WffvIp3IuWKf27cwRkwwKI5ipHupl/p7bwnQ4NPBiMC08RYGShEmGTmTCqMGH 73vwDjoulHVPVnRCMJ4ExOGnHZB1h3PIFFvZv5FqdXAGzqqPL6svbhCltkJjDoBY2yIn H8W4d1THHPzFjfjKHgFcLnSFy9yp+5I1dRrn+8WGD55rprBaL95jaop9UfdjFhUJm3zn oTnLVzp+7Cg36DjvGJKq/cpTjbINy4Y6lZnHC6/ikwMijEkcoASFbMMyF6qbNRMsJjUR 21xw== MIME-Version: 1.0 X-Received: by 10.112.131.8 with SMTP id oi8mr48216lbb.87.1398270056646; Wed, 23 Apr 2014 09:20:56 -0700 (PDT) Received: by 10.112.129.164 with HTTP; Wed, 23 Apr 2014 09:20:56 -0700 (PDT) In-Reply-To: <5357D7E7.605@denninger.net> References: <20140423064203.GD2830@sludge.elizium.za.net> <20140423080056.GE2830@sludge.elizium.za.net> <20140423091852.GH2830@sludge.elizium.za.net> <20140423100126.GJ2830@sludge.elizium.za.net> <5357937D.4080302@gmail.com> <72E79259-3DB1-48B7-8E5E-19CC2145A464@icloud.com> <888649C4-CC66-48A6-9901-BEA93D1BBFA3@mail.turbofuzz.com> <5357CC7B.2090003@denninger.net> <5357D7E7.605@denninger.net> Date: Wed, 23 Apr 2014 17:20:56 +0100 Message-ID: Subject: Re: ZFS unable to import pool From: Tom Evans To: Karl Denninger Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD FS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 16:20:59 -0000 On Wed, Apr 23, 2014 at 4:10 PM, Karl Denninger wrote: > I have a large home system as well. > > But I do back it up to other spinning pieces of rust, and rotate the backups > out to a bank safe-deposit box. If I make a terrible mistake (or my > hardware and/or software does) I have a means of recovery. There are no > guarantees of course in that I COULD wind up with a bad disk in the safe > deposit box, but if my house burns down I have a shot at recovery with high > odds of success -- an act that would otherwise be impossible. Partitioning > my data off into "essentially archival, read-almost-only" and "active" means > that the former needs to be updated rarely and the former is of small enough > size that I don't go crazy doing it either in money or time. I recently re-jigged my setup to do just this - the root pool and working set are on a pair of SSDs, and the rarely written and seldom read data lives on a special archive pool - 8 disk raidz2. > > And I *HAVE* had things like this happen -- twice in the last 20 years I've > had a disk adapter go insane and scribble on MULTIPLE spindles at once. > There is no RAID strategy that will protect you against this event; you > either have a backup or you're done. I didn't want to know that :) > > ZFS actually makes this easier with send/receive and the ability to import a > pool, send to it and then export it. The backup pool can have compression > turned on where for performance reasons it may not make sense for the online > pool to do so. And you can rotate that out fairly easily too; you can take > a 2-way mirror, add a third disk and let it resilver, then split the third > one off and remove it, giving you a dismounted copy you can then stick in a > box and yet if you need it -- it's there. I should be doing more of this, although it is trickier to do with a large pool. Splitting my datasets in to smaller chunks would help to backup to dismounted pools. Interesting advice, thanks Karl! Cheers Tom