>If you can run two disks and raid, that's always a good idea. SMART is >supposed to catch disk problems, but they still do die without warning. > >btrfs raid is (still) full of gotchas, as far as I know. > >Don't use anything higher than raid-1. Parity raid isn't reliable last I knew >...
It's still not *officially* recognized as safe, but I have seen a number of people testing various ways of hitting it over the head that used to break it without losing their data. Big thing is that in the case of power failure you really *need* to run a scrub just in case there was an incomplete write. One will be fine, but if you allow them to stack up you will *eventually* start losing things. >> Your favoured snapshot/backup strategy? > >Manual ... probably shouldn't be. I snapshot / every friday before I do an >emerge on Saturday. /home I ought to snapshot more than I do. Note that you can use the snapshot to build your updates as binpackages and test out how they work before touching your main system. Saves on service downtime and doesn't risk breaking your main system if something goes wrong. Does maybe mean doing the upgrade twice unless you just pivot to the snapshot once it's ready. > >WATCH YOUR FREE DISK. I think it's all sorted now, but whatever you're using >it was always a good idea not to go over 90% full. For a very long time, a >combination of snapshots and a full disk would wedgie the system, such that >the only way to free up space was to reformat the entire disk! As I say, I >think it's now fixed so you can delete snapshots, but >90% ain't a good idea >anyway Mostly sorted. You can still get it wedged if you run the disk all the way up to full, but you can, at least, add another volume to give yourself workspace to straighten it out. And it only seems to happen if you're using disparate-sized disks in a RAID, which throws off its free space calculations. LMP
