Backup
From FGVwiki
I started a little work, to create scripts for making daily backups of various applications or systems, and to create scripts for re-installing / configuring these systems if they disappear, or are moved to a new host. The scripts and the backups they produce are maintained in Subversion: http://shop.freegeekvancouver.org/svn/system/trunk/
The idea is that the backup script (maintained in Subversion) makes daily backups in the same Subversion repository. The re-installation script (also maintained in Subversion) can then use these backups to re-build the system as it existed less than 24 hours before.
The goal of completely non-interactive re-installation scripts - scripts which could be run on a regular basis to re-build systems based on changes committed to Subversion - may be a fantasy. However these scripts could still be interpreted by a human to re-build the system manually. Therefore they should be well documented. And I think the goal of a non-interactive re-installation script encourages the author to be precise.
Contents |
SQL Dump to Subversion Cron Jobs
The backup scripts I am working on frequently take the form of dumping a database to a flat file, then committing that file to Subversion. This is not a comprehensive backup system. For example, I do not know how to accommodate dumping whole server filesystems to Subversion, or which other tools could be used for dumping whole server filesystems. However it does work quite well for backing up databases.
Dumping databases to Subversion works well because it only commits a backup if the database has actually changed, whereas dumping to the filesystem usually creates a backup for every day, whether two days are identical or not. If the database has changed, and the dump format is halfway human legible, then one can sometimes get an idea of what changed by looking at the Subversion changelog.
TODO
The next systems I would like to create backup scripts for are Subversion itself, and Gallery. Backing up Subversion to Subversion may seem a little "meta", but there are some configuration files, like the post-commit hooks, which I think would be good to capture. Obviously the Subversion repository itself, or the filesystem where it is stored, cannot be backed up to Subversion - it should be backed up to some other host, possibly at a second site.
Conffiles
It would be really handy to commit updated Debian / Ubuntu conffiles to a Subversion repository after every update / install: http://thread.gmane.org/gmane.linux.debian.devel.dpkg.general/9732
This would probably be easier in dpkg 2.0, with classes and filters: http://multiarch.alioth.debian.org/dpkg2.pdf
In the meantime, one challenge is getting the maintainer's version of the conffile. It could come from the .deb archive, or from the disk, if it hasn't been modified. I think the disk is easier.
The DPpk::Post-Invoke configuration could be used to run a script after every package update / install / remove.
The Subversion repository could then be kept up-to-date either by `svn rm` the maintainer branch, then `svn revert` for each installed conffile, or using the svn-load script. Using svn-load, the code would be more generic, since it could make copies of conffiles either in a Subversion repository, or anywhere else. However conffiles would be copied first to one temp directory, then svn-load would copy them to another. Also, we probably want to automatically copy them out of the vendor branch. So a custom script may be necessary anyway.
I imagine such a script could be written in sh. The postinst scripts have some good examples of getting conffiles and md5sums from dpkg-query.
Old
we need to implement a backup system for the shop
all that has been done so far is a nightly cronjob that dumps the postgres fgdb (see fgdb@cedar cronjob which runs cedar:/home/fgdb/backup-database.sh)
we need to also dump the mysql on cedar which has the data for this wiki
then we need to dump the filesystems of birch, cedar, and any other servers in the shop.
