There's no reason (except time and money) you can't do both: A "local" image for quick disaster recovery, and offsite backups for more refined restores for individual problems.

The best source for bacula tutorials is the bacula site. Follow the documentation link. (www.bacula.org)

_________________
The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world.
-- seen on the net

backupninja is worth looking at, it's wonderfully easy to set up using ninjahelper, and is essentially a wrapper around rdiff,mysqldump and a few other features.

It runs with a push rather than pull paradigm so is better suited to smaller deployments, but the upside of this is it runs unprivilaged on the remote host, and as root on the local host.

I've been running this both locally safeguarding my workstation, and on my linode sice I got one about 18 months ago, I've lost track of how many partial restores i've had to do (trigger happy with rm -r and busy breaking dev databases) but it's never failed me.

http://dev.riseup.net/backupninja/

_________________
Open Sorcery
http://technomancer.me.uk

Hi,

Firstly; apologies on late feedback, I've been away a few days.

I gave Backup Ninja a shot and it worked very well, and quickly which is good I was only mildly irritated that ninjahelper had no way to create an action for my subversion repositories, but copying the example config with slight modification was hardly difficult.

I have not given Bacula a go yet; but to be honest due to the speed I got Backup Ninja going to the point where I could restore what I needed, I think I will stick with that for the time being. Steve's comment that Bacula is a bit of a monster is keeping me away just now as I am swamped with work , unless I find Backup Ninja does not cater for something I need. Thanks for the info anyway Steve.

My original hope having looked at Rdiff (as you pointed out backupninja is just a wrapper for rdiff and some extra goodies) was that I would be able to Rdiff my whole file system, heavy hit the first time but should be small amounts going across to remote backup each night, and essentially just pull back the whole file system on top of a blanket debian install, in the case where my linode went boom.

However, due to the fact that with databases it seems important to do a dump that you can backup, the notion of just copying the underlying file system does not seem to be a goer, I wouldn't feel confident that the restore would contain my MySQL databases in a working condition, even if I was to restore the individual databases as other parts of the filesystem may not have been stable when the backup ran.

With this in mind; I can only see the following backup strategy as one where I can get up and going with confidence in a reasonable time:

Take a local copy of my prod disk image
Clone that across to my remote host
Setup my backup software for MySQL dumps, Subversion copies and Rdiff the following:

/var (all web sites, email, cron job and the MySQL and Subversion dumps that run before RDiff)
/home/me (all I care about as I run virtual users for clients)
/root
/etc

There are two RDiff's; one for the remote copy and the other locally to prod; if my remote server should be the one to go boom then I do not have access to incremental backups (unless I do a nightly backup of my remote host too, which I am not going to do)

With this setup; I have a local disk image to start up or a remote one should my whole Linode die and I need to start again and I have enough in my backups to restore everything to the previous evening on top of the image.

I need to make copies of my production image to local and remote should I install new software, but this should be rare once I get going and prod only needs to be down long enough to do the local disk image copy, so even with a large file system I am hoping 30 mins at the very worst.

Outside of the complete disaster scenario it is very easy to cp the previous evenings database, subversion repository or missing file and restore should I need to as the data is both local and remote.

That's my thoughts anyway and what I am trying to put in place, and test out obviously. The downside is the amount of space required to do all of this, but the upside is confidence in getting up and going quickly in a complete disaster scenario.

If anyone has a simpler model I'd love to hear it

Cheers,
Paul