[U_]

先日、サーバのメンテナンスでESXi 5.1にアップデートしたのですが・・・

なんかPOST時に警告が出てると思ったらS.M.A.R.Tの警告ですぐに(HDD型番)のバックアップをせよ的な文面が出てた
んで、RAID1の片割れだったので搭載してる仮想マシンの状態を見てみたら[U_](片肺)になってた。

これはなんてこったいと思ったのですが…今すぐ代わりの1TBHDDを買う金銭余裕もあまりなく、RAID1を崩すことにしました。

案の定操作ミスをしました。なにをトチ狂ったのかRAID1を解除したあとに残すほうのHDDのスーパーブロックをzerofillしました。

当然マウントしようとするとファイルシステムが分からないよーと返ってきます。

(しばらく絶望)

しかし、superblockを消しただけならデータ領域は残っているハズなのです。
そしてsuperblockはほぼ必ずバックアップがあるようです!

[root@XXXX~]# mkfs.ext4 -n /dev/sdb1
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
60948480 inodes, 243793664 blocks
12189683 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
7440 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848

ありました。

ただちにsuperblockをバックアップから戻す必要があります。
次のコマンドを試します。

[root@XXXX~]#  fsck.ext4 -b 32768 -B 4096 /dev/sdb1

エラーで実行できませんでした
こうなれば最終手段です。

[root@XXXX~]# mke2fs -S /dev/sdb1

60948480 inodes, 243793664 blocks

12189683 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
7440 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848

Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 38 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

superblockを書き込めたようです?
しかしマウントをトライしてみると(ひとまずread-onlyで)

[root@emily ~]# mount -o ro /dev/sdb1 /share/temp
mount: Stale file handle

マウントできません。

この時点で次のコマンドを試したらなにやら自動修正みたいなことが始まりました。

[root@XXXX~]#  fsck.ext4 -y -b 32768 -B 4096 /dev/sdb1

しかし凄まじい時間がかかった挙句にMemory allocation errorで停止しました。
mke2fs -S /dev/sdb1のコマンドを実行した状態まで戻しました。

もう日をまたいでいたので諦めようかと思ってたんですが、論理障害(操作ミス)だしデータ領域は生きているんだろうなぁ・・・とか考えると諦められません

そしてこのような状況に使えるツールとしてtestdiskというユーティリティがあることを知りました。

http://www.cgsecurity.org/wiki/TestDisk

Linuxのx64だったのでBinary downloadsからtar.bz2をダウンロードしました

[root@XXXX ~]# wget http://www.cgsecurity.org/testdisk-6.14-WIP.linux26-x86_64.tar.bz2
–2013-04-14 10:55:54– http://www.cgsecurity.org/testdisk-6.14-WIP.linux26-x86_64.tar.bz2
www.cgsecurity.org をDNSに問いあわせています… 193.168.50.120
www.cgsecurity.org|193.168.50.120|:80 に接続しています… 接続しました。
HTTP による接続要求を送信しました、応答を待っています… 200 OK
長さ: 5535116 (5.3M) [application/x-bzip2]
testdisk-6.14-WIP.linux26-x86_64.tar.bz2' に保存中

100%[==============================================================>] 5,535,116 1.32M/s 時間 4.0s

2013-04-14 10:55:58 (1.32 MB/s) - testdisk-6.14-WIP.linux26-x86_64.tar.bz2′ へ保存完了 [5535116/5535116]

[root@XXXX ~]# tar xjvf testdisk-6.14-WIP.linux26-x86_64.tar.bz2

[root@XXXX ~]# cd testdisk-6.14-WIP

[root@XXXX testdisk-6.14-WIP]# ./testdisk_static

最初の画面ではログをどうこう言ってますが、[CREATE]選択しとけばいいでしょう
修復対象のディスクは私の場合は/dev/sdb1を選択
パーティションテーブルのタイプがどうこう言ってるのでIntel選択(LINUX / WINは基本コレ)
ただしHDDの容量(2TB↑)とか、あえてGPTにしてるとかによってはGPT EFIとかのこともある

ようやく対象のパーティションに対しての操作メニューが出てくるのでとりあえずAnalyze(解析)する
このツールは結構重要な操作もサクッっとできてしまうので使う場合はここからの操作に注意してください

Analyzeを選択すると現在のパーティション情報が見られます。このままQuickSearch実行
私の場合QuickSearchだと必要な情報が得られなかったので、DeeperSearch?を続けて実行しました。ディスク容量によっては結構時間がかかります(1TBで2~3時間かかりました)
これで正しいパーティションっぽいものが出てきたのでそれのタイプをPrimaryに変更、Writeで変更を適応しました。
あとなんか余計なパーティションっぽいのがあったのでそれはDeleteにしてました。よく考えると怖い行為です。

これでtestdiskを終了しました。rebootが必要みたいだったのでrebootしました。
再度マウントを試します。

[root@XXXX~]# mount -o ro /dev/sdb1 /share/temp
[root@XXXX ~]# ls /share/temp
backup downloads lost+found private public public_html svn

なんということでしょう、ぶっちゃけダメ元だったんですが復旧できてしまいました。
ただコンソール側にはエラーが結構でてるのでダメなファイルもそこそこあるでしょうね
読み書き用でマウントできないし・・・仕方ないので別ディスクにいったんコピーしてフォーマットです。
次バックアップを構成するときは一番簡易であると思われるただの非同期バックアップにします・・・

コメントを残す

メールアドレスが公開されることはありません。