Windows Server software RAID volume constant "Failed Redundancy"

Question

I'm using Windows Server 2008 software RAID volumes. So, recently I've started to receive error in System event log: "The device, \Device\Harddisk7\DR7, has a bad block."

Meanwhile volume in Disk Manager is marked as "Failed Redundancy". I could command to "Reactivate Volume" and it's starts to re-sync, but after a while it stops and returns to previous state.

chkdsk on failed disk do not help. What can I do besides removing, reformatting and restoring from backup? Thank you.

Update When I just offline one of the disks (#7 for instance), "Failed Redundancy" label mutates to "Failed", so removing disk and replacing it with empty one, I thing will not save the volume.

Solution 1

I'd like to summarize my experience here.

When Windows Server (actual for 2008 R2) software RAID5 array is in "Resyncing" state it is as vulnerable to disk failure as striped volume. So you have two options:

• do not use Windows software RAID5,
• do not permit it to enter "Resyncing" state (e.g. use UPS).

Again. If one of volume drives fail during resyncing you are pretty much screwed up. All you could do is create volume again, run chkdsk on it and restore data from backup.

Solution 2

You need to replace the drive with the bad block. Each time you try reconstruct the array if will fail once it hits that block.

You should not need to fully reformat though - you should be able to remove the failed drive, replace it, partition it as needed and rebuild the array (unless, of course, the array is RAID0 rather than RAID1, RAID5 or similar).

I've not done any of the above with Windows' software RAID, so someone else will have to help you there if the place to issue the relevant commands are not obvious. To help them help you, it would be a good idea to add your current disk layout in your question.

Comments

[Erik Nijland]

agreed, if it is RAID 1 or higher just remove the disk from the server and get a warranty replacement or destroy the drive depending on your data destruction policy.

[Spence]

This is probably also a great time to double-check that your backups are running properly. You do test restores, right?

[Axel]

+1 for testing backups. Too many people don't bother at all (until too late to do anything about it if there is a problem).

[Artem Tikhomirov]

This is volume I back up to. So I'd like to save it, but if that really needed I'll just destroy it.

[Spence]

Backup isn't backup unless it's off-site and offline.