Re: [gentoo-user] Safeguarding strategies against SSD data loss

[Volker Armin Hemmann <volkerarmin@googlemail.com>]

Am 27.10.2014 um 16:22 schrieb Mick:
> On Monday 27 Oct 2014 13:13:00 Rich Freeman wrote:
>> On Mon, Oct 27, 2014 at 7:11 AM, Alan McKinnon <alan.mckinnon@gmail.com> 
> wrote:
>>> On 27/10/2014 11:24, Mick wrote:
>>>> I'm starting a new thread so as to not hijack the one about alternative
>>>> kernels, but continue with something Volker raised.
>>>>
>>>> On Sunday 26 Oct 2014 23:25:50 Volker Armin Hemmann wrote:
>>>>> as others have written already: ssd.
>>>>>
>>>>> With a caveat: if an ssd dies, it will die suddenly. Without a warning.
>>>>> Usually 5 minutes before the start of your weekly or monthly backup
>>>>> run. And that is first hand experience.
>>>> I haven't yet started using SSD and have wondered what sort of a system
>>>> should I set up to guard against such instantaneous catastrophic
>>>> failures.  I am interested to hear what strategies people deploy to
>>>> avoid data loss with SSDs, especially on laptops that don't have the
>>>> luxury of raid redundancy.
>>>>
>>>> With spinning drives I use tar and rsync at regular intervals.  There
>>>> have been a few rare cases where a drive failed without prior notice -
>>>> the last one after a reboot.  In such cases I am prepared to live with
>>>> the risk of some data loss, on machines where raid is not an option.
>>> Without some form of redundancy that would be your best strategy -
>>> decent and frequent backups
>> It isn't the most mature solution, but btrfs send has a lot of
>> potential here.  One of the main costs of backups is the need to walk
>> all the data that you intend to backup to find changes.  Rsync can do
>> wonders with minimizing bandwidth, and something like duplicity which
>> uses librsync can do wonders to minimize the size of serializing that
>> in files, but both require reading the entire filesystem.
>>
>> Btrfs send can serialize a set of changes in the filesystem by reading
>> only the btree nodes and extents that have changed.  It is fairly
>> close to a git pull in that sense, though git doesn't use balanced
>> trees.  That would greatly reduce the IO cost of frequent backups.
>> You would just periodically create a new snapshot, do a send between
>> the last snapshot and the new one, and once you've confirmed
>> successful completion of that you'd delete the old snapshot.
>>
>> Of course, IO seeks aren't nearly as expensive on an SSD as they are
>> on a hard drive.  I haven't really done a lot of rsync on ssds while
>> using them so I can't really vouch for how much the IO impacts
>> operations.
>>
>> But yes, backup and RAID are really your only options for SSD failure
>> as far as I can see it.  That and limiting the amount of data that
>> can't be re-generated.  If you just save the world file and all of
>> /etc you could probably rebuild a Gentoo install fairly quickly on a
>> new drive, and then you're just left with /home and whatever else you
>> happen to have installed that sticks stuff in /var that you care
>> about.
>
> Thanks Rich, I have been reading your posts about btrfs with interest, but 
> have not yet used it on my systems.  Is btrfs agreeable with SSDs, or should I 
> be using f2fs:
>
>  http://www.phoronix.com/scan.php?page=article&item=linux_314_ssdfs&num=1
>

neither. Just use ext4.

You don't want to combine the sensitive nature of a ssd with the
youthful playfulness of a young filesystem.

Also, I am a little bit concerned about that 'freshly formatted' at the
start of the article.