• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Replacing all Disks in a RAID array

USF-Nealio

Limp Gawd
Joined
Jan 18, 2012
Messages
373
One of my SQL servers at work has run out of disk space, and we are at the limit of the chassis to hold any extra disks. The Array is a 6 disk RAID 10 on an HP P410i. All 6 disks are currently 120GB SATA SSDs, and my supervisor has purchased 6x 450GB SAS platter drives as replacements. Typical I'd backup the data, and replace 1 disk at a time, allowing the array to rebuild in between, but something tells me that isn't going to work this time around.

Thoughts and ideas as to how I should approach this. I'd prefer to not have an interruption of service, but I understand if it's necessary.
 
No mention of enclosure.
  • Source a new enclosure and install new drives and old, otherwise mount them either permanently or temporary style.
  • You may need the use of an expander to supply enough ports if you haven't got one already.
  • Create new array and initialize the drives.
  • Take all services offline.
  • Copy data across.
  • Remove or rename old array.
  • Rename new array/partitions the to same letters as old was.
  • Restart services.
 
I must reuse the old enclosure, and there are no spare drive slots on that enclosure. So the old drives will need to be removed before the new ones can be installed.
 
Use something like Acronis to produce a backup image of the logical disk.

Then replace all the disks, create a new RAID, and restore the image using an Acronis bootable disk and external harddrive containing the .tib image.
 
Expander or second P410, cables and sit the drives on top until moved.

Otherwise, move all data to another system or external disk, pull old and create new. Move data back afterwards.

I certainly don't condone an image tool that stands good chance of not putting data back in optimum order or layout.
 
I certainly don't condone an image tool that stands good chance of not putting data back in optimum order or layout.
You can do a sector-by-sector backup. There's nothing wrong with doing this using Acronis.
 
There are basically four sensible options.

  1. If you are able to bring all drives online at the same time create a new array on the new disks and make a block level copy. During this process the array is unavailable, but this is the fastest way and you have your old disks as valid backup at the end should something go wrong. You will probably need an expander to connect all drives to your controller.
  2. If you can't bring all disks online you can make block level copies of the drives separately. I'm not sure if all RAID controllers properly detect the superblocks on the new drives when they are larger. You will also have the old drives as backup and the array will not be available for a longer time.
  3. If uninterrupted service is prefered, replace them online. This can take a long time and puts a lot of stress on the remaining old disk (maybe less important since they are SSDs). While one disk is replaced you have no mirror of the drive left during rebuild. So in case of a read error or failed drive you are SOL.
  4. If you can't bring all drives online at the same time make a block level copy to a backup drive, which should be easy considering the size of your drives, then pull the old drives, build a new array and restore your block level copy.

If it was my array I would do no. 1 or 4 alternatively. Both can also be done at file level with the added benefit of complete defragmentation.
 
Last edited:
Getting this done isn't difficult. Options are basically listed above..

I hope your application (and your team) is able to withstand the *staggering* loss in speed that will occur from this move. Full SSDs are "slow" but not spinning SAS slow.
 
Back
Top