public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download: 
* Re: [gentoo-user] Safeguarding strategies against SSD data loss
  @ 2014-10-27 13:13 99%   ` Rich Freeman
  0 siblings, 0 replies; 1+ results
From: Rich Freeman @ 2014-10-27 13:13 UTC (permalink / raw
  To: gentoo-user

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


^ permalink raw reply	[relevance 99%]

Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2014-10-27  9:24     [gentoo-user] Safeguarding strategies against SSD data loss Mick
2014-10-27 11:11     ` Alan McKinnon
2014-10-27 13:13 99%   ` Rich Freeman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox