Increasingly, I find that I have many servers, especially OpenBSD servers, where the only bit of the hard drive worth backing up is /etc. Good examples are routers or spamtrap boxes where everything is part of base. If a hard drive goes pop, all I need is to install the OS, and re-populate /etc.
Currently I back up /etc on these machines using variants on rsync and rsnapshot, and it works OK. However, I've got it into my head to shift to using CVS to back up /etc on these machines. Advantages I think I see: 1) /etc is mostly flat text files. It makes more sense to back it up using a system which is text-based, rather than the belt and braces of rsync. 2) CVS is big on diffs and such. Checking to see which config changes happened to a given file, and when, gets really easy. 3) The nightly backup procedure just becomes a 'cvs ci' in cron. If nothing changed, no additional space is taken. However, if a change has been made, that change is stored efficiently, and cron will auto-magically send me an email of the change delta, because of the output from the cvs ci. 4) If someone makes big changes, they can manually do a checkin, just to be sure. 5) If everything goes hideously titsup, and there's disk corruption on the CVS server, I've still got a chance to recover data, as the CVS data storage format looks vaguely like plain text. This is more of a cvs-vs-svn (eep BDB.) If things are sufficiently bad that both a machine I back up and the CVS server are having issues, I suspect I will care about something this unlikely. Before I embark on this, I have a couple of questions: 1) Can anyone think of an idea why I'm being dumb? I hope not, but it doesn't hurt to ask. 2) How will /etc, and the things that read it, react to /etc becoming a working copy, with CVS, Entries, et al? I'm thinking of things that eg "Include /etc/appname/*" barfing on unexpected files left by CVS. To any and all who have read all the way through my disjointed waffle, I thank you. I'll report back once I give it a go :-) Si1entDave
