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

[Mick <michaelkintzios@gmail.com>]

[-- Attachment #1: Type: Text/Plain, Size: 3254 bytes --]

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

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]