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 48797138977 for ; Mon, 27 Oct 2014 15:15:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 92892E09A9; Mon, 27 Oct 2014 15:15:48 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 75D93E0874 for ; Mon, 27 Oct 2014 15:15:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 2908534041D for ; Mon, 27 Oct 2014 15:15:46 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5.5 tests=[AWL=0.596, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.56, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sklz3Q2pZNnA for ; Mon, 27 Oct 2014 15:15:38 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 4444334031E for ; Mon, 27 Oct 2014 15:15:37 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Xim15-00013u-M1 for gentoo-user@gentoo.org; Mon, 27 Oct 2014 16:15:32 +0100 Received: from rrcs-71-40-157-251.se.biz.rr.com ([71.40.157.251]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Oct 2014 16:15:31 +0100 Received: from wireless by rrcs-71-40-157-251.se.biz.rr.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Oct 2014 16:15:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: James Subject: [gentoo-user] Re: Safeguarding strategies against SSD data loss Date: Mon, 27 Oct 2014 15:15:22 +0000 (UTC) Message-ID: References: <201410270924.40381.michaelkintzios@gmail.com> <544E2875.5000309@gmail.com> 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: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 71.40.157.251 (Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1) X-Archives-Salt: 2c86a0aa-a8c0-4f92-8128-5edc1f456505 X-Archives-Hash: 4bd44b809bc489343f62014aba68a693 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 warning. 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. [1] http://codecapsule.com/2014/02/12/coding-for-ssds-part-6-a-summary-what-every-programmer-should-know-about-solid-state-drives/ > >> In such cases I am prepared to live with the risk of some > >> data loss, on machines where raid is not an option. Wise with a well thought out (planned) recovery/fresh-install strategy. > > Without some form of redundancy that would be your best strategy - > > decent and frequent backups > 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. 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. 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......? 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. 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. [2] http://serverfault.com/questions/454775/is-post-sudden-power-loss-filesystem-corruption-on-an-ssd-drives-ext3-partition hth, James