TeraStation のソフトウェアRAIDの構成情報が失われてエラーになってしまったときの、データ・サルベージ方法のメモ。
書いたのは 2011 年なので、当時の状況は現在の TeraStation には当てはまらないことがあるかもしれない。
0. 作業用ディスクを用意する
できれば、元のディスクと同じモデルで。
同じモデルが入手ができない場合は、かならずもとのディスクよりも容量(セクタ数)が多いものを用意する。
手持ちのディスクを使用する場合は、最初のコピーで区別がつくように、事前に作業用ディスクのすべてのパーティションを削除しておくのがよい。
また、サルベージしたデータを保存するディスクは、TeraStationに格納していたデータ量に応じて用意する。
1. 複製の作成
KNOPPIX で作業する。
TeraStation から取り外したコピー元ディスクが /dev/sda に、サルベージ作業用のディスクが /dev/sdb に つながっている状態であるとする。
コピー元とコピー先を間違えると取り返しのつかないことになるため、くれぐれも慎重に作業すること。
シリンダあたりのセクタ数と、ディスクのセクタ数を fdisk -l で確認する。
セクタ単位でコピーすると時間が掛かるため、ブロックサイズをシリンダ単位にしてコピーする。
dd if=/dev/sda of=/dev/sdb bs=シリンダあたりのセクタ数b
なお、bad block が出ているディスクの場合は、コピーの最中にリードエラーが出てコピーが止まることのないように
dd if=/dev/sda of=/dev/sdb bs=1b count=ディスクのセクタ数 conv=noerror,sync
とする。この場合、読めないブロックをスキップするため、すべてのデータを回収することは 叶わないだろう。
コピー元ディスクに物理的な障害が発生している場合は、ディスクアクセスに伴い、異音がするので区別がつくと思われる。
コピーがすんだらコピー元ディスクは外して保管しておく。
2. データの回収
Endian の心配をしたが、IA32 と同じ Little Endian だったので KNOPPIX で作業する。
コピーしたディスクが /dev/sda に、サルベージしたデータを保存するディスクが /dev/sdb に つながっている状態であるとする。
データを保存するディスクはxfsにしておくのがよい。TeraStationではデータ領域はxfsを使用しているので、ディレクトリのリンクカウントが 32000 を超えるものが存在する可能性がある。ext3では、このようなディレクトリでは、サブディレクトリが作成できず、コピーに失敗する。
ちなみに ext4 と xfs では、リンクカウントが 65000 を超えると、1 にリセットされカウントアップしなくなる。
パーティションがGPTになっているため、gparded でパーティション一覧を表示
おそらくこのような構成になっているはず。
- sda1 起動(ext3)
- sda2 システム(ext3)
- sda3
- sda4
- sda5
- swap
- sda6 データ領域(xfs)
コピー元ボリュームをマウントする。メタデータのバージョンが 0.9 の場合、メタデータはパーティションの最後尾に書かれているため、ミラーの片側だけをそのままマウントすることができる。
mount -t ext3 -o ro /dev/sda1 /media/sda1
mount -t ext3 -o ro /dev/sda2 /media/sda2
mount -t xfs -o ro /dev/sda6 /media/sda6
Linux の場合、マウントオプションに ro を指定して read-only でマウントしても、ジャーナルのリプレイが行われるためディスクへの書き込みが発生する。
ジャーナルのリプレイを防ぐ必要がある場合は、norecovery オプションも指定する。
ただし、この場合、マウントしたファイルシステムはメタデータの一貫性がないかもしれない。したがって、この後のファイルの読み出しで失敗したり、運が悪いとカーネルパニックを引き起こす可能性がある。
もともとLinuxのファイルシステムは、ジャーナルやメタデータの書き込み処理において、一貫性を保証するような実装になっていない。したがって、ジャーナルそのものが当てにならないことがある点に留意する。
mkdir /media/sdb1
mount /dev/sdb1 /media/sdb1
mkdir /media/sdb1/sda{1,2,6}
cd /media/sda1 && find . -xdev -depth -print | cpio -pdmvu /media/sdb/sda1
cd /media/sda2 && find . -xdev -depth -print | cpio -pdmvu /media/sdb/sda2
cd /media/sda6 && find . -xdev -depth -print | cpio -pdmvu /media/sdb/sda6
A. FS: Filesystem sda6 has duplicate
UUID XFS のファイルシステムには UUID が振られているため、ミラーディスクの、個々のメンバーボリュームを、両方ともマウントしようとすると、「FS: Filesystem xxx has duplicate UUID」というエラーメッセージが出力され、マウントできない。
この場合は、nouuid オプションを指定して、UUID を無視するようにすれば、マウントできる。
mount -t xfs -o ro,nouuid /dev/sdb6 /media/sdb6
B. ミラーの再構成
どのパーティションがどのミラーデバイスにバインドされていたかは、sda2 の var/log/messages をみて確認する。
grep 'md[0-9]' /media/sda2/var/log/messages
md0: sda1 sdb1
md1: sda2 sdb2
md2: sda6 sdb6
md10: sda5 sdb5
mdadm でミラーの再構成をおこなう。作業用ディスクはひとつしか用意しなかったので、片方には missing を指定した。
mdadm --create /dev/md0 --level=1 --raid-devices=2 --metadata=0.90 /dev/sda1 missing
mdadm --create /dev/md1 --level=1 --raid-devices=2 --metadata=0.90 /dev/sda2 missing
mdadm --create /dev/md2 --level=1 --raid-devices=2 --metadata=0.90 /dev/sda6 missing
mdadm --create /dev/md10 --level=1 --raid-devices=2 --metadata=0.90 /dev/sda5 missing
この処理では、メタデータが再構成されるだけで、RAIDボリュームに含まれるデータは保持されているはずであるが、くれぐれも自己責任 "At your own risk" で実施してもらいたい。
C. RAID5 の再構成
この節に記載する内容は、机上レベルでの想定手順なので注意されたい。
RAID5 ボリュームのデータをサルベージする場合は、メンバーを再アッセンブルする必要がある。
RAID5 のディスクが /dev/sda 〜 /dev/sdc に接続されているとする。
再アッセンブル用の mdadm.conf を作成する。
echo "DEVICE /dev/[hs]d?[0-9]" >/tmp/mdadm.conf
mdadm --examine --scan --config=/tmp/mdadm.conf >>/tmp/mdadm.conf
検出されたRAIDボリュームをスタートさせる。
mdadm --assemble --scan --config=/tmp/mdadm.conf
下記のようなメッセージが出力されれば、RAIDボリュームがアクセスできるようになっているはず。
mdadm: /dev/md2 has been started with 3 drives (out of 4).
RAIDの構成情報が飛んでしまっている場合は、この手順ではRAIDボリュームがスタートできない。 メタデータを再構成する。
mdadm --create /dev/md2 --level=5 --raid-devices=4 --metadata=0.90 /dev/sda6 /dev/sdb6 /dev/sdc6 missing
この処理では、メタデータが再構成されるだけで、RAIDボリュームに含まれるデータは保持されているはずであるが、未検証のため、くれぐれも自己責任 "At your own risk" で実施してもらいたい。
D. /etc/melco/diskinfo
array1=raid5
array2=off
disk1=array1
disk2=array1
disk3=array1
disk4=array1
usb_disk1=
usb_disk2=
usb_disk3=
usb_disk4=