Richard Wilson escreveu: > 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 > > I use svn. But, instead of backup all the files on /etc, i do something quite different. I do have one big repo with configs of all of my firewall's. Then, i do install the openbsd release and do copy the config's of one of my other firewall's and create a dir specific to the new machine. Then, what i do is the following: install the openbsd release, install subversion, checkout the specific dir for the machine inside /root/frw-<name>. But, instead of backup all /etc or all /var/named/etc, or all /var/www/conf, etc. I do only backup the conf's that i modify. So, if i alter /etc/sysctl.conf and /etc/pf.conf, there will be a /root/frw-<name>/etc/pf.conf and /root/frw-<name>/etc/sysctl.conf, only these 2 files. This make the upgrade process much simpler, and also helps make things simpler. Why backup /etc/rc when you almost never will change it? And /etc/rc is a file that almost always changes from release to release. I do make symbolic links for the confs from /etc to the svn checkout inside root. So /etc/squid/squid.conf, instead of being a file, is a symlink to /root/frw-<name>/etc/squid.conf. As you may have noticed, the svn checkout layout reflects the same hierarchy as the / filesystem. So, if there is a file /var/named/master/somezone.com, there will be a correspondent /root/frw-<name>/var/named/master/somezone.com. A smart script can tell any diff's from them. I do have cron mail me these diff's, cause there are third parties that mess with some conf's also. But i do never make commits being automatic. This is error prone. What if some other people make a big mistake in some conf file? you will have to keep checking out earlier revisions of the file always. Also you could make some mistake. Well, this is it.
My regards, [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
