| 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 |
> http://www.phoronix.com/scan.php?page=article&item=linux_314_ssdfs&num=1 |
| 60 |
> |
| 61 |
|
| 62 |
neither. Just use ext4. |
| 63 |
|
| 64 |
You don't want to combine the sensitive nature of a ssd with the |
| 65 |
youthful playfulness of a young filesystem. |
| 66 |
|
| 67 |
Also, I am a little bit concerned about that 'freshly formatted' at the |
| 68 |
start of the article. |
Archives