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:20:53
In Reply to: Re: [gentoo-user] Safeguarding strategies against SSD data loss by Mick
1 Am 27.10.2014 um 16:22 schrieb Mick:
2 > On Monday 27 Oct 2014 13:13:00 Rich Freeman wrote:
3 >> On Mon, Oct 27, 2014 at 7:11 AM, Alan McKinnon <alan.mckinnon@×××××.com>
4 > wrote:
5 >>> On 27/10/2014 11:24, Mick wrote:
6 >>>> I'm starting a new thread so as to not hijack the one about alternative
7 >>>> kernels, but continue with something Volker raised.
8 >>>>
9 >>>> On Sunday 26 Oct 2014 23:25:50 Volker Armin Hemmann wrote:
10 >>>>> as others have written already: ssd.
11 >>>>>
12 >>>>> With a caveat: if an ssd dies, it will die suddenly. Without a warning.
13 >>>>> Usually 5 minutes before the start of your weekly or monthly backup
14 >>>>> run. And that is first hand experience.
15 >>>> I haven't yet started using SSD and have wondered what sort of a system
16 >>>> should I set up to guard against such instantaneous catastrophic
17 >>>> failures. I am interested to hear what strategies people deploy to
18 >>>> avoid data loss with SSDs, especially on laptops that don't have the
19 >>>> luxury of raid redundancy.
20 >>>>
21 >>>> With spinning drives I use tar and rsync at regular intervals. There
22 >>>> have been a few rare cases where a drive failed without prior notice -
23 >>>> the last one after a reboot. In such cases I am prepared to live with
24 >>>> the risk of some data loss, on machines where raid is not an option.
25 >>> Without some form of redundancy that would be your best strategy -
26 >>> decent and frequent backups
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 > Thanks Rich, I have been reading your posts about btrfs with interest, but
56 > have not yet used it on my systems. Is btrfs agreeable with SSDs, or should I
57 > be using f2fs:
58 >
59 >
60 >
62 neither. Just use ext4.
64 You don't want to combine the sensitive nature of a ssd with the
65 youthful playfulness of a young filesystem.
67 Also, I am a little bit concerned about that 'freshly formatted' at the
68 start of the article.