Gentoo Archives: gentoo-user

From: Mick <michaelkintzios@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: Safeguarding strategies against SSD data loss
Date: Mon, 27 Oct 2014 15:23:31
Message-Id: 201410271523.22392.michaelkintzios@gmail.com
In Reply to: [gentoo-user] Re: Safeguarding strategies against SSD data loss by James
1 On Monday 27 Oct 2014 15:15:22 James wrote:
2 > Rich Freeman <rich0 <at> gentoo.org> writes:
3 > > > On 27/10/2014 11:24, Mick wrote:
4 > > >>> With a caveat: if an ssd dies, it will die suddenly. Without warning.
5 >
6 > With SSD the most important fact to keep constantly in mind is
7 > writing/erasing by blocks due to uniqueness of the hardware.
8 > Unfortunately, if you dig deeply, many Solid State Storage devices
9 > are organized differently and those hardware differences may impact
10 > your SSD_specific implementation details. SSD raid redundancy is
11 > something most machines (folks) cannot afford, imho and may be a waist
12 > to dis_functional if you employ the same semantics for I/O on the
13 > redundant SSD hardware.
14 >
15 > [1]
16 > http://codecapsule.com/2014/02/12/coding-for-ssds-part-6-a-summary-what-eve
17 > ry-programmer-should-know-about-solid-state-drives/
18 >
19 > > >> In such cases I am prepared to live with the risk of some
20 > > >>
21 > > >> data loss, on machines where raid is not an option.
22 >
23 > Wise with a well thought out (planned) recovery/fresh-install strategy.
24 >
25 > > > Without some form of redundancy that would be your best strategy -
26 > > > decent and frequent backups
27 > >
28 > > But yes, backup and RAID are really your only options for SSD failure
29 > > as far as I can see it. That and limiting the amount of data that
30 > > can't be re-generated. If you just save the world file and all of
31 > > /etc you could probably rebuild a Gentoo install fairly quickly on a
32 > > new drive, and then you're just left with /home and whatever else you
33 > > happen to have installed that sticks stuff in /var that you care
34 > > about.
35 >
36 > Yep. Rich has it exactly right. I'd add /usr/local/*
37 > as by design that is where I put most uniqueness in any linux system
38 > besides the list above.
39 >
40 > In fact for small networks, I just identify the directories that I want
41 > to preserve. At the least you rsysnc those to a differnet system
42 > on the local net, besides a backup, if no raid is underneath. (Triple).
43 > Obviously, you have all systems on UPS power......?
44 >
45 > I'd add any dirs with custom scripts and the kernel files also minimally
46 > replicated to another system. A comprehensive list of critical files
47 > is fine. Workstations and servers have different lists of critial files;
48 > and you can further subdivide the servers by function, to focus
49 > on those critical files and directories. So what is on the SSD that is
50 > important, just replicate it to a spinning HD on the local net. None
51 > of this replaces weekly backups, but give you a tertiary level of
52 > recovery redundancy for the important stuff. Triple redundancy is keenly
53 > important for all critical stuff; ymmv.
54 >
55 > Personally, I find max-ram and spinning HD to be the best bang for the
56 > buck. But, many folks with older portables are usually really happy with
57 > SSD as a replacement (single) drive that is cost effective but needs
58 > a network backup.
59 >
60 > [2]
61 > http://serverfault.com/questions/454775/is-post-sudden-power-loss-filesyste
62 > m-corruption-on-an-ssd-drives-ext3-partition
63 >
64 >
65 > hth,
66 > James
67
68 Good comments and links James. Thank you.
69
70 --
71 Regards,
72 Mick

Attachments

File name MIME type
signature.asc application/pgp-signature