What Tom just suggested is what I would have suggested next as long as your data was intact.  Just be aware that once you do the New Config, you've lost any ability to actually do the rebuild UnRAID now wants to do.    I didn't suggest that off-the-bat for the following reason:

 

=> IF the data has NOT in fact been successfully recovered (which you'll know if you look at it on a Windows box) ... then there is some possibility that you could still recover it with a rebuild => IF the following sequence of events happens to be true:  (a)  When you booted with the wrong flash drive, the rebuild that wiped out disk1 (your old parity drive ... which was "parity" as far as the wrong flash drive was concerned) wiped out too much of the disk for a successful reiserfsck recovery (which you'll know if you look at the disk);  AND  (b)  When you then booted with the correct flash drive, the rebuild that started then was aborted (by you) quickly enough that only a small part of the valid parity information (on the correct parity drive) was destroyed.

 

IF that sequence is what happened, then if the data is NOT good on the disk now, you could let UnRAID rebuild the disk (which would correctly recover all of the contents of the disk except what is at the "front end" where parity was incorrectly "corrected" by the parity sync you aborted) ... and THEN you could repeat the reiserfsck process to see if it could recover the data then.

 

Basically, you've wiped out parts of two drives -- disk1 and the new 4TB parity.    The sequence I just outlined may help if you wiped out a lot more of disk1 than you did of the 4TB parity drive.

 

While the likelihood of this helping is probably small, if you still haven't recovered your key data [e.g. wife's pictures  ] it might just be worth trying.

Since Tom is suggesting seems to be for viewing purposes to see what's left, could razr not backup his current config and restore it later if it's found worthwhile so he doesn't eliminate his last hope of a drive recovery?

 

It's looking unlikely that things are recoverable, but likely a good idea just in case, no?

What Tom just suggested is what I would have suggested next as long as your data was intact.  Just be aware that once you do the New Config, you've lost any ability to actually do the rebuild UnRAID now wants to do.

Not true.

 

I didn't suggest that off-the-bat for the following reason:

 

=> IF the data has NOT in fact been successfully recovered (which you'll know if you look at it on a Windows box) ... then there is some possibility that you could still recover it with a rebuild => IF the following sequence of events happens to be true:  (a)  When you booted with the wrong flash drive, the rebuild that wiped out disk1 (your old parity drive ... which was "parity" as far as the wrong flash drive was concerned) wiped out too much of the disk for a successful reiserfsck recovery (which you'll know if you look at the disk);  AND  (b)  When you then booted with the correct flash drive, the rebuild that started then was aborted (by you) quickly enough that only a small part of the valid parity information (on the correct parity drive) was destroyed.

 

IF that sequence is what happened, then if the data is NOT good on the disk now, you could let UnRAID rebuild the disk (which would correctly recover all of the contents of the disk except what is at the "front end" where parity was incorrectly "corrected" by the parity sync you aborted) ... and THEN you could repeat the reiserfsck process to see if it could recover the data then.

He could still try this if his 4TB parity disk has not been assigned yet.

 

Basically, you've wiped out parts of two drives -- disk1 and the new 4TB parity.    The sequence I just outlined may help if you wiped out a lot more of disk1 than you did of the 4TB parity drive.

 

While the likelihood of this helping is probably small, if you still haven't recovered your key data [e.g. wife's pictures  ] it might just be worth trying.

 

The sequence I gave above preserves his 4TB parity if the actual recovered contents of disk1 are too f-upped to recover anything useful.

 

I guess one question to ask is, "razr: is there anything on disk1 you absolutely must recover?"  Maybe this was asked already.

Since Tom is suggesting seems to be for viewing purposes to see what's left, could razr not backup his current config and restore it later if it's found worthwhile so he doesn't eliminate his last hope of a drive recovery?

 

It's looking unlikely that things are recoverable, but likely a good idea just in case, no?

Easy to restore later if we have to.

I do not have much time now..until late tonight probably....

But it is a little late... I was waiting for a go, nobody was around and I did what bjp suggested

First..Tom is right...I stopped the array, assigned the disk as disk1..blue dot..I thought, if I start it it will start to rebuild parity again and we are back to square one. No way.

unassigned disk one again

I shut it down.

Physically removed cache disk..just in case

started the array in safe mode

I did as bjp suggested. Assigned disk one to cache....dont scream at me.....

Guess what......I would say almost 98% of the data was........................there.

Yes, everything was even almost organized. 

all the top folders renamed with the folders and files inside it intact.

There are many files without extension, probably unusable, but like I said, I do not have time today. I plugged an external HD to my pc and everything is being moved as we speak.

I am not home, i cannot stop it now, hopefully parity check is not happening, it was not when I left home.

I will keep you posted late tonight.

Thank you all

 

 

Whew! Drama, excitement, even a cliffhanger.  But in the end a happy ending!

 

Razr, suggest you go back and reread this entire thread when you have a breather to understand the solutions that were offered and the reasons why. It will make you better able to keep your data safe and avoid missteps. Feel free to ask questions and I'd be glad to try and help.

 

My only slight fear is ... is the mover going to run and try to copy data off the cache drive?

My only slight fear is ... is the mover going to run and try to copy data off the cache drive?

That's why I suggested he create a new config, leaving out the parity disk.

 

I have this command in my go file to disable the mover. I am assuming it hasn't changed.

 

Razr - suggest you run this when you can to stop the mover from trying to do anything.

 

echo ; >/usr/local/sbin/mover

I have this command in my go file to disable the mover. I am assuming it hasn't changed.

 

Razr - suggest you run this when you can to stop the mover from trying to do anything.

 

echo ; >/usr/local/sbin/mover

Why do you have that there?  One way to disable the mover is to go to Settings/Share settings and disable the cache disk.

 

Also - not good to have users place these kinds of hacks in the 'go' file.

I have this command in my go file to disable the mover. I am assuming it hasn't changed.

 

Razr - suggest you run this when you can to stop the mover from trying to do anything.

 

echo ; >/usr/local/sbin/mover

Why do you have that there?  One way to disable the mover is to go to Settings/Share settings and disable the cache disk.

 

Also - not good to have users place these kinds of hacks in the 'go' file.

 

I DO use a disk mounted in the cache disk slot, but don't use user shares or want files copied to the cache disk to make their way to the array. This has been in my go file for many many moons. Don't remember when it was suggested.

 

Should I remove it? Is there an alternative that is not a hack?

I definitely think it was a bit dangerous to assign the drive as cache.    Either moving it to another PC to look at;  or just doing a New Config as Tom suggested would seem a lot safer.  Especially since you can still do a rebuild if needed ... I hadn't thought about that, but as Tom noted, as long as the parity drive wasn't assigned, you could always do yet-another New Config with the "Trust Parity" option to restore that option (Tom -- I presume that's why how you could restore the option -- right?).

 

In fact, yet another way to check the contents would have been to take the old flash drive;  reformat it and create a new v5.0.5 system on it with NO configuration;  boot to it; and assign ONLY the drive in question as a data drive ... and then see what was on the drive.    Then you could shut down and switch back to the correct flash drive after you'd copied all of the recovered data from it.

 

In any event, it does seem like the end result has turned out okay, with most of the significant data recovered      I'm sure it's been 4 stressful days ... but all seems to have turned out okay.

 

 

This is great but we are encouraging people to keep backups of their USB disks. We need to be clearer.

 

Certainly true that backups need to be CURRENT.  I actually don't recommend maintaining a backup flash drive -- I DO recommend having a spare flash drive with a key for it; but as for the actual UnRAID files, etc., I suggest simply copying the current flash drive contents to a folder on your PC at regular intervals (Mine is done automatically via a backup script on my PC).  Then, if you need to use the backup flash drive, copy everything (except the key file) from your backup folder on the PC to the flash drive ... and THEN boot to it.

 

This is NOT a good technique.

 

If you copy the super.dat file to your backup when the array is active, and later restore it and try to start the array, your system will initiate a correcting parity check.

 

I definitely think it was a bit dangerous to assign the drive as cache.

 

The danger was minimal even if the mover kicked off.

 

With my advice I did say ...

 

"Make sure you are in maintenance mode and that the mover script is not going to try to do anything with the files on the disk."

 

I assume maintenance mode disables the mover. Is that not true?

This is great but we are encouraging people to keep backups of their USB disks. We need to be clearer.

 

Certainly true that backups need to be CURRENT.  I actually don't recommend maintaining a backup flash drive -- I DO recommend having a spare flash drive with a key for it; but as for the actual UnRAID files, etc., I suggest simply copying the current flash drive contents to a folder on your PC at regular intervals (Mine is done automatically via a backup script on my PC).  Then, if you need to use the backup flash drive, copy everything (except the key file) from your backup folder on the PC to the flash drive ... and THEN boot to it.

 

This is NOT a good technique.

 

If you copy the super.dat file to your backup when the array is active, and later restore it and try to start the array, your system will initiate a correcting parity check.

 

I definitely think it was a bit dangerous to assign the drive as cache.

 

The danger was minimal even if the mover kicked off.

 

With my advice I did say ...

 

"Make sure you are in maintenance mode and that the mover script is not going to try to do anything with the files on the disk."

 

I assume maintenance mode disables the mover. Is that not true?

 

I am not home...just following the thread from outside.. (I have become a little addicted) I cannot comment in tapatalk from cell ...do not know how..I can read though...

And that is what I thought..... If I start in save mode...mover, which I suppose is a plugin should not work..

Besides, Mover kicks in after 3:00 AM...I got back home before that and the transfer was already finished.

I haven't had time to check the files or work on unraid again..like I said, I am not home now until late tonight.

 

MOving on to the next chapter.....

I am afraid of formatting disk1, re-assign everything back to normal, start the array, Parity drive has error.....parity starts....messes up the data on Disk2 and Disk 3..Big mess again. 

 

What would be the best procedure?

As of now all the data from DIsk one is on an external HD, but how about data from disks 2 and 3???

Please advise....

At the end of all this, BBQ in my house for all  IT is sunny and hot down here in Florida

Suggest you leave your array alone for now. Stop the array, shutdown the server, leave it powered off.

 

Explore the data on your external drive. You said you had a large percentage and it looked good. Make sure that you feel satisfied and confident. There is one other recovery mode you could attempt that might bring back more data. 5% chance. Not good odds but if little Suzy's first ballet recital is missing with no backup, 5% is better than 0%. We could try it.

 

Once you are confident, reread the thread. Understand why I suggested disconnecting disk1. Why it might have worked. Why it didn't work. Why putting the original disk back in slot1 after the recovery, and starting the array with the blue ball, would have been a big mistake. Until you have a better understanding of parity and how unRaid works, I am nervous telling you to do this and do that. Until you understand it better I fear you'll make another misstep even after we get Humpty Dumpty back together again.

 

But for now, enjoy your BBQ, check your recovered data, and thank your lucky stars. When you've calmed down, review this thread, answer my questions in the paragraph above, ask a few questions, and then we'll get things put back together.

To clear up a couple of misconceptions in OPs most recent. Mover is not a plugin. It is integral to the whole point of having a cache drive. As far as I know safe mode will not stop mover from running. You can adjust its schedule at Settings - Share Settings - Mover Settings.

 

Also, normally, a correcting parity check will not write to any drive but parity. A non-correcting parity check will not write to any drive, not even parity.

 

Where you got into trouble was starting from an old configuration that had an unclean shutdown, which automatically triggered a correcting parity check, and had your current disk1 as the parity drive. So it did a correcting parity check on disk1, corrupting its data.

To clear up a couple of misconceptions in OPs most recent. Mover is not a plugin. It is integral to the whole point of having a cache drive. As far as I know safe mode will not stop mover from running. You can adjust its schedule at Settings - Share Settings - Mover Settings.

 

Also, normally, a correcting parity check will not write to any drive but parity. A non-correcting parity check will not write to any drive, not even parity.

 

Where you got into trouble was starting from an old configuration that had an unclean shutdown, which automatically triggered a correcting parity check, and had your current disk1 as the parity drive. So it did a correcting parity check on disk1, corrupting its data.

 

Agreed, but have one question:

 

You say that safe mode does not disable the mover.  Does maintenance mode disable it?"

Agreed, but have one question:

 

You say that safe mode does not disable the mover.  Does maintenance mode disable it?"

I have never been in safe mode or maintenance mode when mover would have run so I have no direct experience. I wasn't around when maintenance mode was invented so am not aware of any of those discussions. I was around when safe mode was introduced and as far as I'm aware it was never mentioned that mover would be disabled in safe mode. Safe mode was introduced in v5 betas to skip the loading of plugins on boot and so eliminate any potential third party code problems.

I am afraid of formatting disk1, re-assign everything back to normal, start the array, Parity drive has error.....parity starts....messes up the data on Disk2 and Disk 3..Big mess again. 

 

If a parity check "kicks in", it won't harm any data on your other drives.  What WOULD mess things up big-time is if UnRAID did a rebuild of the WRONG disk ... your last post indicated it said that if you Started the array it was going to do a rebuild, but it wasn't clear which disk it wanted to do that on (You indicated disk1's status was shown as good).

 

The safest thing to do is to just do a New Config WITHOUT assigning a parity drive (as Tom noted earlier) ... then look at each of the data drives and confirm all of the contents look good;  and then Stop the array, assign parity, and restart it to do the initial parity sync.

 

Edit:  The SAFEST thing, of course, is to maintain BACKUPS of your data.  As you've clearly learned here, UnRAID is NOT a backup.  It's simply a fault-tolerant server, which allows you to retain access to your data in the event of a drive failure.  But clearly that provides NO protection against system failures ... and booting to the WRONG OS (which is essentially what you did) can easily "clobber" your data.    You were able to recover only because you STOPPED the automated parity checks quickly enough that not too much data was lost ... a fortunate (some might say lucky) bit of timing.  In this case, you were able to stop what happened because it wasn't a hardware failure ...but there are plenty of hardware issues that could cause a couple of drives to fail simultaneously -- and if that happens, anything not backed up will simply be GONE.

 

 

I am afraid of formatting disk1, re-assign everything back to normal, start the array, Parity drive has error.....parity starts....messes up the data on Disk2 and Disk 3..Big mess again. 

 

If a parity check "kicks in", it won't harm any data on your other drives.  What WOULD mess things up big-time is if UnRAID did a rebuild of the WRONG disk ... your last post indicated it said that if you Started the array it was going to do a rebuild, but it wasn't clear which disk it wanted to do that on (You indicated disk1's status was shown as good).

 

The safest thing to do is to just do a New Config WITHOUT assigning a parity drive (as Tom noted earlier) ... then look at each of the data drives and confirm all of the contents look good;  and then Stop the array, assign parity, and restart it to do the initial parity sync.

 

BUT doing this would remove the chance to do the additional error recovery step I mentioned. See, he could run reiserfsck on the simulated disk1 at this point. If it was less corrupted than the physical disk, additional recovery would be possible. Do a new config and that option gets a lot harder. Do a parity build and it is lost.

 

I suggest he follows my instructions.

No need for reiserfsck on the simulated disk -- his data is already fine on disk1.    The concern he mentioned above is any possibility of corrupted the other disks.    The only way that would happen at this point (barring a physical failure) is if UnRAID started rebuilding one of them based on the current BAD parity info.

 

Easiest way to be certain that's avoided is to do a New Config.  Initially without parity (as Tom suggested earlier) ... but after confirming the data looks fine, then I'd add the parity disk and get the system back into a fault-tolerant mode.

 

Doing a new config is not a drastic as it once was. The system allows the new config to use the existing parity drive by checking a box. Rebuilding a data disk after setting a new config that includes a working parity drive is done using the command line. It would be nice if this was available in the GUI rather than the CLI.

Doing a new config is not a drastic as it once was. The system allows the new config to use the existing parity drive by checking a box. Rebuilding a data disk after setting a new config that includes a working parity drive is done using the command line. It would be nice if this was available in the GUI rather than the CLI.

 

Right now he has his simulated disk available. He also has a backup of his photos on a physical disk. I'd suggest we leave it there for now, and shutdown the array to avoid other issues.

 

Tom has indicated problems on his disk2. I am not particularly excited about running parity checks, builds, or any other full disk operations right now.

 

Please let he and his wife look at their kids pictures for the past 10 years on the external and agree they look good before tying to take additional steps with the array. A shutdown array is a good place to be right now IMO.

 

I am not disagreeing with anyone here, but suggest we keep chatting in this thread to a minimum to let Razr get through this without overwhelming him.

One thing that maybe needs to be addressed if its not too late is shutting down safely. We have already seen a couple of instances of automatic correcting parity checks happening here. Does OP know that you must stop the array before shutting down?

 

It might also be worthwhile to go into Settings - Disk Settings and set Enable auto start to No.

 

P. S. if OP has already shutdown, safely or otherwise, he could manually edit disk.cfg to disable auto start.

 

One thing that maybe needs to be addressed if its not too late is shutting down safely. We have already seen a couple of instances of automatic correcting parity checks happening here. Does OP know that you must stop the array before shutting down?

 

It might also be worthwhile to go into Settings - Disk Settings and set Enable auto start to No.

 

I did tell him to shutdown the array, so hopefully he will do that (Stop button after checking the little "Yes I want to do this" checkbox).

 

I like the suggestion to turn off auto-starting of the array.

 

As trurl says, Razr, from the unRAID GUI, click Settings - Disk Settings and set auto start to No. Make sure you hit Apply. But if you've already stopped the array and powered down, don't reboot to do this.

 

 

 

One thing that maybe needs to be addressed if its not too late is shutting down safely. We have already seen a couple of instances of automatic correcting parity checks happening here. Does OP know that you must stop the array before shutting down?

 

It might also be worthwhile to go into Settings - Disk Settings and set Enable auto start to No.

 

P. S. if OP has already shutdown, safely or otherwise, he could manually edit disk.cfg to disable auto start.

 

Well, in regards to "safely shutdown".

I think that if the array is not stopped first, the shutdown or reboot buttons are greyed-out, so it is impossible to shut down without stopping it.

But giving it some thought...."the array must be stopped first" I used "shutdown -h now" to shutdown the array when it was invisible in my network...taken from http://lime-technology.com/wiki/index.php?title=Configuration_Tutorial#Setting_a_static_IP_address

I do not think that command will stop it and then shut it down....therefore, not a safe shutdown. Am I right?

 

I am not ready yet to start with PHASE 3. I am still traumatized  lol