0

I run a subversion source control server from my house on a debian machine. I will be setting up Jira for bug/project tracking very soon so I now have the necessary motivation to put a proper backup plan in place. The current hard drive in my server is going on probably 10 years (an old 80GB IBM deskstar) so I'm looking at picking up a couple of 250GB WDs from newegg and see these options so far for my backup:

1) Setting up a RAID1 array

  • I have never setup a RAID configuration before
  • My gumption is that this is more
    robust, but does that come at a cost of complexity?
  • How difficult is it to replace a drive that goes bad in RAID1 configuration?
  • I do not need instant access to my data, 24 hour replacement is good enough - so RAID may not be the best option

2) Setup a nightly diff backup

  • Is this simpler to setup and maintain?
  • Are there any good free linux diff backup programs?

I also plan on using something like Jungledisk/AmazonS3 for offsite backup. I welcome thoughts on the above 2 options, and any alternative solutions.

Tone
  • 601
  • 4
  • 13
  • 29
  • Another reason RAID isn't a backup: someday you'll do `rm -rf * ~` or something equally regrettable; RAID can't protect you from this. – Tobu Jul 03 '10 at 13:52

1 Answers1

1

Raid is not a backup option. Please repeat that out loud at least ten times. Do not rely on it for data integrity, you will get burned. The purpose of raid is to have less time where your data is unavailable due to mechanical failures. (and to increase throughput)

The complexity of raid1 depends a little on the controller. The way your setup sounds, it could be a good idea to use linux soft raid. Use the 'new' drive to create a degraided raid array, move all the data to it (no need to reinstall, you could move the OS with a live-cd if you want to), then wipe the old drive and attach it to the raid. Do this after you have proper backups. Replacing a drive is as simple as that.

rdiff-backup is my tool of choice in a lot of situations (don' forget to clean up old data), you may also like rsnapshot. Any backup storage to different machine, preferably on a different location is a good one, if it comes down to JD/S3 I have no preference.

Make sure to take dumps of both the svn repos and the database and include them in the backups. (do not believe that about svn fsfs backends not needing this)

Check your backups once in a while, and check your backup process daily. Do this is a way it requires least effort; routine chores lapsing can give you a false sense of (data)security, with a nasty wakeup later (don't ask...)

Last but not least: make sure you have checked out redmine before you settle on jira; it's a matter of taste, of course.

Bonus points for running 10 years on a single deathstar
Joris
  • 5,969
  • 1
  • 16
  • 13
  • this is good feedback. i'm thinking a simple nightly diff backup will do for now. Right now only two users will be accessing the svn and bug/work item system and it's not a big deal if it's down for a day or even two. I'll look into Redmine - thanks for the pointer.. wondering if Redmine is as robust as Jira - Jira you pay $10 for a one time license for 10 users so it's basically free as well, and it has plugins for svn among other things.. so seems like a more comprehensive system to learn and be able to grow into as my company grows. – Tone Jul 02 '10 at 14:06