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
