Occasionally, I hear things that surprise me. And one of the statements that I’ve heard lately that fits into that category is that if your database files are on a RAID volume that you don’t need backups.
Well, we hopefully all know what RAID stands for – Redundant array of independent / inexpensive disks – take your pick on what word you use for the “I”
It appears to me that a few people seem to be under the impression that the words “Redundant” and “Backup” mean pretty much the same thing – lets be clear here, they are most defiantly different.
Like most hardware that has redundancy built in, you can afford to lose one piece and still keep functioning. Lets be clear here again, if we lose one piece of hardware and still keep functioning, at least two things may happen,
- Performance may suffer.
- The server has immediately become more vulnerable because we may not have any further redundancy (while we might still have further redundancy,it has defiantly been reduced / compromised.)
SQL Server provides components that can be used for redundancy as well, such as mirroring and replication and also RAID will give us a few additional benefits such as read \ write speeds – depending on the configuration.
The components that provide redundancy give us no facility to “Step back in time” – that’s what our backups are for.
Take the following senario’s
- We loose all our redundancy and then have a server crash.
- A user deletes data and we need to get it back (or worse, the DBA deletes something they should not have!)
- Your server disappears for some reason – perhaps it’s been physically taken or involved in some sort of natural disaster.
If you only have RAID implemented in the above scenarios then you’ll find yourself doing a little bit of explaining.
If you have backups (that should be tested regularly) then at least you can recover, you might have downtime – but you can recover.
So in summary, we can see that RAID volumes and backups complement each other and that one is not a replacement for the other.
Have a good day.