Gentoo Archives: gentoo-user

From: Volker Armin Hemmann <volkerarmin@××××××××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Safeguarding strategies against SSD data loss
Date: Mon, 27 Oct 2014 17:17:24
Message-Id: 544E7E1B.2000503@googlemail.com
In Reply to: Re: [gentoo-user] Safeguarding strategies against SSD data loss by Rich Freeman
1 Am 27.10.2014 um 14:13 schrieb Rich Freeman:
2 > On Mon, Oct 27, 2014 at 7:11 AM, Alan McKinnon <alan.mckinnon@×××××.com> wrote:
3 >> On 27/10/2014 11:24, Mick wrote:
4 >>> I'm starting a new thread so as to not hijack the one about alternative
5 >>> kernels, but continue with something Volker raised.
6 >>>
7 >>> On Sunday 26 Oct 2014 23:25:50 Volker Armin Hemmann wrote:
8 >>>
9 >>>> as others have written already: ssd.
10 >>>>
11 >>>> With a caveat: if an ssd dies, it will die suddenly. Without a warning.
12 >>>> Usually 5 minutes before the start of your weekly or monthly backup run.
13 >>>> And that is first hand experience.
14 >>> I haven't yet started using SSD and have wondered what sort of a system should
15 >>> I set up to guard against such instantaneous catastrophic failures. I am
16 >>> interested to hear what strategies people deploy to avoid data loss with SSDs,
17 >>> especially on laptops that don't have the luxury of raid redundancy.
18 >>>
19 >>> With spinning drives I use tar and rsync at regular intervals. There have
20 >>> been a few rare cases where a drive failed without prior notice - the last one
21 >>> after a reboot. In such cases I am prepared to live with the risk of some
22 >>> data loss, on machines where raid is not an option.
23 >>>
24 >> Without some form of redundancy that would be your best strategy -
25 >> decent and frequent backups
26 >>
27 > It isn't the most mature solution, but btrfs send has a lot of
28 > potential here. One of the main costs of backups is the need to walk
29 > all the data that you intend to backup to find changes. Rsync can do
30 > wonders with minimizing bandwidth, and something like duplicity which
31 > uses librsync can do wonders to minimize the size of serializing that
32 > in files, but both require reading the entire filesystem.
33 >
34 > Btrfs send can serialize a set of changes in the filesystem by reading
35 > only the btree nodes and extents that have changed. It is fairly
36 > close to a git pull in that sense, though git doesn't use balanced
37 > trees. That would greatly reduce the IO cost of frequent backups.
38 > You would just periodically create a new snapshot, do a send between
39 > the last snapshot and the new one, and once you've confirmed
40 > successful completion of that you'd delete the old snapshot.
41 >
42 > Of course, IO seeks aren't nearly as expensive on an SSD as they are
43 > on a hard drive. I haven't really done a lot of rsync on ssds while
44 > using them so I can't really vouch for how much the IO impacts
45 > operations.
46 >
47 > But yes, backup and RAID are really your only options for SSD failure
48 > as far as I can see it. That and limiting the amount of data that
49 > can't be re-generated. If you just save the world file and all of
50 > /etc you could probably rebuild a Gentoo install fairly quickly on a
51 > new drive, and then you're just left with /home and whatever else you
52 > happen to have installed that sticks stuff in /var that you care
53 > about.
54 >
55 > --
56 > Rich
57 >
58 > .
59 >
60
61 what happens if that send stream becomes corrupted?