Am 27.10.2014 um 14:13 schrieb Rich Freeman: > On Mon, Oct 27, 2014 at 7:11 AM, Alan McKinnon <alan.mckin...@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?
