From owner-freebsd-fs@FreeBSD.ORG Wed Apr 23 16:20:46 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 1D69DB48 for ; Wed, 23 Apr 2014 16:20:46 +0000 (UTC) Received: from st11p02mm-asmtp002.mac.com (st11p02mm-asmtpout002.mac.com [17.172.220.237]) by mx1.freebsd.org (Postfix) with ESMTP id D994219E4 for ; Wed, 23 Apr 2014 16:20:45 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.10.73] (flipbeam.com [76.74.153.36]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N4H0000XS2I1X00@st11p02mm-asmtp002.mac.com> for freebsd-fs@freebsd.org; Wed, 23 Apr 2014 16:20:44 +0000 (GMT) Subject: Re: ZFS unable to import pool From: Gennadiy Gulchin X-Mailer: iPhone Mail (11D201) In-reply-to: <5357D7E7.605@denninger.net> Date: Wed, 23 Apr 2014 09:20:42 -0700 Message-id: <6305B1EB-F091-47FB-ADEA-6C2EF72C8FBD@icloud.com> 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> To: Karl Denninger X-MANTSH: 1TEIXWV4bG1oaGkdHB0lGUkdDRl5PWBoaHxEKTEMXGx0EGx0YBBIZBBsTEBseGh8 aEQpYTRdLEQptfhcaEQpMWRcbGhsbEQpZSRcRClleF2hueREKQ04XSxsYGmJCHx1SHXVnGXhzB xlkGxwYGkNoEQpYXBcZBBoEHQdNSx0SSEkcTAUbHQQbHRgEEhkEGxMQGx4aHxsRCl5ZF2FAc1A ZEQpMRhdsa2sRCkNaFx0cBB0eBBsfGQQZHBEKRFgXGBEKREkXGBEKQkUXZkV5cEAYTAVEchsRC kJOF2tFGlJQHkNcWVxoEQpCTBdmSH1ZYl1Se2JZHxEKQmwXbBkBQWwbUmZ/HmcRCkJAF2Vua2V /emdQZx1dEQpwaBdiRQVgGkNlYBMbfBEKcGgXZHlyZ01DQXMbcFkRCnBoF2NoGEdEXHpCW1hmE QpwaBdgTxNoT2MaSR9iXxEKcGgXZlwdXRtuQH1aQ3ARCnBsF2NZc0Rca14bHV5tEQ== X-CLX-Spam: false X-CLX-Score: 1011 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96,1.0.14,0.0.0000 definitions=2014-04-23_04:2014-04-23,2014-04-23,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404230247 Cc: "freebsd-fs@freebsd.org" 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:46 -0000 Thanks for your help guys! The only think that makes my hope still survive is the disk I have added is the sAme physicscal disk as in raidz1 pool. Or having Just one disk outside of raidz1 and making this disk unavailable causes the whole array to tank? --Gena > On Apr 23, 2014, at 8:10 AM, Karl Denninger wrote: > >> On 4/23/2014 10:03 AM, Tom Evans wrote: >>> On Wed, Apr 23, 2014 at 3:21 PM, Karl Denninger wrote: >>> /*Filesystem based "redundancy" is not a backup strategy!*/ >> It's my (home) backup strategy :( >> >> Very few cost efficient ways to backup 15TB+ of data other than >> redundant spinning rust. > 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. > > 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. > > 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. > > -- > -- Karl > karl@denninger.net > >