From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id E2DE1138978 for ; Mon, 27 Oct 2014 15:23:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1BB9DE09E8; Mon, 27 Oct 2014 15:23:26 +0000 (UTC) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C6900E09E0 for ; Mon, 27 Oct 2014 15:23:24 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id b13so5945420wgh.10 for ; Mon, 27 Oct 2014 08:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:reply-to:to:subject:date:user-agent:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=vRkzdK2M+J5Y6DbnHnogBXDYbF8BXZnyNXTWr+aI1fo=; b=TmLRd218Lv3vwlCcvUCvIEGzWesPG+ng5A98M0FcXlKs9yn10p61ALJW+GFM2kclwe eBkK4qI1KSV+Jt1uAg5juaJ2XVwoUD7hXyay1QIzY3tMb7A5tma/P/mN5t/PDtaGpx/D akAzZb2OkpsueBvkYZi2IkQ2X7GoND7JVMTxcanKSTuno1Ilf1c+FICit4100kEuFZ/U ZZ2fUOczFSAjJJ4L4wD4fQrHqWknDuE7qlXysQGowv7zMbC9YkGopqLOJtzvwaFo72hG dVmPETu6JjUyMwglEakNAn9aPvPA7VNahOPgY224UisxSm/Umat09V9EbXXw2gC0z13z /h4g== X-Received: by 10.180.87.196 with SMTP id ba4mr11778390wib.40.1414423403458; Mon, 27 Oct 2014 08:23:23 -0700 (PDT) Received: from dell_xps.localnet (230.3.169.217.in-addr.arpa. [217.169.3.230]) by mx.google.com with ESMTPSA id au3sm15952090wjc.15.2014.10.27.08.23.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 08:23:22 -0700 (PDT) From: Mick To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: Safeguarding strategies against SSD data loss Date: Mon, 27 Oct 2014 15:23:20 +0000 User-Agent: KMail/1.13.7 (Linux/3.16.5-gentoo; KDE/4.12.5; x86_64; ; ) References: <201410270924.40381.michaelkintzios@gmail.com> In-Reply-To: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1434213.1cOiNg6g04"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201410271523.22392.michaelkintzios@gmail.com> X-Archives-Salt: ef48543e-e1c6-4ed0-ada1-62c4c1e0cbe9 X-Archives-Hash: d82754dc73d5ef183a211f5418fec86d --nextPart1434213.1cOiNg6g04 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Monday 27 Oct 2014 15:15:22 James wrote: > Rich Freeman gentoo.org> writes: > > > On 27/10/2014 11:24, Mick wrote: > > >>> With a caveat: if an ssd dies, it will die suddenly. Without warnin= g. >=20 > With SSD the most important fact to keep constantly in mind is > writing/erasing by blocks due to uniqueness of the hardware. > Unfortunately, if you dig deeply, many Solid State Storage devices > are organized differently and those hardware differences may impact > your SSD_specific implementation details. SSD raid redundancy is > something most machines (folks) cannot afford, imho and may be a waist > to dis_functional if you employ the same semantics for I/O on the > redundant SSD hardware. >=20 > [1] > http://codecapsule.com/2014/02/12/coding-for-ssds-part-6-a-summary-what-e= ve > ry-programmer-should-know-about-solid-state-drives/ >=20 > > >> In such cases I am prepared to live with the risk of some > > >>=20 > > >> data loss, on machines where raid is not an option. >=20 > Wise with a well thought out (planned) recovery/fresh-install strategy. >=20 > > > Without some form of redundancy that would be your best strategy - > > > decent and frequent backups > >=20 > > But yes, backup and RAID are really your only options for SSD failure > > as far as I can see it. That and limiting the amount of data that > > can't be re-generated. If you just save the world file and all of > > /etc you could probably rebuild a Gentoo install fairly quickly on a > > new drive, and then you're just left with /home and whatever else you > > happen to have installed that sticks stuff in /var that you care > > about. >=20 > Yep. Rich has it exactly right. I'd add /usr/local/* > as by design that is where I put most uniqueness in any linux system > besides the list above. >=20 > In fact for small networks, I just identify the directories that I want > to preserve. At the least you rsysnc those to a differnet system > on the local net, besides a backup, if no raid is underneath. (Triple). > Obviously, you have all systems on UPS power......? >=20 > I'd add any dirs with custom scripts and the kernel files also minimally > replicated to another system. A comprehensive list of critical files > is fine. Workstations and servers have different lists of critial files; > and you can further subdivide the servers by function, to focus > on those critical files and directories. So what is on the SSD that is > important, just replicate it to a spinning HD on the local net. None > of this replaces weekly backups, but give you a tertiary level of > recovery redundancy for the important stuff. Triple redundancy is keenly > important for all critical stuff; ymmv. >=20 > Personally, I find max-ram and spinning HD to be the best bang for the > buck. But, many folks with older portables are usually really happy with > SSD as a replacement (single) drive that is cost effective but needs > a network backup. >=20 > [2] > http://serverfault.com/questions/454775/is-post-sudden-power-loss-filesys= te > m-corruption-on-an-ssd-drives-ext3-partition >=20 >=20 > hth, > James Good comments and links James. Thank you. =2D-=20 Regards, Mick --nextPart1434213.1cOiNg6g04 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJUTmNqAAoJELAdA+zwE4YeCtkIAM22adx2QX02pkBfjTlENrD0 L8rYbjDz+h0bCIYlrww81scsYG3vZ2QfU8+xLj492df5UbFO2HIA/++UDnZcpnQW BXHnN0BFjzVJyKo2K6InGsWNDv+FDnfV+pi4QdKoAoSsb/sDJ7153ZMX7FoCcCna 5AG1x/hD7AJlcWpbPd+i0qde15FAcaz9nUiTSM0K95yLHuexBB3we+qY44rj46hk nszCUZfxePW8osVR1q0Yl2deT0fc4acNfuR3g1bMJgMfAr7Edr4Sn+kWfMXZHaSA Ld0V4FJG70HP21h5NJeC4dj7M9cgV12KD8FcJ+jlmP8Agzaoxi4dZpOBgOs6XJc= =2qAI -----END PGP SIGNATURE----- --nextPart1434213.1cOiNg6g04--