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 3BD5D13895F for ; Mon, 27 Oct 2014 13:13:11 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D8CE6E0993; Mon, 27 Oct 2014 13:13:02 +0000 (UTC) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C09C9E0985 for ; Mon, 27 Oct 2014 13:13:01 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id dc16so3743467qab.18 for ; Mon, 27 Oct 2014 06:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=471IqimugzUONb+shdkEFiVJxi0vDe+wdq19fk9WfKc=; b=TUP7rH0/icxLCTwOZzVwsAAie6xk1evePZG+5xsJn37uwC6l/GvglzJzfx5SHkR5N7 8465RRdrpjjAZHqdt/elg6KDcPB3PtwvaGxoONcUjayxd2kqWI2BVxsisek+qfQA+5w3 RtFt0mxGqJPOBTBcKfZsv0k+1KazqnpXxT/HYivTq/v6Ht6pIKUK5aG7Kv6WIJ0jtVYV ogyzmzhrpUkFF5+aZSRY2viYAK8qSBeyJ9fshmSzmGsEwFoXJG1SCWKLXW4kyfuyzMvz BFf5/t3fE8X1CdPhCpY2LWL2r486XpoXdbgBzV184ekJz542fjPR0N0yK6seLk8Sn9Fd Y4bQ== 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 X-Received: by 10.224.4.68 with SMTP id 4mr5617554qaq.12.1414415580843; Mon, 27 Oct 2014 06:13:00 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.140.102.134 with HTTP; Mon, 27 Oct 2014 06:13:00 -0700 (PDT) In-Reply-To: <544E2875.5000309@gmail.com> References: <201410270924.40381.michaelkintzios@gmail.com> <544E2875.5000309@gmail.com> Date: Mon, 27 Oct 2014 09:13:00 -0400 X-Google-Sender-Auth: fRZLzLmU_QOS8tgGTMggXzK4r_M Message-ID: Subject: Re: [gentoo-user] Safeguarding strategies against SSD data loss From: Rich Freeman To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: cf7ab73d-28c6-460c-9057-c93191b9ea28 X-Archives-Hash: 828c241c42395d5cf5f3fc4beb4a88e7 On Mon, Oct 27, 2014 at 7:11 AM, Alan McKinnon wrote: > On 27/10/2014 11:24, Mick wrote: >> I'm starting a new thread so as to not hijack the one about alternative >> kernels, but continue with something Volker raised. >> >> On Sunday 26 Oct 2014 23:25:50 Volker Armin Hemmann wrote: >> >>> as others have written already: ssd. >>> >>> With a caveat: if an ssd dies, it will die suddenly. Without a warning. >>> Usually 5 minutes before the start of your weekly or monthly backup run. >>> And that is first hand experience. >> >> I haven't yet started using SSD and have wondered what sort of a system should >> I set up to guard against such instantaneous catastrophic failures. I am >> interested to hear what strategies people deploy to avoid data loss with SSDs, >> especially on laptops that don't have the luxury of raid redundancy. >> >> With spinning drives I use tar and rsync at regular intervals. There have >> been a few rare cases where a drive failed without prior notice - the last one >> after a reboot. In such cases I am prepared to live with the risk of some >> data loss, on machines where raid is not an option. >> > > Without some form of redundancy that would be your best strategy - > decent and frequent backups > It isn't the most mature solution, but btrfs send has a lot of potential here. One of the main costs of backups is the need to walk all the data that you intend to backup to find changes. Rsync can do wonders with minimizing bandwidth, and something like duplicity which uses librsync can do wonders to minimize the size of serializing that in files, but both require reading the entire filesystem. Btrfs send can serialize a set of changes in the filesystem by reading only the btree nodes and extents that have changed. It is fairly close to a git pull in that sense, though git doesn't use balanced trees. That would greatly reduce the IO cost of frequent backups. You would just periodically create a new snapshot, do a send between the last snapshot and the new one, and once you've confirmed successful completion of that you'd delete the old snapshot. Of course, IO seeks aren't nearly as expensive on an SSD as they are on a hard drive. I haven't really done a lot of rsync on ssds while using them so I can't really vouch for how much the IO impacts operations. 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. -- Rich