TeraStationディスクのサルベージ

TeraStation のソフトウェアRAIDの構成情報が失われてエラーになってしまったときの、データ・サルベージ方法。

0. 作業用ディスクを用意する

できれば、元のディスクと同じモデルで。

同じモデルが入手ができない場合は、かならずもとのディスクよりも容量(セクタ数)が多いものを用意する。

手持ちのディスクを使用する場合は、最初のコピーで区別がつくように、事前に作業用ディスクのすべてのパーティションを削除しておくのがよい。

また、サルベージしたデータを保存するディスクは、TeraStationに格納していたデータ量に応じて用意する。

1. dd でコピー

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)

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のファイルシステムは、ジャーナルやメタデータの書き込み処理において、一貫性を保証するような実装になっていない。したがって、ジャーナルそのものが当てにならないことがある点に留意する。

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/sda6

B. ミラーの再構成 どのパーティションがどのミラーデバイスにバインドされていたかは、sda2 の var/log/messages をみて確認する。

grep 'md[0-9]'

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" で実施してもらいたい。