TeraStationディスクのサルベージ

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=
```