Backups: a note

by Juliet Kemp

For those of you who (like me) separate the root partition & user data, and don't bother backing up the former because it's a standard install & therefore easy to recreate: note that whilst this is in general true, it may not be in the case of /root.

I at least have a tendency to leave a handful of Useful Scripts there, in particular in the case of server machines. It is annoying to realise that the death of Machine X has also resulted in the loss of the Useful Script you had spent some time developing.

Conclusions I have drawn from this:
1. Back up /root.
2. Consider keeping the Useful Scripts more centrally, even if they are machine-specific in a couple of instances (I do this already with everything else I am not sure why I haven't thought to do it for these. Some peculiar form of blind spot, evidently.)

In a further relevant note: the rescue mode of the Debian etch SPARC CD works fine, albeit quite slowly. The only real issue is that the cursor fails to show up on any of the screens so choosing the correct option is to some extent a matter of guesswork (most irritating when your guess results in hitting the "Reboot now" option rather than the "Choose another root partition" option). Useful Scripts now safely rescued, however; and backed up.


2007-05-10 11:44:16
svn every file you touch. mirror your svn database.
2007-05-10 12:39:29
also don't forget /usr/local. that's where most of my "useful scripts" end up (/usr/local/sbin for system scripts, /usr/local/bin for user scripts).

my self-compiled software also ends up in there, but it's actually in /usr/local/stow (and symlinked into bin & sbin by stow) which is not included in my backup (but archived separately at time of installation if reasonably complex to recreate).

2007-05-10 15:52:29
Create backup folder, it could be on any of the userdata partitions. I create 22 folders (one months worth of work days) backup/daily-01, daily-02 etc. Edit crontab to make cron.daily run 1-5 and put this dailybk.scr script in cron.daily.

#! /bin/bash
filename=`eval date +%F`
cd /export/backup
rm -rf /export/backup/daily-22
mv daily-21 daily-22
mv daily-20 daily-21
mv daily-19 daily-20
mv daily-18 daily-19
mv daily-17 daily-18
mv daily-16 daily-17
mv daily-15 daily-16
mv daily-14 daily-15
mv daily-13 daily-14
mv daily-12 daily-13
mv daily-11 daily-12
mv daily-10 daily-11
mv daily-09 daily-10
mv daily-08 daily-09
mv daily-07 daily-08
mv daily-06 daily-07
mv daily-05 daily-06
mv daily-04 daily-05
mv daily-03 daily-04
mv daily-02 daily-03
mv daily-01 daily-02
cp -al /export/backup/root /export/backup/daily-01
touch /export/backup/daily-01
rm /export/backup/root/*.log
rsync -a /root/ /export/backup/root >/export/backup/root/$filename.log
df -h >> /export/backup/root/$filename.log
date >> /export/backup/root/$filename.log

If the server is important, I build a "snapshot" backup server with a fancier version of this script and rsync all the important stuff. I set those up to save 12 monthly backups as well. With cp -al the backups don't really take up that much space. Great use for old desktop machines and a cheap big IDE drive. Warning, I edited this script for posting it may have a typo or two.

2007-05-11 06:26:14
Also don't forget /var/lib/mysql.
I did.
Juliet Kemp
2007-05-11 07:35:21
Alberto: yep, done that too!

MC: thanks for the script. I have some databases etc I back up like that; I should consider extending it.

q: Totally agreed in theory. Very bad at putting this into practice.