From owner-freebsd-stable@freebsd.org Tue Apr 30 13:53:01 2019 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20BA31591E0A for ; Tue, 30 Apr 2019 13:53:01 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.21.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp-sofia.digsys.bg", Issuer "Digital Systems Operational CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D0B372171 for ; Tue, 30 Apr 2019 13:52:53 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from [193.68.6.100] ([193.68.6.100]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.15.2/8.15.2) with ESMTPSA id x3UDe6rp061034 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Apr 2019 16:40:07 +0300 (EEST) (envelope-from daniel@digsys.bg) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: ZFS... From: Daniel Kalchev In-Reply-To: Date: Tue, 30 Apr 2019 16:40:06 +0300 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <31095B59-630A-44E3-B68F-530C6A0AEC35@digsys.bg> References: <30506b3d-64fb-b327-94ae-d9da522f3a48@sorbs.net> <56833732-2945-4BD3-95A6-7AF55AB87674@sorbs.net> <3d0f6436-f3d7-6fee-ed81-a24d44223f2f@netfence.it> <17B373DA-4AFC-4D25-B776-0D0DED98B320@sorbs.net> <70fac2fe3f23f85dd442d93ffea368e1@ultra-secure.de> <70C87D93-D1F9-458E-9723-19F9777E6F12@sorbs.net> <5ED8BADE-7B2C-4B73-93BC-70739911C5E3@sorbs.net> To: Karl Denninger X-Mailer: Apple Mail (2.3445.104.8) X-Rspamd-Queue-Id: 9D0B372171 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of daniel@digsys.bg designates 193.68.21.123 as permitted sender) smtp.mailfrom=daniel@digsys.bg X-Spamd-Result: default: False [-1.28 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.90)[-0.904,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:193.68.21.123]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[digsys.bg]; NEURAL_HAM_LONG(-0.88)[-0.876,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[relay.digsys.bg,xt.digsys.bg]; RCPT_COUNT_TWO(0.00)[2]; SUBJ_ALL_CAPS(0.45)[6]; IP_SCORE(-0.09)[asn: 3245(-0.48), country: BG(0.04)]; NEURAL_HAM_SHORT(-0.06)[-0.057,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3245, ipnet:193.68.0.0/19, country:BG]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 13:53:01 -0000 > On 30 Apr 2019, at 16:11, Karl Denninger wrote: >=20 >=20 > My experience is that ZFS is materially more-resilient but there is no > such thing as "can never be corrupted by any set of events." Backup > strategies for moderately large (e.g. many Terabytes) to very large > (e.g. Petabytes and beyond) get quite complex but they're also very > necessary. >=20 I can only second that statement. Being paranoid with your data (keep = many copies, have many backups) is never enough. A colleague just complained the other day, that they lost a zpool and = that ZFS didn=E2=80=99t save their data=E2=80=A6. by not making a = redundant pool and the hard drive trashing heads. And no backups. The = unreadable part of the drive happened in metadata and the pool can not = be imported. I keep an HDD around, that since it was brand new, runs perfectly under = any OS. Rock solid, that is=E2=80=A6 and only ZFS complains that it = reads things back it didn=E2=80=99t write. Before that, I would think = UFS was ok=E2=80=A6 since then, I don=E2=80=99t build a single = installation, that does not have at least a mirrored ZFS pool. And = =E2=80=9Carchive servers=E2=80=9D (stands for backup) have become the = central focus of my work. These are never enough.. Daniel