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

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

Am 27.10.2014 um 14:13 schrieb Rich Freeman:
> 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.
>
> --
> Rich
>
> .
>

what happens if that send stream becomes corrupted?