DELL SAS 6/iR Adapterで構成したRAID1 VolumeをSATA HDDにクローン化してみる

1. なんでこんなことやってんの？

DELL PowerEdge R300に実装されていたSAS 6/iRでRAID1を構成していたのだが、2本のSAS HDDのうち1本が破損。RAID1で作成した仮想ボリュームでのシステム運用に支障が生じた。そこで新たなSAS HDDを調達し、SAS 6/iRの機能でRAID1 Volumeの修復（HDD同期）を試みるも失敗。どうやらRAID1を構成していた2本のSAS HDDとも、損傷している...という状況に。このあたりの状況は次の記事をどうぞ。

silvernetworks.hatenablog.jp

で、当然このままでは置いておけない。考えてみると、RAIDで構成されている仮想ボリュームは、OSから見れば単体ストレージとして見えるワケで。ということは、ddrescueあたりで（RAIDの）仮想ボリュームを、1本のSATA HDDにクローンを取れないか？と思い立った次第。RAIDの仮想ボリューム、SAS HDD、SATA HDDともOSから見ればMBR（or GPT）を含むストレージなワケで。上手くいけば、クローニングされたSATA HDDからさっくりシステムが起動できるか、と考えた次第。

あと、実はSAS HDDで運用しているシステムは今回障害を起こしたこの1台のみ。SASとSATAで信頼性に大きな差があるワケでもない（と個人的には思っている）。であれば、ハードウエア障害時に、適当なPCにつないでさくっとHDDごとクローニングできるSATAの方が圧倒的に便利。

さらに（個人的には）各種ハードウエアRAIDで組まれたシステムでロクな目にあったことがない。RAID Adapterごと壊れて八方ふさがりになったり、RAID5でも2本同時にHDDが損傷したり...。今回も2本のHDDが（ほぼ）同時に損傷。考えてみたら、2本のHDDには同じ負荷がかかってきたのだから、壊れる時期もほぼ同じになるのは、ある程度合点のいく話。

などなど、諸々の背景があり、RAID1で構成した仮想ボリュームデータを、SATA HDDへ引き抜くことになった。

2. 構成と操作

ざっくりとしたクローン化のイメージはこんな感じ。SystemRescueCDでシステムを起動し、ddrescueにより、RAID1で構成された仮想ボリュームをSATA HDDへクローニングする。

PowerEdge R300マザーボード上のSATA I/Fへ次のSATA HDDを接続し、SystemRescueCDでシステム起動。使用したSystemRescueCDのバージョンはv4.8.1。

f:id:silvernetworks:20160821160030p:plain

SATA HDD（Seagate ST32000542AS）は難なく/dev/sdaに割り当てられた。

f:id:silvernetworks:20160821160045p:plain

心配していたのがSAS 6/iR Adapterで作成した仮想ボリューム。こちらも難なくVIRTUAL DISKとして認識され、/dev/sdbに割り当てられた。ちなみに、VIRTUAL DISKは、あくまでRAID作成時に命名したラベル名なので、必ずこうなるワケではない。

f:id:silvernetworks:20160821160050p:plain

念のため、認識されたそれぞれのデバイスのセクタサイズを調べる。

fdisk -l /dev/sda
fdisk -l /dev/sdb

という感じ。いずれもセクタサイズが512bytesであることが確認できる。

f:id:silvernetworks:20160821160055p:plain

なお、GPT PMBR size mismatchと言われているが、今回の宛先となる/dev/sda（Seagate ST32000542AS）は、以前ddrescueで無理矢理他のHDDクローンの宛先としたことがあり、PMBRの値は正確なものではない。どのみち上書きされるので、ここは気にしない。

/dev/sda、/dev/sdbの各デバイスが間違いなく送信元、送信先デバイスであることを確認でき、論理セクタサイズも同じであることが確認できたため、ddrescue実行。

f:id:silvernetworks:20160821160100p:plain