News:

RAID is not a replacement for a backup! Here's why.

Main Menu

RAID won't mount, array status normal

Started by MacDaddyOh, January 04, 2013, 10:57:27 AM

Previous topic - Next topic

MacDaddyOh

After a routine maintenance on my Linkstation Pro Duo LS-WXL, one disk moved to a status of error, and the RAID 1 array status moved to degraded.  My problem is that after the steps I took below, both disks are now back to Array 1 status (web browser -> system -> storage -> disks) and the array status is listed as normal (web browser -> system -> storage -> RAID array), but storage is not available and NasNav2 shows the E14 error (raid cannot be mounted).
I'm searching for an option in which I do not rebuild the array, because I am now concerned about how to restore the data.

The steps I performed after I the original error status are:

1.  After a shut down, I removed the disk (we'll call it disk B, originally-provided 2TB seagate, XFS format), and replaced it with another HDD (we'll call it disk C, a 2TB Hitachi), formatted FAT.  After reading other posts, I now realize it should have been in a "raw" state.

2. I rebuilt the array as RAID 1 from the "good" disk, (we'll call it disk A, originally-provided 2TB seagate, XFS format) and Disk A and C's status moved to array 1 and the array 1 status listed as normal.  However, the array did not mount.  So I restarted the LS (web browser -> system -> maintenance -> Restart) with no effect.  Thinking that I may have mistakenly re-established the RAID from the blank disk C, I shut down the linkstation and removed drive C.

3. I booted a mac with ubuntu 10.4 running from a live CD to determine what had occurred. ( I used 10.4 because I had good documentation and could not get 12 to run from a CD) I installed mdadm (Terminal -> sudo apt-get install mdadm --no-install-recommends), mounted drive C with the "pseudo"-array (sudo mdadm --assemble /dev/md0 /dev/sdX6) and discovered (Places -> 2TB filesystem) that --assumedly-- all the data had copied to Drive C.

4. Thinking that maybe the LS-WXL was being finicky about the fact the drive was originally FAT (and/or not seagate), and now possessing a more up to date backup than before the array degraded, I put disk B back into the LS (still with disk A), and rebuilt the array.

After that array rebuild also failed to mount, and no change after a restart,  I have come here.   The option to attempt a second rebuild with disks A and B is unavailable (status listed as normal) so the only choice I have is to rebuild the array.  I hope to avoid that, since all the data  will be lost, and transferring the information from the third HDD is, well, not straightforward (I can't directly copy it from the USB port on the back of the LS, and swapping drives to mirror the data appears to not work).  

The manual explains how to move a drive from RAID to normal (page 96), but implies that the data would be lost at that point also. Is it possible to remove the RAID partitions (1-5) in ubuntu and restore at least one drive to normal status without affecting the data partition (6)?  At least that would give me a working XFS format drive in the LS to move data more easily to HFS (journaled), and then consider my options from there.  Or, can I attempt an array rebuild in ubuntu, that the LS would recognize?  Or, does anyone have a set of instructions on how to move an XFS partition to a (permissions intact) HFS (journaled) drive ?

Thank you for your time in advance.


MacDaddyOh

I apologize, in the second to last paragraph I meant to say, "the only choice I have is to delete the array" not what I wrote: "the only choice I have is to rebuild the array."


Browser ID: smf (is_webkit)
Templates: 4: index (default), Display (default), GenericControls (default), GenericControls (default).
Sub templates: 6: init, html_above, body_above, main, body_below, html_below.
Language files: 5: index+Modifications.english (default), Post.english (default), Editor.english (default), Drafts.english (default), StopForumSpam.english (default).
Style sheets: 4: index.css, attachments.css, jquery.sceditor.css, responsive.css.
Hooks called: 126 (show)
Files included: 35 - 1354KB. (show)
Memory used: 935KB.
Tokens: post-login.
Queries used: 16.

[Show Queries]