[Hans M Aus]

What's a reasonable hardware SOHO backup scheme?

I'm thinking about using an external firewire Raid with two hotswapable disks. We would alternate the disks each day and hot swap the disk in the evening. In the worst case, the backup disk would be only one day behind.

Questions:
How long would take yesterday's disk to catch up?
Is it doable?
Other ideas?

[mduell]

Figure about 3GB/min for disk syncing; depends a lot on the quality of your RAID controllers.

Doable? Yes. Advisable? No. Doing a daily rebuild with a SOHO grade RAID controller is just asking for trouble.

How much data are you talking about? How much changes daily? How long is the backup window?
Does it contain personally identifying information (name, SSN, DOB, etc) or other privacy-critical information (HIPPA, credit cards, etc)?

[Hans M Aus]

Originally Posted by mduell 

Figure about 3GB/min for disk syncing; depends a lot on the quality of your RAID controllers.

Doable? Yes. Advisable? No. Doing a daily rebuild with a SOHO grade RAID controller is just asking for trouble.

What controller should we use?

How much data are you talking about?

The database is approximately 100GB big.

How much changes daily?

The operation evolves about 1000 new entries each day.

How long is the backup window?

From late evening until early morning.

Does it contain personally identifying information (name, SSN, DOB, etc) or other privacy-critical information. (HIPPA, credit cards, etc)?

YES !

[OreoCookie]

First of all, a RAID is not a backup. For several reasons it is a bad idea.

(i) A RAID(1) is not a backup. A RAID (with the exception of RAID0) is to protect you from (physical) drive failure. A RAID does not protect you against failure of your filesystem, data inconsistencies in your database and accidental deletion. There is no safeguard.
(ii) What you want is a daily clone. Clones aren't backups either. You have at most two days worth of backup, you have zero access to data that was deleted up to three days ago. If your database fails and you don't notice it for two days, you're screwed.
(iii) Especially with database, there is no guarantee that the clone will contain a usable copy of your database. If you unplug the second harddrive during a transaction, for instance, the cloned database on the drive might be useless.

Instead, you should consider a real backup solution, i. e.
(i) Access to backups that are older than a few days.
(ii) Making sure that the database that is backuped is in a consistent state.
(iii) Having several copies at hand, off-site and on-site.

In principle, external harddrives are a usable form of backups, but I would probably add some form of off-site backup. You can switch external harddrives on a weekly basis and keep the other one offsite.

[mduell]

Originally Posted by Hans M Aus 

What controller should we use?

I can not (since I don't know the market that well) and would not (since the RAID break/rebuild idea is so bad) make a recommendation there.

Originally Posted by Hans M Aus 

Size? The database is approximately 100GB big.

Growth? The operation evolves about 1000 new entries each day.

Window? From late evening until early morning.

Privacy? YES!

As Oreo said, you want to clone your server's entire drive every night onto another drive or tape. The decision between drives and tapes depends on how many days you might need to go back to recover; if it's small (less than a week) drives are fine, otherwise tapes are more cost effective. Despite the relatively static nature of your data, I don't think you really have enough data to justify going to a full+incremental or full+diff strategy.

Since you're storing privacy-critical information, you need to encrypt the backup. Either use backup software that supports this, or store the backup in an encrypted disk image. Put a copy of the key in a safe deposit box which requires two company officers (or similar) to open. There have been a number of data thefts (leading to identity theft, liability, and all that fun) resulting from offsite backups being stolen.

And remember to test your backups early and often. Everyone (in their right mind) makes backups, but few people ever test them. Grab a spare machine and recover the server on to it as often as is practical and prudent; I'd say once a month to once a quarter is a good timeframe.

Here's a story about another company that had the same idea you started this thread with: RAIDing Disks - Worse Than Failure
I hope the title of the page doesn't spoil the ending.

[OreoCookie]

That's an excellent link, mduell! I'll add it to my collection

[Hans M Aus]

Thanks for all the interesting, important input, and the article. It's interesting to note that the raid "backup" scheme failed only after several years.

In my previous life before retirement, I ran a DB which shut down every night, checked for that the DB was in a consistent state, and backed up to tapes, which were recycled once every month. ALSO, most important, the IT staff was responsible for the operation ,especially the nightly backup.

In a SOHO environment the situation is different - nobody worries about fail proof backup until the moment after the big bang.

The sinking cost of disk drives makes it tempting to drop the tapes.

How does this sound?

A two disk raid set.
Five (or ten) disks to clone the system every night.

[OreoCookie]

Have you had a look at the link at all? That describes the failure of the solution you describe and gives explains why. Do not abuse a RAID1 as a cloning device, especially when all crucially depends on the integrity of the source drive.
Again, a RAID is not a backup solution and what you want to do is a really bad idea.

You can do backups onto drives, even onto RAIDed drives, but that's not what you propose. Either get tape drives or do backups onto external drives (RAIDs) using regular software. Make sure to use a RAID as a source drive to protect against drive failure.

[Hans M Aus]

Originally Posted by OreoCookie 

Have you had a look at the link at all? That describes the failure of the solution you describe and gives explains why. Again, a RAID is not a backup solution and what you want to do is a really bad idea.

Yes, I read the read and took article seriously.