RAID 1 Recovery

SCS

Distinguished
Jul 12, 2011
23
0
18,510
In my office, we have a Buffalo LinkStation Duo with two 2TB drives set up as RAID 1. We're a design firm and all files are saved directly to the NAS where they can be accessed and edited by any employee. We have frequent power failures in our building, and three times in the past year or so, the Linkstation (this one and a previous one) has shown an error (E14: The RAID array cannot be mounted) when recovering from a power failure.

Every time this happens, our network guy (from an outside company) takes the whole linkstation away for two or three days, and ONCE we got all of our data back. The other two times, there were huge holes in the data. All files were there, but many showed 0 file size and could not be opened. Obviously this has happened again (last Thursday) and we are supposed to get our stuff back today - hopefully with files intact.

Perhaps I don't understand RAID correctly, but what is going on here that would cause catastrophic failure from a power outage (the LinkStation is plugged into a new Tripp-Lite "Inernet Office UPS") AND make it that difficult to recover data when it is supposedly mirrored on both disks? That was the whole selling point for this system - If a drive fails, swap it out and be up and running. As a semi-literate computer guy who has a home network on a NAS backup (although a single disk without RAID), this just doesn't add up for me. Do we need a new network guy, a different storage/backup solution or is there something I just don't understand? Thanks in advance.
 
Solution
As you probably know, RAID isn't a backup solution in any way - it's an uptime solution.

As someone who managed to lose their data on a RAID 1 (nothing vital luckily), I will say that it can happen, despite the data being 'written to both disks in the RAID 1).

What you probably need to realize is that RAID 1 adds an additional layer of complexity to writing data - whether it's a hardware RAID card (much better) or a software/firmware type of RAID (as in motherboard-driven usually), RAID itself is a processing step - it writes the data, depending on the protocol, either to both drives at the same time, or to one drive, then the other sequentially.

In any event, the RAID itself essentially adds meta-data to the unit of drives in the...

commissarmo

Distinguished
Jan 5, 2010
179
0
18,690
As you probably know, RAID isn't a backup solution in any way - it's an uptime solution.

As someone who managed to lose their data on a RAID 1 (nothing vital luckily), I will say that it can happen, despite the data being 'written to both disks in the RAID 1).

What you probably need to realize is that RAID 1 adds an additional layer of complexity to writing data - whether it's a hardware RAID card (much better) or a software/firmware type of RAID (as in motherboard-driven usually), RAID itself is a processing step - it writes the data, depending on the protocol, either to both drives at the same time, or to one drive, then the other sequentially.

In any event, the RAID itself essentially adds meta-data to the unit of drives in the RAID group - that is to say, a RAID 1 is NOT the same thing as having a single drive copied verbatim to another one (as would be the case say, if you used a backup software solution to copy one drive to the other).

A RAID rather, stores information about the RAID architecture (where the data is mapped to on both drives) ON one (or both I'm not sure about this) of the RAID member disks.

In principle, this shouldn't prove problematic, since if a drive 'dies' the RAID controller will simply read the other drive, and can reconstruct the array when you supply a new HDD (or new raid controller, or fix whatever caused the RAID to degrade).

In practice, this also works, but is subject to some vulnerabilities. I still don't know what precisely befell my RAID 1 drives, but in the end, the file systems on both drives were apparently corrupted, and despite using recovery software, RAID rebuilders, etc., I was unable to retrieve the data on EITHER of the 2 RAID 1 disks; it was lost (I had backups of it, but they were a bit dated).

Because of this, I currently use Google's preferred method of redundancy in data, which is essentially to use SOFTWARE to write data to 3 identical but independent disks, so no RAID. These are essentially backups, and don't provide the various usually server-specific desirable chars of RAID, but I prefer this system since seeing a RAID 1, supposedly robust in the face of failure, produce data loss.

Also of note, is if you're using RAID on an OS volume, you run into additional problems, because the OS writes an MasterBootRecord preface-like bit of code to the HDD it's installed on. This can often produce a problem when it's written by a RAID controller - since to my knowledge, in RAID 1, it is NOT written to both drives, or if it is, and one drive dies, you still cannot immediately BOOT the other RAID 1 volume on its own. You would have to reconstruct the RAID, but whether that reconstructs into a bootable volume, I'm not sure, and have never bothered to find out for reasons aforementioned.
 
Solution