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

Reply via email to