Can I move a software RAID 0 array from my Mac to an external enclosure?
March 16, 2018 7:19 PM Subscribe
I have 2 x 2TB drives in my Mac Pro that I set up as a RAID 0 using Apple’s Disk Utility. It’s working fine, & I have backups galore (time machine, onsite & offsite clones, Backblaze) but the disks are getting old enough that I’m beginning to get concerned about failure.
Can I move these 2 drives into an external enclosure of any sort & have it recognize the RAID configuration? Or is the only device that will recognize an Apple software RAID the Mac that it’s built on?
The objective is to replace them with newer drives, then clone all the data from the old RAID to a new RAID 0 array.
Since the Mac Pro has 4 bays, I could do this by installing 2 new drives in the other 2 bays (would have to temporarily pull 2 other drives out, but NBD) install the new drives in those bays, create the new software RAID 0, clone the old RAID to the new one, then pull the old drives out if that’s the only option. Having them appear as their same old selves in an external dual drive bay would be the optimal situation for me, though, as I would have uses for it with minimal fuss.
I’m curious generally about whether the existing RAID will be recognized in any way if moved, or if even moved to other slots, for that matter. How restrictive are Apple-built software RAIDs?
The objective is to replace them with newer drives, then clone all the data from the old RAID to a new RAID 0 array.
Since the Mac Pro has 4 bays, I could do this by installing 2 new drives in the other 2 bays (would have to temporarily pull 2 other drives out, but NBD) install the new drives in those bays, create the new software RAID 0, clone the old RAID to the new one, then pull the old drives out if that’s the only option. Having them appear as their same old selves in an external dual drive bay would be the optimal situation for me, though, as I would have uses for it with minimal fuss.
I’m curious generally about whether the existing RAID will be recognized in any way if moved, or if even moved to other slots, for that matter. How restrictive are Apple-built software RAIDs?
Response by poster: It’s not the boot disk, it’s just files. OS & apps are on their own drive.
So if it refused to mount in an enclosure, I should be able to put them back into the tower & have them recognized, as it’s old RAID 0 self, I gather, no harm done, if the enclosure doesn’t recognize them as a RAID.
I want to move the data a minimum of times, just to avoid possible corruption while copying, but I suppose since the advent of journaling, I should probably get over that concern. I lost a few semi-important files to corruption from a transfer many years ago & didn’t realize it until it was way too late.
posted by Devils Rancher at 8:01 PM on March 16, 2018
So if it refused to mount in an enclosure, I should be able to put them back into the tower & have them recognized, as it’s old RAID 0 self, I gather, no harm done, if the enclosure doesn’t recognize them as a RAID.
I want to move the data a minimum of times, just to avoid possible corruption while copying, but I suppose since the advent of journaling, I should probably get over that concern. I lost a few semi-important files to corruption from a transfer many years ago & didn’t realize it until it was way too late.
posted by Devils Rancher at 8:01 PM on March 16, 2018
I suppose since the advent of journaling, I should probably get over that concern
Journaling addresses some of the kinds of corruption typically caused by power loss or unexpected drive removal, but it can't detect or fix data rot either at rest or during transfers. The ZFS filesystem does data rot detection automatically, but if you're not using ZFS you can do it by hand with short scripts built on find and shasum.
posted by flabdablet at 8:28 PM on March 16, 2018 [1 favorite]
Journaling addresses some of the kinds of corruption typically caused by power loss or unexpected drive removal, but it can't detect or fix data rot either at rest or during transfers. The ZFS filesystem does data rot detection automatically, but if you're not using ZFS you can do it by hand with short scripts built on find and shasum.
posted by flabdablet at 8:28 PM on March 16, 2018 [1 favorite]
Best answer: Just to be clear: I would not expect an enclosure that has its own inbuilt support for RAID 0 to stripe its drives and/or allocate its RAID metadata in the same way that OS X software RAID does. Any enclosure you use for this should simply expose the individual drives to the OS, letting the OS handle RAID assembly exactly as it would for drives mounted in the Mac's own bays.
Also, be prepared for software RAID 0 performance in a USB enclosure to be disappointing; some of them are really stupidly slow to arbitrate parallel requests across multiple disks.
In your shoes, I would absolutely be using the Mac's own inbuilt bays before reaching for the enclosure. Alternatively, I'd pull the drives and use either a disk duplicating dock or a live Linux boot disk and ddrescue to image them individually onto new drives. As long as I used a method that simply made a bit-identical copy of the original disks at the block level, I can think of no reason why the clones should refuse to assemble into a new RAID 0 array identical to the original.
posted by flabdablet at 11:23 PM on March 16, 2018
Also, be prepared for software RAID 0 performance in a USB enclosure to be disappointing; some of them are really stupidly slow to arbitrate parallel requests across multiple disks.
In your shoes, I would absolutely be using the Mac's own inbuilt bays before reaching for the enclosure. Alternatively, I'd pull the drives and use either a disk duplicating dock or a live Linux boot disk and ddrescue to image them individually onto new drives. As long as I used a method that simply made a bit-identical copy of the original disks at the block level, I can think of no reason why the clones should refuse to assemble into a new RAID 0 array identical to the original.
posted by flabdablet at 11:23 PM on March 16, 2018
Response by poster: Ok, sounds like sticking 2 new 3 or 4 TB drives in the extra bays & doing a clone from the old RAID while they’re still in the machine is the best option. Carbon Copy Cloner has always done well for me as far as getting a reliable bit-for-bit copy, then I can pull the old drives & re-format them.
Thanks!
Still curious- if you took a software RAID out of one Mac Pro & stuck it in another Mac Pro, would it mount & function? Thinking about eventually replacing this 2008 with a 2012 since they just dropped support for the 2008 with Logic.
posted by Devils Rancher at 6:15 AM on March 17, 2018
Thanks!
Still curious- if you took a software RAID out of one Mac Pro & stuck it in another Mac Pro, would it mount & function? Thinking about eventually replacing this 2008 with a 2012 since they just dropped support for the 2008 with Logic.
posted by Devils Rancher at 6:15 AM on March 17, 2018
Best answer: if you took a software RAID out of one Mac Pro & stuck it in another Mac Pro, would it mount & function?
Again, I have no specific experience with Macs to back this up, but having used assorted kinds of RAID for some years I can think of no reason to doubt that it would.
RAID sets generally work by reserving a little bit of space on each of the member disks for RAID metadata, which describes stuff like how many disks comprise the array, what flavour of RAID it is, exactly how the logical blocks that the overall array presents to the OS will be spread across the member disks, and this particular member's relationship to the array as a whole.
There is no standard format for RAID metadata. In particular, there is no agreement across implementations even about such basic things as whereabouts on the disk it should go. Sane implementations will structure and place the metadata in such a way as to make a RAID member disk highly unlikely to be mistaken for one that's been partitioned for stand-alone use, but there are many insane implementations.
This is why I would not expect a hardware RAID controller such as the one you'd find inside a typical RAID-capable disk enclosure to be able to assemble an array from member disks whose metadata was created by OS X software RAID; such a controller might not even recognize the existence of the OS X metadata, mistake your newly installed disk for a new blank one, and go on to corrupt it in the process of writing out RAID metadata in its own format. This is why I strongly prefer non-RAID-capable enclosures for this kind of thing.
But I would expect any version of OS X to understand RAID metadata written by OS X on some other Mac, and would also expect it to work with RAID metadata written by earlier versions of OS X. Apple occasionally fucks up, but I don't think they'd fuck up anything as basic as that.
posted by flabdablet at 7:12 PM on March 17, 2018
Again, I have no specific experience with Macs to back this up, but having used assorted kinds of RAID for some years I can think of no reason to doubt that it would.
RAID sets generally work by reserving a little bit of space on each of the member disks for RAID metadata, which describes stuff like how many disks comprise the array, what flavour of RAID it is, exactly how the logical blocks that the overall array presents to the OS will be spread across the member disks, and this particular member's relationship to the array as a whole.
There is no standard format for RAID metadata. In particular, there is no agreement across implementations even about such basic things as whereabouts on the disk it should go. Sane implementations will structure and place the metadata in such a way as to make a RAID member disk highly unlikely to be mistaken for one that's been partitioned for stand-alone use, but there are many insane implementations.
This is why I would not expect a hardware RAID controller such as the one you'd find inside a typical RAID-capable disk enclosure to be able to assemble an array from member disks whose metadata was created by OS X software RAID; such a controller might not even recognize the existence of the OS X metadata, mistake your newly installed disk for a new blank one, and go on to corrupt it in the process of writing out RAID metadata in its own format. This is why I strongly prefer non-RAID-capable enclosures for this kind of thing.
But I would expect any version of OS X to understand RAID metadata written by OS X on some other Mac, and would also expect it to work with RAID metadata written by earlier versions of OS X. Apple occasionally fucks up, but I don't think they'd fuck up anything as basic as that.
posted by flabdablet at 7:12 PM on March 17, 2018
Best answer: Carbon Copy Cloner has always done well for me as far as getting a reliable bit-for-bit copy, then I can pull the old drives & re-format them.
If you're going to do all of this in the Mac's own bays then I would recommend creating the new RAID array first, then using CCC to clone the old array to the new one as a whole, rather than cloning individual member disks. That way, the new array will have its own unique ID in its RAID metadata, and there will be no possibility that the OS could mix up old and new member disks on any subsequent reassembly, as could easily happen after cloning individual member disks.
Also, given that the stated aim of replacing your existing array is doubts about the ongoing reliability of the drives, I would recommend not reformatting the old drives after cloning. Just put them away in a drawer instead. This gives you some chance of recovering at least something after a perfect storm of fuckery overwhelms your usual backup strategy two years from now.
posted by flabdablet at 7:26 PM on March 17, 2018
If you're going to do all of this in the Mac's own bays then I would recommend creating the new RAID array first, then using CCC to clone the old array to the new one as a whole, rather than cloning individual member disks. That way, the new array will have its own unique ID in its RAID metadata, and there will be no possibility that the OS could mix up old and new member disks on any subsequent reassembly, as could easily happen after cloning individual member disks.
Also, given that the stated aim of replacing your existing array is doubts about the ongoing reliability of the drives, I would recommend not reformatting the old drives after cloning. Just put them away in a drawer instead. This gives you some chance of recovering at least something after a perfect storm of fuckery overwhelms your usual backup strategy two years from now.
posted by flabdablet at 7:26 PM on March 17, 2018
This thread is closed to new comments.
In any case, if the RAID 0 set you're talking about isn't your boot disk (which I gather it's not, if you have "uses for it with minimal fuss") then you can't really go wrong just by trying this out. Worst possible case is that one of the member drives will be misrecognized as a corrupted whole drive and "fixed" in a way that would mean you'd have to restore up to 4TB of stuff from backups, but given anything even vaguely resembling sane RAID design that's really quite unlikely; the most likely failure mode is simple non-recognition of the set and refusal to mount it.
posted by flabdablet at 7:41 PM on March 16, 2018