TR Forums

I was asked to sort this out for some one who's running a Linux server and the first place I looked at that did this kind of thing (on Linux anyway) wanted nearly $200 a month.

So forget that ($20 I might have lived with)

Anyway I thought I'd have a go myself (after all, isn't this what rsync is meant for?)

So here's my plan...

server to be backed up will have SSH installed (DSA keys only for authentication)
EDIT: since my dsa keys will have no passphrase set (so it can be automated) I'm locking down that key so it can only run rsync)

2 separate remote sites will have a cron job that makes them log in at 4AM (no one should be working at that sort of time) and rsync the entire /home directory (which has all their data in it)

Any obvious flaws with what I'm planning?

Any suggestions as to how I could keep the backed up data encrypted so that only the clients have access to it. I'm too worried about this but it would be nice if there isn't too much involved. I was planning on giving them remote access to their backups through sftp (or some such) any ideas about how I could handle that if I encrypted all the data?

EDIT EDIT: I'd also like to have a log kept of what this thing is doing.
I suppose I can do that with something like:

rsync -azv -e "ssh stuff " remote user stuff:path stuff >> remotebackup.log

but how do I get it to put a date stamp in there? (something like echo date >> remotebackup.log ?)

I could easily be missing something, but as an attacker with access to one of the backup systems, why would I bother trying to decrypt the backups when the key used to retrieve them is on the same system and requires no passphrase.

nulltrust wrote:

I could easily be missing something, but as an attacker with access to one of the backup systems, why would I bother trying to decrypt the backups when the key used to retrieve them is on the same system and requires no passphrase.

well true, that's one of the reasons why I wasn't too worried about doing it. The main reasons I wanted to encrypt were that: I could tell the clients the it was encrypted so they could sleep well at night (whether is actually meant anything or not), and to stop another client see anyone else's data.

I suppose the latter is probably better servered by setting file permissions properly

Well for better or worse I've gone ahead and fitted the system I outlined above.

A couple of small changes I made...

originally I had the rsync command like this:

and I had it running on the backup server.
which is stupid since it means I'd have to open ports on both firewalls (since the clients recover files through sftp so the backup server had to have a port open for that). I switched the $RPATH and $LPATH round and ran the script from the main server so only the backup machine (which is in a DMZ) needed to be exposed.

I also added:

in front of the rsync command so the logs would make more sense.

Just need to create a script to backup the backups and I'm all done

Must say, rsync rocks

I use this script for my backups:

http://ribs-backup.org/

Basically a wrapper for rsync+ssh for doing stuff like incrementally backups, etc. It can also be set up you email you a complete log file each time it runs.

It's nothing you can't code up yourself easily but it can save you a little time