Monthly Archives: December 2007

Belt and Braces

Dear Reader,

Well I’m now putting in place measures to stop all my work disappearing again! (To be fair it was only one days work, but it annoyed me enough to want to do something about it)

So now I have flyback working on two computers, the one in the office and the one at home and also in the office I have rdiff-backup working to an external hard drive.

This is done by a number of lines in crontab such as:

0 1 * * 0,3 /usr/bin/rdiff-backup /media/sdb1/username/data/archive /mnt/usbback/archive
0 2 * * 0,3 /usr/bin/rdiff-backup --remove-older-than 9M /mnt/usbback/archive

Two important things:Note 1: the full path of rdiff-backup is specified as cron doesn’t use environment variables.

Note 2: Using an external hard drive with FAT32 doesn’t work with rdiff-backup. Reformating in Ubuntu is tricky using gparted as the darn thing automounts everytime you try to reformat. I found a hint on a forum to use the openbox window manager to run gparted which solves that problem. Once you have reformated as ext3 you then have to make sure you have permission to write to the drive, this I did by altering the /etc/fstab file like this:

/dev/sdc1 /mnt/usbback ext3 defaults 0 2

and then ensuring the /mnt/usbback directory was owned by the user (well me) that I wanted to run the backups on.

This eventually appears to have worked….

Advertisements

Flyback on Ubuntu 7.10

Ok so I’ve now tried out the flyback programme – which seems to work! The instructions are here on how to install it – I would recomend the svn version as this has more features.

One bug I have encountered is that the programme always seems to expect the flyback.py file to be at: /home/user/flyback.py whereas I’ve stuck mine in /usr/local/flyback/flyback.py A workaround to this is to set your crontab values in the flyback GUI and then edit your crontab file using crontab -e to point to the correct executable.

I’ve got it backing up my working directory 1.3 GB or so and this seems to complete in a few seconds once the initial back is completed.

Backup Solutions…

Dear Reader not having the guts to go and just start doing all my work again – I have instead started playing around with potential backup solutions, there are three alternatives that look promising:

  1. TimeVault coming to Ubuntu soon – though it’s not yet there and looks potentially complicated to backport to a dapper drake system
  2. rdiff-backup which looks well established and stable but doesn’t seem to have a way of browsing backup files
  3. Flyback which looks untested, trendy and easy to use – so of course I’m trying this one as we speak, cause what you really want in backup software is flash, untried software 🙂

For added redundancy I might actually use flyback and rdiff-backup together! Losing all my work has really annoyed me.

Data Loss with Unison

Well dear Reader I’m really up the creek this time. Using the (so far) quite reliable Unison file synch program it’s all gone base over apex. A bunch of files which I’d done approx six to eight hours work on have all be reduced to zero bytes size in all three of my replicas (home computer, work computer, usb drive). I’m really not sure how this happened there is a Debian Bug on something that looks familiar I’m using 2.13.15 where the release notes claim that is fixed however! The problem is that the data has propagated through with zero bytes over a couple of synchronisations so all of my files are corrupted…. all I’m left with is a half completed bibtex file.

Oh Dear….