News:

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

Main Menu

Weird and need help, LS-WTGL/R1

Started by knightrec, November 05, 2012, 05:39:02 PM

Previous topic - Next topic

knightrec

I am in a total state of confusion here and looking for help. Sorry as I know similar questions have been asked but I have never found any that explain all of these or enough to put all of these together into a solution so sorry if this has been asked and solved, I just can't find the solution here.
Because I store absolute tons of data for myself and client's here is my setup:

Two: LinkStation Pro Duo LS-WTGL/R1 Firmware 3.10 (Drives U and X)
Four Seagate 2TB Desktop expansion units, two on each Duo (Drives V, W, Y, Z) all are formatted XFS

Everything is redundant and mirrored so
U has drives V and W
X has drives Y and Z
(Still with me or fall asleep yet?)

More Mapping:
Original U mirrored to Y
Original X mirrored to W
Original Z mirrored to V
Essentially data on one box goes to the other in case of HD failure.

About a week ago W disappears off the face of the earth and the Duo says it's in a "disconnected" state so because of that it can't format it. I can't check it. It no longer exists as far as the Duo is concerned.
Even though it is "disconnected" I properly un-mounted and disconnected the drive then connected it locally.
SeaTools says it's fine. UFS Explorer says it's fine and in tact.
Maybe the USB connection is gone or going? NOPE. Plug another drive in and it is seen immediately. (Seagate, WD and Samsung but all MUCH smaller in size)
I've restarted. Turned off and back on. Forced the firmware back on the Duo.
If drive W is connected to Duo U it can't be seen.

Unless someone has an outstanding suggestion here, I will blow away data on at least one drive, unformat it completely and see if it can be read. If not I will format it locally and see if it can be seen.
Why would I get a constant "disconnected" state from one drive from one Duo and what do I do to have it seen again?

Regardless there will be no loss of data. I'm looking for a reason why this may have happened and how to prevent it in the future as I have set up 4 clients with this exact configuration.


knightrec

SOLVED but no idea how
I'm not sure which one of my attempts actually fixed this issue but am leaning toward plugging in a known working drive then switching back.
As I was about to pull my hair out I gave her one more try and POOF it came back like there was never a problem.

Years ago I had the original Tera Station and had a similar problem.
I may be wrong but it almost seems like the devices "mark" a drive bad and to keep plugging / unplugging the same drive over and over never helps. As soon as I plugged in a completely different known working drive then went back to the one that appeared "Disconnected" it came right back. It's almost like the device saw the original one as bad for whatever reason and held onto that opinion. Different drive "Ok the bad one is gone heres the details on this drive" Put it back "OH a different drive again. OK"

For any that have a similar issue keep a few things in mind:
I tested the disconnected drive with a direct connection so I knew the drive and data was fine HOWEVER, if you find yourself in a similar situation with a drive that once worked at least try another known working drive then swap back and see if it comes back again.

I am sooo happy I don't have to erase and mirror that drive all over again!
Redundancy is key folks but if built by man it can and will break eventually.


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: 127 (show)
Files included: 35 - 1354KB. (show)
Memory used: 928KB.
Tokens: post-login.
Queries used: 16.

[Show Queries]