I'm not sure I completely understand what happened, but it is important to understand your options in CTRL-R (if you didn't go here, that is a problem) and what to do with foreign configurations (when to import and when to clear).
It sound like you simply pulled two HDD that had 4 Virtual Disks define on them (one VD containing your OS).
It's worth noting that when defining a Virual Disk (array as you call it), configuration data is written to the HDD's that contain the VD you have created. As such, when moving these HDD to another PE server, the PERC in the other server will recognose that a VD (or VD's) exist on these HDD and offer you the option to import the VD (or VD's). The PERC also provides the option to clear configuration data from the HDD's you have inserted in which case the VD configuration data is wiped.
Now i'm not clear on what if any configuration data the PERC itself stores but i'm guessing it remembers the HDD's that are/were stored within the server so when reinserting HDD, you may not need to import the VD as such. I guess that's how disk roaming is handled but i've not looked into the details so i'm not sure. And there is also cache data that can be stored on the PERC and may need to be handled before simply pulling HDD from the server, otherwise you may get some data corruption. Real server RAID is not like the software raid on a client OS that i'm used to :emotion-4:
So, as you insert two new SSD's into a diskless PE server, there would be no configuration data contained on these new SSD's and as such no VD's will show up :emotion-3:.
Note that the PERC may have some data about the previous HDD's and/or some cache data related to the previous VD's but no VD's should show up.
Luckily your old VD('s) and all data contained within are still available on your old HDD that may be sitting on your desk (unless you have previously removed the configuration data or wiped each HDD clean on another system).
Reinserting these old HDD into your Dell server would either have PERC recognise they belong or give you the option to import the VD's and again get access to your data... but this is not RAID recovery as such so it's wrong to look at it as such. I guess it's more correctly defined as physical disk and/or virtual disk management !
Raid recovery is a much much more complex and expensive action when compare to a single HDD partition based data recovery action :emotion-7:
The real question of how you migrate an OS and data from one/many VD/VD's on a HDD based array to another VD/VD's on another SSD based array is not something i've played around with on a server. However, i'd always start with a backup and then test the backup recovery process works just to be sure.
Then i'd read the Dell PERC user guide to familiarize yourself with thyour PERC capabilities :emotion-5:
Oh, and moving a client OS from one partition on a HDD to another partition on a SSD is not recomended since the OS install makes certain configurations when installing to HDD as compared to installing to SSD. As such, using partition copy techniques may result in sub optimal performance.
I'm not sure if the same issues would occur if using partition copy techniques to migrate a server OS from HDD based VD to SSD based VD but i'g guess PERC drivers would provide some level of abstraction so it might be OK. But i'd not want to play with 'might' on a production server.
I'm sure others will have much more to say on the miutiae of RAID management and HDD to SSD migration.
Not 4 VD on 2 HDD -- it was 4 VD on 8 HDD (1 VD = 2 Disks in RAID 1),
I realized my mistake as soon as I plugged in 2 new drives and things went haywire.. However it was 2 am on a long weekend, and the server was not being used so I just went ahead with what I did...
Had it been a production, I'd be out of a job probably... I know not to do this again!!!
."However it was 2 am on a long weekend, and the server was not being used so I just went ahead with what I did..."
Been doing raids since 1991 . Never lost a raid due to my impulsiveness but 2-5 am is the most dangerous time to be working on a raid, if you have been up all day. Twice I nearly lost raids in that time of the morning. One of those raids took me 2 hour to recover, the other took me 5 hours.
"so I just went ahead with what I did..."
That where the danger lies, your just too tired to stop yourself from hitting the enter key. Lesson learned
theflash1932
9 Legend
•
16.3K Posts
0
January 17th, 2017 12:00
I'm not sure I completely understand what happened, but it is important to understand your options in CTRL-R (if you didn't go here, that is a problem) and what to do with foreign configurations (when to import and when to clear).
skylarking
2 Intern
•
548 Posts
0
January 17th, 2017 21:00
It sound like you simply pulled two HDD that had 4 Virtual Disks define on them (one VD containing your OS).
It's worth noting that when defining a Virual Disk (array as you call it), configuration data is written to the HDD's that contain the VD you have created. As such, when moving these HDD to another PE server, the PERC in the other server will recognose that a VD (or VD's) exist on these HDD and offer you the option to import the VD (or VD's). The PERC also provides the option to clear configuration data from the HDD's you have inserted in which case the VD configuration data is wiped.
Now i'm not clear on what if any configuration data the PERC itself stores but i'm guessing it remembers the HDD's that are/were stored within the server so when reinserting HDD, you may not need to import the VD as such. I guess that's how disk roaming is handled but i've not looked into the details so i'm not sure. And there is also cache data that can be stored on the PERC and may need to be handled before simply pulling HDD from the server, otherwise you may get some data corruption. Real server RAID is not like the software raid on a client OS that i'm used to :emotion-4:
So, as you insert two new SSD's into a diskless PE server, there would be no configuration data contained on these new SSD's and as such no VD's will show up :emotion-3:.
Note that the PERC may have some data about the previous HDD's and/or some cache data related to the previous VD's but no VD's should show up.
Luckily your old VD('s) and all data contained within are still available on your old HDD that may be sitting on your desk (unless you have previously removed the configuration data or wiped each HDD clean on another system).
Reinserting these old HDD into your Dell server would either have PERC recognise they belong or give you the option to import the VD's and again get access to your data... but this is not RAID recovery as such so it's wrong to look at it as such. I guess it's more correctly defined as physical disk and/or virtual disk management !
Raid recovery is a much much more complex and expensive action when compare to a single HDD partition based data recovery action :emotion-7:
The real question of how you migrate an OS and data from one/many VD/VD's on a HDD based array to another VD/VD's on another SSD based array is not something i've played around with on a server. However, i'd always start with a backup and then test the backup recovery process works just to be sure.
Then i'd read the Dell PERC user guide to familiarize yourself with thyour PERC capabilities :emotion-5:
Oh, and moving a client OS from one partition on a HDD to another partition on a SSD is not recomended since the OS install makes certain configurations when installing to HDD as compared to installing to SSD. As such, using partition copy techniques may result in sub optimal performance.
I'm not sure if the same issues would occur if using partition copy techniques to migrate a server OS from HDD based VD to SSD based VD but i'g guess PERC drivers would provide some level of abstraction so it might be OK. But i'd not want to play with 'might' on a production server.
I'm sure others will have much more to say on the miutiae of RAID management and HDD to SSD migration.
Chirag11
1 Rookie
•
32 Posts
0
January 18th, 2017 15:00
SKYLARKING -
Not 4 VD on 2 HDD -- it was 4 VD on 8 HDD (1 VD = 2 Disks in RAID 1),
I realized my mistake as soon as I plugged in 2 new drives and things went haywire.. However it was 2 am on a long weekend, and the server was not being used so I just went ahead with what I did...
Had it been a production, I'd be out of a job probably... I know not to do this again!!!
Lessons learned!
pcmeiners
4 Operator
•
1.8K Posts
0
January 19th, 2017 16:00
."However it was 2 am on a long weekend, and the server was not being used so I just went ahead with what I did..."
Been doing raids since 1991 . Never lost a raid due to my impulsiveness but 2-5 am is the most dangerous time to be working on a raid, if you have been up all day. Twice I nearly lost raids in that time of the morning. One of those raids took me 2 hour to recover, the other took me 5 hours.
"so I just went ahead with what I did..."
That where the danger lies, your just too tired to stop yourself from hitting the enter key. Lesson learned
Chirag11
1 Rookie
•
32 Posts
0
January 20th, 2017 09:00
Couldn't agree more with you!!!