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 17:17 99%     ` Volker Armin Hemmann
  0 siblings, 0 replies; 1+ results
From: Volker Armin Hemmann @ 2014-10-27 17:17 UTC (permalink / raw
  To: gentoo-user

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?


^ 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       ` Rich Freeman
2014-10-27 17:17 99%     ` Volker Armin Hemmann

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