Tim wrote:
Paul wrote in news
How about this one.
Apparently uses Disk Management window.
https://technet.microsoft.com/en-us/.../ff601861.aspx
Paul
I had looked at that before. None of the four situations apply to my
drives. I did to a 'resyncronize' just now and it failed.
I have another 2tb drive I bought to replace an older drive that failed,
that I haven't installed yet. I was thinking install that drive. Initialize
it GPT like the other two, and see if I can add it to the mirror. If that
works I can remove one of the other drives from the mirror, reinit it, and
add it back to the mirror. That will give me two good drives again in a
RAID 1, and I can reinit the last one and use it to replace the other
failed drive.
If that doesn't work, I will back up the RAID drive to the new disk,
totally destroy the existing raid, and create a new one.
Are either of these to ideas feasible?
You will back up the RAID drive *period*. End of story.
Running a RAID mirror, is not a backup. A backup is
data you place on a third drive. Once the 2TB of data
is on the third drive, now you have a measure of
redundancy you can actually use.
What you do after that, is a carefree experiment. Put
the data some place safe.
Always have *a couple* drives handy for recovery work. *Always*.
Never go into a crisis, half equipped. Make sure the data
is safe first. Then you can make a new drive GPT, and
make it a member of the array, and rebuild (resync).
And see if from a status point of view, it returns
to normal.
I am not a great fan of RAID, because it requires that
the user learn how to use it, in advance. You should
simulate failures as best you can, when setting up the
RAID array. I've done that a couple times as part of
trying to help people with RAID problems. Trying to
wing it later, is inevitable, and you can't test every
possible scenario, but I find you can do enough tests
to get a feeling for what the failures look like, and
what works. Just unplugging a SATA drive, or starting
the machine with one SATA drive connected during boot,
is enough to give a Failed Redundancy message. Doing the
resynchronize at that point, the good drive (whose status
logs what happened) will resync to the "out of sync" one.
To accelerate testing, I've used an HPA to "clip" the capacity
of a drive, so filling the disk is a lot faster. Putting
2TB of data on a 2TB drive would be boring. I clipped
down some drives to 4GB and 6GB, and used those for
some experiments before unclipping them again. HPA
is Host Protected Area. My SATA ports cannot be used
for this (BIOS security feature prevents it). My
JMicron IDE port, with an IDE to SATA adapter on
the end of it, works just fine for defining an HPA.
Once an HPA is set, I can make "tiny" hard drives
for quicker SATA RAID test cases. You can only
execute one HPA command per boot session, and it
takes a lot of reboots to do stuff. The HPA commands
are trap doored. Only one command per session, on
my Jmicron. On the Intel SATA ports, Intel burned up
the single command, such that a user cannot issue
any such commands. The purpose of making the drive
small, is so when the RAID software checks the drive
capacity, it sees a 6GB drive, not a 2TB drive,
as I've clipped off most of the top of the drive
with the HPA. The capacity reads as 6GB when the
software/OS checks it.
After a RAID experiment, I connect the SATA drive
to an older computer, and use diskpart to "clean all".
For hardware RAID, clean all won't clean all of the
disk. You have to arrange things, in the case of
hardware RAID, so the RAID metadata areas are exposed,
so you can erase them. Even erasing from Linux is
not foolproof, as sometimes Linux tries to read
the metadata and make it work as it did in Windows.
When I work with a drive, the drive must be
completely clean, as I have had cases where a
later experiment is ruined, because the test
case can "sniff" the metadata from a previous
experiment.
Paul