Debian Administration

You seem to have all the important things covered, with the possible exclusion of any user home areas, and any mail spools.

I have a script which I wrote which backs up the following directories:

• /etc/
• /home
• /usr/local
• /var/lib/dpkg
• /var/spool
• /var/log

Storing the output of dpkg --get-selections is handy, but it's redundent as that information can be rebuilt from the /var/lib/dpkg/status file, so I don't bother with that step.

I only keep five days of backups by putting everything in a .tar.gz file, and rotating it that keeps the space usage down, but gives me a week to realise I've deleted something I wanted to keep!

I do find that keeping logfiles is useful, especially if you're worried about a system compromise ..

-- Steve.org.uk

Another, though somewhat tangential, item that one might keep at least a local copy of (generated from a daily cron job) is a list of all files including owner/permissions for those pebcak moments when you get creative with chmod -R :)

We get a lot of people on #debian asking things like:

I just typed

chown -Rf root:root /

and went for a coffee! Help.

A simple recovery for such cases would be having a local copy of the system's ownership and permissions.

It's worth noting that some packages stick their data in strange locations - for example the Gallery package places all its albums in /usr/share/gallery/albums.

It could be worth making sure that the packages you have installed don't store date in non-obvious directories like that. Or you might miss them in the backup.

Steve
-- Steve.org.uk

I keep all my backupworthy files in a svn-repository.

Doing any one of these would be a good start: apt-get install hdup apt-get install dar apt-get install rsnapshot apt-get install rdiff-backup For people with more complex needs like backing up many different machines, then try: apt-get install bacula

mysqldump -u root --password=$MYSQLROOTPW --all-databases --opt > "/var/backups/mysql-$DATE.sql"

Would you honestly ever like to be in a position to have to restore a single database out of what could be a massive .sql file? Heres a snippit of the script I use:

#Options:
CACHE=/var/backup/
MYSQL_USER=root
MYSQL_PASSWD=rootpwd


  test -d $CACHE/mysql && rm -rf $CACHE/mysql/* || mkdir -p $CACHE/mysql

  MYSQL_DATA_DIR=$(grep datadir /etc/mysql/my.cnf | sed -e "s/.*\=//")

  echo "Starting Mysql backup"
  COUNT=0
  for db in $(find $MYSQL_DATA_DIR/ -type d | sed -e "s/\/var\/lib\/mysql\///");
  do
   #echo "[$(hostname)]  Dumping Mysql DB: $db"
   mysqldump $db -a --add-drop-table \
        --allow-keywords  -q --user=$MYSQL_USER -p$MYSQL_PASSWD\
        | bzip2 -c \
        > $CACHE/mysql/$db.sql.bz2
   if [ $? = "0" ]
   then
    echo "  Dumped $db to $CACHE/mysql/$db.sql.bz2"
    COUNT=$(($COUNT+1))
   fi
   if [ $COUNT -eq 0 ]
   then
     echo "No databases dumped!"
   fi
  done

Probably a few crap things about that, but it Works For Me™

rdiff-backup is an awesome backup utility

Instead of listing what to backup, isn't it safer to list the things you don't want to backup and backup the rest ?
What would you list in your 'don't-care-list' ?

Rebuilding a system is much easier if you back up any service configuration files. If you do not work with a configuration file on a regular basis then customizing it can be time consuming. This is especially frustrating if you are rebuilding a configuration file to match restored data.

I regularly back up the following configuration files:
Apache2: /etc/apache2/apache.conf, /etc/apache2/sites-available/, and /etc/apache2/mods-enabled/
PHP: php.ini
Samba: /etc/samba/smb.conf
MySQL: /etc/mysql/my.cnf

If you are using a locally stored backup script to back up to a remote or removable device then you should also back up your backup script.

I knew I'd find the answer here :-)

I backup my home computers over the net to an online server using rsync. Because of the limited bandwidth and quota on the server I can't just backup everything, so I copy things like /home (carefully avoiding things like Iceweasel's cache), some of /var and /usr/local, and /etc. At one time I tried to prune what I copied from /etc (e.g. the 3 MBytes in /etc/X11/xkb and the ridiculously-overhuge gconf) but that was too painful to maintain.

To aid recovering the Debain packages, I had been doing "dpkg -l", but I was aware that that could be truncating the package names! The "dpkg --get-selections" suggested above avoids that problem.

One thing that is not included in the --get-selections output is the package version. This raises the interesting question of what to do about package versions when you restore. On the one hand, you could install the latest versions of each package. This has the advantage that the packages will all be available "from the usual places", but the disadvantage that your configuration files may need to be updated because the package has changed, or new dependencies may need to be installed, or functionality may have unexpectedly changed. The package might not even exist any more! If the aim of your backup/restore policy is to get back to your position immediately before the failure then this isn't what you want. So on the other hand you could (how?) store the package versions, and then (how?) install those same versions when restoring. What do other people do about this?

One of the comments above notes that you should store your debconf data. Good point. Would it be possible to semi-automate the restore by generating, either at backup-time or restore-time, a "pre-seeded" debian installer thingy based on the saved debconf data? I know next to nothing about this, but if it's a one-liner then it would be good to know. Google suggests "debconf-get-selections --installer > file ; debconf-get-selections >> file".

Pre-seeding deals with the debconf configuration, but restoring the /etc config files when the packages that they correspond to may have been upgraded is another challenge. Is there some way to run the packages' "here are the differences between your version and the maintainer's version of the conffile" dialog after restoring your old /etc contents? Storing your /etc files in Subversion and using its merge features would also help; I really must get around to trying that.


Phil.

It is quite unsecure to expose your credentials on command line, especially, if you do your backups automatically! Reconsider not to calling mysqldump this way:

mysqldump -u root --password=$MYSQLROOTPW ...

There is a user debian-sys-maint created by the installation scripts who perfectly fits for doing backups: it has All PRIVILEGES on all databases and the system stores it's credentials in /etc/mysql/debian.cnf ini-style configuration file readable by the root user only. The problem is how to get credentials from the configuration file.

I'm using this little script named parse-ini to parse ini-file:

#!/bin/sh
[ -z "$1" ] || [ -z "$2" ] && exit 1
sed -e 's/[[:space:]]*\=[[:space:]]*/=/g' \
    -e 's/;.*$//' \
    -e 's/[[:space:]]*$//' \
    -e 's/^[[:space:]]*//' \
    -e "s/^\(.*\)=\([^\"']*\)$/\1=\"\2\"/" \
   < $1 \
   | sed -n -e "/^\[$2\]/,/^\s*\[/{/^[^;].*\=.*/p;}"

It returns a sourceable list of variable definitions from $2 section of $1 ini-file. Now, my backup script looks like:

touch $mysqldump
chmod 600 $mysqldump
eval $(/usr/local/bin/parse-ini /etc/mysql/debian.cnf client)
mysqldump -A -u $user -p$password > /srv/backup/mysqldump_all.sql

First two line are also important for security, don't forget them!