I was asked to set up a new backup server using Symantec Backup Exec that stores to hard disk instead of tape, because the backup size is outgrowing tape capacity.

I was wondering does it really make sense or are there any advantages for the backup server to be running RAID of any sort as it is the "backup"?

To me, the benefit is not that great to justify the added cost.

I'm interested to see what others think.


  • 1
    Similar tO: serverfault.com/questions/2888/why-is-raid-not-a-backup
    – Andrioid
    Jul 14, 2009 at 16:01
  • 1
    This, from my point of view, is not really the same question as he ask "if there is a reason for using raid on a backup server" not "using raid as a backup". It's almost the opposite side of the question.
    – radius
    Jul 14, 2009 at 16:11
  • I agree, just posted the link because some of the answers are related.
    – Andrioid
    Jul 14, 2009 at 16:12
  • Great answers from other posters. I don't have much to add, but I would argue that if ".. the benefit is not that great to justify the added cost.", you may not realize you're risking your job. Is saving a few hundred bucks worth jeopardizing your job? No one would think less of you if you spent a relatively little amount of money to avoid a complete disaster for the company and your career. Just my two cents.
    – osij2is
    Jul 20, 2009 at 15:12

12 Answers 12


Imo, there's a massive benefit to using raid.

If the backup machine has a disk failure without raid then you'll lose all your backups. How long will it take you to rebuild them?

Also, what if you lose all your backups due to a disk failure, successfully rebuild them, and then need to find something that was backed up previously but got lost cause of this disk failure.

If nothing else, disks are now so cheap that the cost of an extra disk to put the system in raid 5 will probably cost less than your time in the event you needed to recover from a failure.

  • 1
    Not to mention the tremendous advantages in disk speed that certain RAID levels offer. If you're rebuilding off a backup, read speed can be an issue and RAID5 or RAID10 will help. Jul 14, 2009 at 16:14
  • 1
    Be aware that actual disks capacity is given so big that same RAID configurations had become not so safe as they promise to be. I'm referring to the fact that having a big dimension a disk have an increased failure probability too (per sector) .. this simple statistic fact makes probable the fact that a RAID reconstruction after a disk failure make the survived disk to die too ... making a super safe RAID1+HS a totally unreliable system... So, don't use very very big disks for your fault tolerant RAID system. See hds.com/assets/pdf/…
    – drAlberT
    Aug 6, 2009 at 11:14

Server computers should have redundant disks except in very special circumstances (think rack after rack of "scale out" 1U application servers, like Google). A server computer w/o redundant disks is a ticking time bomb.

That having been said, backup isn't backup unless it's off site and offline. If it's on-site but offline (tapes in a drawer) then it's gone when the building burns down (see Cleaning soot out of a server ). If it's off-site but online then it's vulnerable to attack and "corruption".

And now, stay tuned for religious arguments about disk versus tape, etc.

  • Disk + Tape. Neither one is better than the other for everything. Disk is faster for getting backups off of the main servers and onto the backup media servers - it lets you keep your downtime windows short and predictable. You can't guarantee when robot #1, drive #0 is going to be available. Tape is better for offsite. I don't particularly care for VTL, I like the here's a blob, here are 1000 datasets in the blob, arrange them all efficiently on tape for me. (NetBackup 6.5 does this well).
    – Chris K
    Jul 14, 2009 at 18:08
  • 1
    Agreed re: "neither is better than the other for everything". I'm with you-- disk-to-disk is great for shrinking backup windows and quick restores. Getting data offsite and offline, though, is where tape excels. Disk-to-disk-to-tape is the best general "sweet spot" in backup today (with a deduplication step in there, if you can afford it). Jul 14, 2009 at 18:42
  • We use disk -> offsite disk, and disk -> onsite disk. Makes all the backups handy to get at. Not possible in many cases though, thanks to the cost of bandwidth unfortunately.
    – Cian
    Aug 27, 2009 at 12:53

Use RAID-10.

RAID-5 is dumb for backup servers, because:

  • The server spends most of its non-idle lifetime doing lots and lots of sequential writes. Performance Matters.
  • Disk utilization tends to increase over time, so if backup windows aren't something that you're worrying about now, they likely will be in the future.
  • The performance hit you get from operating with a downed disk will cause backups to fail.
  • The usual excuse for using RAID-5 ("disks are sooo expensive, wah, wah") is 100% total bunk for backup, because you can use high-capacity SATA disk.
  • SATA vs. SAS is less important for backup, since you're random I/O workload is relatively small.

Not using RAID at all may be acceptable, depending on whether you're using your backups as a de facto archiving solution or not.

  • Completely agree on the performance aspect of backups. My backup server is currently RAID-5, performance is terrible, and switching it RAID-10 is not going to be fun.
    – Dan
    Sep 15, 2010 at 18:08

What cost? Hard drives are cheap and Raid 1 is pretty much standard on motherboards now.

In my opinion you can't be too careful. I've got raid on my main development machine, I regularly make backups to my home server and my home server makes an offsite backup every night. If it's cheap, easy and seamless I say why not?


Today there are multiple levels of backup, nearline and offsite. Nearline is where you back up to disk. Here you can keep multiple backup sets of highly important data near, while a copy gets made from the backup servers disks to tape and then the tape gets sent offsite. This has several benefits:

  1. backup to disk is usually faster
  2. You have an effectively unlimited # of disk devices, where backing up to tape is usually constrained in the number of heads you have to write at a time.

That said, you should treat your backup servers disks with the same sort of redundancy you treat your database server. Say your database server fails at noon, you can rollback to the backup servers ondisk copy from last night and do your restore, where you tapes might already be a $250 emergency return from your offsite vendor.

You should put RAID on every server you run, IMHO, and not that non RAID RAID-0 crap. :-)

  • Anecodote: when moving a datacenter, some of our drives failed in our Database server. Turned out to be enough to be a risk to keep using the system. So we made two copies, one over the network to another server with diskspace, and another to some external disks. Well, turns out the array was bad, and we only managed to get the network copy (who know going SCSI->Ethernet would beat SCSI->SCSI). Just because you're not likely to lose two disks on two different systems at once doesn't mean it isn't likely to happen.
    – Chris K
    Jul 14, 2009 at 18:05

Yes, just do it. A hard drive is many times more likely to fail than any other computer component. By going to a RAID, you're protecting against the one problem that's most likely to happen. Measure the marginal cost of a RAID setup (probably less than $500, assuming a low to medium-end server) with the value of your data.

Having said that, I second what Evan Anderson said above. This absolutely should NOT be your only backup. Evan talked about being off-site and offline, and I'd add redundancy to that list. You need to have multiple copies of your backups in case of failure of your backup media, backup job, theft, loss, dropped media, etc.


Should you use RAID on a backup server?

For redundancy, I would not

If you are not in the habit of restoring specific revisions of files of your backup system and you fear that you might have to do that in case the backup system disks fail. Then yes, I would use RAID 5 or mirroring or even striping and mirroring.

The only reason to do this if you expect that the original data might be unavailable at the worst possible time.

For expanding disks into one volume (striping)

Maybe, but be aware, that if one disk dies the entire array dies.

Bottom line

I think it is a better practice to backup the backup server. I know it sounds silly, but bear with me. Backup the system disk, the configuration files and the backup settings. That way, if your backup server fails you can be up as soon as possible.

(Edit: sorry, about the other answer, I misread the question)


It absolutely makes sense to use RAID on your back server since you plan on storing the data on the server, and not tape.

I would recommend RAID 5 , 1 or 10.

Think about it this way, hard drives will fail. With the proper RAID setup you are protected against data loss when this occurs. You replace the failed hard drive and the rebuild the RAID.

With out RAID protection when you hard drive dies (at it will die at some point) then you have lost your backups.


This highly depends on what you think about 'backup'.

If the goal is just to have a server with "live" data duplicate from other servers on this server, then using raid on this backup server is almost useless has, if you lose it, data are still available on servers. In this case you just need to have some spare disk to be able to make the backup server back online in a short time if a disk fails.

If the goal is to archive backup in the time. I mean doing a backup daily, and keep it for a month, a year or so. Then yes, you want to use raid because if you lose a disk you will lose archive. If it's critical for you to be able to restore data from a X week ago backup, you may also backup this 'backup/archive' to another server or to tape (tape is very well for long time archiving) (and far away of course)


What are the odds of production server and backup server hard disk failing at the same time? If they are psychically separated (i.e. not on the same power grid, etc.) this chance is really, really low. So, I vote for no RAID.

Of course, make sure you have alerts when backup server is failing.

  • 1
    What if the drives in both the production and backup servers are from the same batch? The chances are increased greatly.
    – Lazlow
    Jul 14, 2009 at 20:07

I agree with what's been said already, but if you are using a raid with parity there's going to be a way of monitoring the health of the drives and your backup data. Most adaptors or onboard controllers will send warnings via syslog, windows events or email.

If this box is simply going to throw a windows event when SMART reports a failing drive then it's far too late.

Redoing the backups has to take longer (man hour cost) than a raid controller and a few extra SATA drives.



Backup to disk has value. While I am firmly on the tape side of the argument. I will say this however, if your backup volumes are single disks with no redundancy you will eventually lose all your data. Because your disk will eventually fail.

I suppose it depends on the nature of your need for backups as to whether backup to disk is really a suitable solution. If you don't need your data off site, and you don't care about disaster recovery, or survivability of your data over a long time then tape isn't necessary. I certainly have backups that never get off disk, and never leave the data center, but they are there to correct user deletion error.

Also how do you outgrow tape capacity? That's the beauty of tape, you can always get another tape. That does require that you have a tape changer of some sort though.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .