Richard Wilson wrote:
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.
This is exactly why I don't allow /etc, /var/cron/tabs, and so on to be
working directories. Like you mentioned, it will crap out some programs.
I use rcs instead of cvs; much simpler and effortless to setup and
manage. What I do is create an RCS root, /root/rcsroot. The first time I
need to change a system file, I copy it into /root/rcsroot, maintaining
directory hierarchy of course. For example, /etc/pf.conf would go to
/root/rcsroot/etc/pf.conf. I make changes to files in the rcsroot, and
when I like the way they look, I copy them to the system and check them
in. This preserves original file permissions and doesn't clutter the
system with repos stuff. Also, I can quickly see and maintain only what
I have modified.
I must confess that I perform these actions manually, like the copying
of the working file back to the system. This could be scripted to make
it even easier. I thought about it, but it's just so easy already. For
example you could modify a config file using a single command: `confedit
/etc/pf.conf`. It could perform the 2 or 3 other commands needed to copy
files around and do the check-in.
For backup, I do `dump | ssh backupbox` from cron. Simple and easy.
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 :-)
This is a good discussion. Please do enlighten use with your setup.
-pachl
