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? |