1 |
On Mon, Oct 27, 2014 at 7:11 AM, Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
2 |
> On 27/10/2014 11:24, Mick wrote: |
3 |
>> I'm starting a new thread so as to not hijack the one about alternative |
4 |
>> kernels, but continue with something Volker raised. |
5 |
>> |
6 |
>> On Sunday 26 Oct 2014 23:25:50 Volker Armin Hemmann wrote: |
7 |
>> |
8 |
>>> as others have written already: ssd. |
9 |
>>> |
10 |
>>> With a caveat: if an ssd dies, it will die suddenly. Without a warning. |
11 |
>>> Usually 5 minutes before the start of your weekly or monthly backup run. |
12 |
>>> And that is first hand experience. |
13 |
>> |
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 |
> |
25 |
> Without some form of redundancy that would be your best strategy - |
26 |
> decent and frequent backups |
27 |
> |
28 |
|
29 |
It isn't the most mature solution, but btrfs send has a lot of |
30 |
potential here. One of the main costs of backups is the need to walk |
31 |
all the data that you intend to backup to find changes. Rsync can do |
32 |
wonders with minimizing bandwidth, and something like duplicity which |
33 |
uses librsync can do wonders to minimize the size of serializing that |
34 |
in files, but both require reading the entire filesystem. |
35 |
|
36 |
Btrfs send can serialize a set of changes in the filesystem by reading |
37 |
only the btree nodes and extents that have changed. It is fairly |
38 |
close to a git pull in that sense, though git doesn't use balanced |
39 |
trees. That would greatly reduce the IO cost of frequent backups. |
40 |
You would just periodically create a new snapshot, do a send between |
41 |
the last snapshot and the new one, and once you've confirmed |
42 |
successful completion of that you'd delete the old snapshot. |
43 |
|
44 |
Of course, IO seeks aren't nearly as expensive on an SSD as they are |
45 |
on a hard drive. I haven't really done a lot of rsync on ssds while |
46 |
using them so I can't really vouch for how much the IO impacts |
47 |
operations. |
48 |
|
49 |
But yes, backup and RAID are really your only options for SSD failure |
50 |
as far as I can see it. That and limiting the amount of data that |
51 |
can't be re-generated. If you just save the world file and all of |
52 |
/etc you could probably rebuild a Gentoo install fairly quickly on a |
53 |
new drive, and then you're just left with /home and whatever else you |
54 |
happen to have installed that sticks stuff in /var that you care |
55 |
about. |
56 |
|
57 |
-- |
58 |
Rich |