ネットワークアタッチトストレージ(NAS)のデータサルベージ

本職はデータベースエンジニア(Oracle)だが、不思議な縁があって宮崎県のおそらく教育系の職場で使われていたNAS(ネットワークアタッチトストレージ)のデータサルベージの手助けをする事ができたので、技術系の情報に関して載せてみたいと思った。

 

IT系という仕事柄Linuxを使う機会も多く、プライベートでも自宅にSolidRun製のcubox-iという小型PCにDebianを入れて運用している。

f:id:LagrangeL2:20190918234207p:plain

CUBOX-I

 

サルベージに成功したNASは以下のものとなる。

f:id:LagrangeL2:20190918235252p:plain

ELECOM NSR-MS2T2BLB

・ELECOM NSR-MS2T2BLB
・WD Red NAS Hard Drive 1.0TB×2機
SATA/64MB Cache
・WD10ERRX
RAIDミラーリングにて運用

・NASware 3.0

 

メーカー製なため、中身にLinuxが使われているという事以外は全くのブラックボックスだった。

なお当方はニューヨークに在住しているため、知恵袋経由でコマンドを宮崎県在住の実作業者に対して全て提供し、結果を貼り付けて貰うというやり方で進める事となった。

 

データベースエンジニアという仕事柄、本番機環境のデータベースの復旧作業を行う事もある事はあるのだが、最近は本当に堅牢にハードもソフトも作られているため、データ復旧という機会はそうあるものでもないのが実情である。

 

データベースの復旧の鉄則として、今でも最初に受けたトレーニングクラスで覚えているのは、「復旧作業を開始する前に現状のバックアップを必ず取得しておく事」だった。

そうしておけば、例え復旧作業を失敗したとしても最悪またやり直せるからというのが一番の理由である。

この鉄則に基づいて、オリジナルのNASで直接作業するのは避け、まずはNASの全データをddにてブロックレベルで新規HDD上にコピーして貰い、そこで作業するという方式を取った。

 

実作業者はある程度のPCに関する知識は有していた様で、Live CDで起動できるUbuntuを使って作業して貰った。

まずはddコマンドにてオリジナルのNASから新規に購入して貰ったHDDへとddを使って完全コピーを作成して貰った(作業は全てrootユーザー)。

(オリジナルのNASは/dev/sdaとして認識しており、新規HDDは/dev/sdbとして認識)

 

dd if=/dev/sda of=/dev/sdb bs=1M

 

コピー完了後、オリジナルのNASは外して貰い、Ubuntuを再起動して貰う。

これによりコピー先のHDDは/dev/sdaとして認識された。

 

以下は全てコピーした新規HDD上での作業となる。

(本当は紆余曲折が二週間ほどあったのだが、最短ルートでの復旧方法に関して記述して行きたいと思う)

 

コピー終了後にpartedによって現状のパーティションに関して確認して貰う。

 

root@ubuntu:/home/ubuntu# parted /dev/sda print
モデル: BUFFALO HD-EDS-A (scsi)
ディスク /dev/sda: 4001GB
セクタサイズ (論理/物理): 512B/4096B
パーティションテーブル: gpt
ディスクフラグ:

番号 開始 終了 サイズ ファイルシステム 名前 フラグ
4 1049kB 10.7GB 10.7GB 瀀瀀挀ⴀ吀䠀䔀䌀唀匀 raid
5 10.7GB 21.5GB 10.7GB raid
1 21.5GB 23.6GB 2147MB raid
3 23.6GB 24.2GB 537MB raid
2 24.2GB 1000GB 976GB 吀䠀䔀䌀唀匀 raid

 

上記の結果から、パーティション2の976GBの領域に目的のデータが蓄積されていると当たりを付けた。

 

オリジナルのNASがmdadmによるソフトウエアレイドのミラーリングで運用されているため、コピー先のHDD1台でも読み込める様にミラーリングを解除する必要があった。

以下のコマンドにより、無理やり1台ミラーリング構成へと変換させた。

 

mdadm --verbose --assemble /dev/md0 /dev/sda2 --force
mdadm /dev/md0 --grow --raid-devices=1 --force
mdadm --examine /dev/sda2

 

[コマンド結果]

root@ubuntu:/home/ubuntu# mdadm --verbose --assemble /dev/md0 /dev/sda2 --force
mdadm: looking for devices for /dev/md0
mdadm: /dev/sda2 is identified as a member of /dev/md0, slot 1.
mdadm: no uptodate device for slot 0 of /dev/md0
mdadm: added /dev/sda2 to /dev/md0 as 1
mdadm: /dev/md0 has been started with 1 drive (out of 2).
root@ubuntu:/home/ubuntu# mdadm /dev/md0 --grow --raid-devices=1 --force
raid_disks for /dev/md0 set to 1

 

(/dev/md0として認識させているが、場合によっては/dev/mdprocを見てデバイス番号を確認する必要有り)

 

 

オリジナルのNASext4によって運営されていたので、ファイルシステムの修復をfsck.ext4にて試みる。

 

fsck.ext4 -fy /dev/md0

 

[コマンド結果]

root@ubuntu:/home/ubuntu# fsck.ext4 -fy /dev/md0
e2fsck 1.44.1 (24-Mar-2018)
/dev/md0: recovering journal
Pass 1: Checking iノードs, blocks, and sizes
Pass 2: Checking ディレクトリ structure
Pass 3: Checking ディレクトリ connectivity
Pass 4: Checking reference counts
Pass 5: Checking グループ summary information
Free blocks count wrong (8609789, counted=8194408).
修正? yes

Free iノードs count wrong (14725976, counted=14696827).
修正? yes


/dev/md0: ***** ファイルシステムは変更されました *****
/dev/md0: 187013/14883840 files (1.8% non-contiguous), 6698613/14893021 blocks

 

 

無事にファイルシステムが修復されたから、後はマウントして終わり・・・と思ったのだが、ここから二週間近くハマったポイント。

ファイルシステムはクリーンな状態になったのにマウントしようにもひたすら以下の様なエラーが出てしまう。

 

@ubuntu:/home/ubuntu# mount /dev/md0 /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/md0, missing codepage or helper program, or other error.

 

i-nodeのスーパーブロックが壊れているのかと思い、全ての代替i-nodeを試してみても結果は同じ。

ext4のi-nodeを再作成してみたけど、結果は駄目。

dmesgの結果を見ると以下の様なエラーが上がって来ていた。

 

[ 917.402848] md0: detected capacity change from 0 to 976029220864
[ 1739.855732] EXT4-fs (md0): bad block size 65536

 

端的に言うと今現在主流となっている一般的なPCのCPUはx86_64であり、ページサイズは4kとなる。

ところがオリジナルのNASで使われているCPUはia64, mips, parisc, powerpc, sh, sparcなどのどれかであるため、ページサイズが64kで作成されている。

したがって今現在主流のPC上でこのファイルシステムを標準のマウントコマンドで読み込める様にする事は実質的に不可能となっている。

 

マウントできないならなんとかしてファイルシステムを直に読み込む方法を探すしかない。

という事でどうやらファイルシステムデバッグなどに使うdebugfsというツールはこの4kページサイズの制限を受けないという事を知る。

 

実際に以下のコマンドを入力して貰うと、ファイルシステムの中身のディレクトリ一覧を無事に表示できた。

 

debugfs -R "ls -l" -c /dev/md0

 

上記の結果によるなりば"/data"というディレクトリ上に業務で使用していたファイル群が存在しているという事を知った。

後はdebugfsを使って、サルベージ対象となっているファイル群を通常のファイルシステムへとコピーしてやれば良い。

という事で復旧先の通常のext4ファイルシステムを別の新たなHDD(/dev/sdbとして認識)上に作成して貰った。

 

以下が通常のファイルシステムを復旧先として新規HDD上に作成して貰った結果。

 

root@ubuntu:/home/ubuntu# mkfs.ext4 /dev/sdb2 (これは環境に応じて要変更)

root@ubuntu:/home/ubuntu# mkdir /salvage
root@ubuntu:/home/ubuntu# mount -t ext4 /dev/sdb2 /salvage
root@ubuntu:/home/ubuntu# chmod 755 /salvage
root@ubuntu:/home/ubuntu# cd /salvage
root@ubuntu:/salvage# pwd
/salvage
root@ubuntu:/salvage# ls -l
合計 16
drwx------ 2 root root 16384 8月 30 14:15 lost+found
root@ubuntu:/salvage#

 

これで復旧先は確保できたので、実際にサルベージを実行して貰った。

 

debugfs -R "rdump /data ." -c /dev/md0

 

上記のコマンドの意味は-Rは""(ダブルクォーテーション)で囲まれた部分を実行しろという意味。

rdumpは対象ファイル/ディレクトリ一覧のイメージダンプを再帰的に取得する様にという意味になる。

そして肝心なのが"-c"オプション。

これはカタストロフィモード(大量データ破壊発生時モード)と言ってi-node情報を無視してひたすら実ファイルを追えという事になる。

つまり/dev/md0上の"/data"というディレクトリに存在する全実ファイルを"."で指定したカレントディレクトリ(今の時点で/salvage)上にイメージダンプとして再帰的に復元しろという事になる。

 

root@ubuntu:/salvage# debugfs -R "rdump /data ." -c /dev/md0
debugfs 1.44.1 (24-Mar-2018)
/dev/md125: catastrophic mode - not reading inode or group bitmaps
root@ubuntu:/salvage#

 

結果として、上記のコマンドによって全データの復旧は無事に完了となった。

 

実ファイルとして読める様になったので、後はssh経由でFilezillaを使ってWindows PC上へと転送して貰って復旧を確認して貰った。

 

f:id:LagrangeL2:20190919030309p:plain

 

 

職場の10年分以上に渡るデータを無事に復旧できたとあって、物凄く感謝された笑

 

f:id:LagrangeL2:20190919030441p:plain

f:id:LagrangeL2:20190919030509p:plain

f:id:LagrangeL2:20190919030538p:plain

 

今回はデータベースは全く関わってはいなかったけど、データベース管理者にとって、データ復旧は地味な部分ではあるものの、成功はある意味美学だと思っている笑

もっとも今回幸運だったのは元NASがハード的におかしくなったとは言え、HDDとしては無事に読み込めたという事が一番の成功要因だったと思う。

 

余談だが、無事にデータ復旧できて相手の職場の女性陣から「対応が男前」と言われた事が実は結構嬉しかった笑

f:id:LagrangeL2:20190919031319p:plain

 

#NAS #ネットワークストレージ #データ復旧 #データサルベージ #宮崎