Date: Tue, 30 Apr 2019 10:26:27 +0200 From: Kurt Jaeger <pi@freebsd.org> To: Michelle Sullivan <michelle@sorbs.net> Cc: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: ZFS... Message-ID: <20190430082626.GX72200@home.opsec.eu> In-Reply-To: <17B373DA-4AFC-4D25-B776-0D0DED98B320@sorbs.net> References: <30506b3d-64fb-b327-94ae-d9da522f3a48@sorbs.net> <CAOtMX2gf3AZr1-QOX_6yYQoqE-H%2B8MjOWc=eK1tcwt5M3dCzdw@mail.gmail.com> <56833732-2945-4BD3-95A6-7AF55AB87674@sorbs.net> <3d0f6436-f3d7-6fee-ed81-a24d44223f2f@netfence.it> <17B373DA-4AFC-4D25-B776-0D0DED98B320@sorbs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi! > If one triggers such a fault on a production server, how can one > justify transferring from backup multiple terabytes (or even petabytes > now) of data to repair an unmountable/faulted array.... because all > backup solutions I know currently would take days if not weeks to > restore the sort of store ZFS is touted with supporting. Isn't that the problem with all large storage systems ? Even mainframe storage (with very different concepts behind it) can become messed up so much that there's no hope left. -- pi@opsec.eu +49 171 3101372 One year to go !
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190430082626.GX72200>