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 38C77138992 for ; Mon, 27 Oct 2014 17:17:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 72289E09EB; Mon, 27 Oct 2014 17:17:19 +0000 (UTC) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 306B2E09C8 for ; Mon, 27 Oct 2014 17:17:17 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id q5so7107128wiv.11 for ; Mon, 27 Oct 2014 10:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=P4YLaYjjkwK8VFNVTw7+X5vfxjTzAuoAdg91PYF6Cgc=; b=mq85xUcDSxs+YN7CoVTgD9II7txwQTduuukLKI9yJf7Xpy5xOyF08SWHWmcdHuv2ku 31e/iIJi5tyDOkIFXeSgpfivvvNrB0m4pVbYIcXCSJ4Hb2KwHIzOgsH/OFxGLxA5T+KI X3N95Ga4RnUrZFy0wNfexaiE07L4jNsQa/u1AZDEhpn7b2g4PRdNWxWb4BreLWyWqRM4 QUh86Tatlv8SLfH6Jf7aev1TRUJP8+qBJWmLEe7fJjRYVgRXbBMbNfnI+Ral7RAEUPNG TNyfmjFbWMt1wE0nfojQ6B/yC9mVHP2P96Xdq+ytNy9KesGT17CsGvo2UYsjWBldpiy1 +SKg== X-Received: by 10.180.95.74 with SMTP id di10mr4406942wib.54.1414430236849; Mon, 27 Oct 2014 10:17:16 -0700 (PDT) Received: from [192.168.178.21] (p3E9E7622.dip0.t-ipconnect.de. [62.158.118.34]) by mx.google.com with ESMTPSA id eu8sm7636292wic.1.2014.10.27.10.17.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Oct 2014 10:17:16 -0700 (PDT) Message-ID: <544E7E1B.2000503@googlemail.com> Date: Mon, 27 Oct 2014 18:17:15 +0100 From: Volker Armin Hemmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 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 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Safeguarding strategies against SSD data loss References: <201410270924.40381.michaelkintzios@gmail.com> <544E2875.5000309@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 7b207d28-ce49-4e9b-b653-e7957f4b989e X-Archives-Hash: cccde81fe6b5544101ff04d1cd2e5eda Am 27.10.2014 um 14:13 schrieb Rich Freeman: > 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 > > . > what happens if that send stream becomes corrupted?