EXT3フォーマット破損からのデータ復元

ファイルサーバとしてつかっていたUbuntu Linuxのユーザ切り替え画面で
ユーザ切り替えができなくなっていたので、電源ボタン長押しで
強制的に電源を落としたところUbuntuが立ち上がらなくなってしまいました。
chrootを使った方法を試してみました。
プロセス番号が677となっていますが、こちらでは754でした。
http://ubuntuforums.org/showthread.php?t=1309423​
ここにあるとおり、9.04のLiveCDを用いて
cd /
mount /dev/sda1 /mnt
mount --bind /dev/sda1 /mnt/boot
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /dev /mnt/dev
chroot /mnt
apt-get update
apt-get dist-upgrade
dpkg --configure -a
とコマンドを打って、再起動したのですが
UbuntuはGRUB画面すら立ち上がらず、
LiveCDからGPartedを立ち上げると
ファイル共有用の1TBHDDのファイルシステムが壊れ、ファイルを読み出すことができなくなりました。
ファイル共有用の1TBHDDは/dev/sdb2として認識されています。
次に行った行動は
​http://www.atmarkit.co.jp/flinux/rensai/linuxtip …​
にある。
mkfs.ext3 -n /dev/sdb2
fsck.ext3 -b 32768 -B 4096 /dev/sdb2
mke2fs -S /dev/sdb2
とコマンドをうち、なんとかEXT2ファイルフォーマットとして
Gparted上から認識されるようになりました。
しかし、マウントしようとすると
org.freedesktop.Hal.Device.Volume.Unknownというエラーが出てしまいます。
これ以上、自分でいじると事態が取り返しのつかない状態になりそうです。
このHDDを元の状態に戻すためにはどうしたらよいのでしょうか？
最悪の場合はPhotorecを用いて復元しようと考えていますが、
ディレクトリ構造もなるべく残した形で復元したいのです。
ご教授お願いいたします。

No.1 ベストアンサー 回答者： vaidurya 回答日時： 2010/01/15 14:19

これだけの時間が経って、何の回答も無いのは

たぶんほとんどの人が、私同様「手遅れだ」と考えていると思います。
(スーパーブロックの再生成は、あまり体験した人はいないと思います)

省略した手順やエラーメッセージがあるのかもしれませんが…
書かれていなければ、それはやっていないものとして考えます。

後の祭りなのですが、ファイルサーバーであれば、普通はローカルからログインしません。
openssh serverなどを導入して、sshログインできるようにしておけば
電源の強制断が必要になることは無かったでしょう。

そのほかコンソールからの(CUIでの)管理についての基本を知らず
GUIツールが提供していない手段について調べる過程で
その方向性を見誤って、発見したのが
"基本的な手順で回復できなかった場合のための特殊な作業"だったように見えます。


電源強制断による起動不能は、ほとんどのOSにおいて
最初に行なうべきことは、ファイルシステムのチェックです。

もちろん自動的にそれを行なう仕組みはLinuxでもWindowsでもありますが…
共に、それが正常に機能せず…
LiveCD等から起動したOSから、ファイルシステムのチェックを行なうことで
回復することができることがあります。

この手順を行なわず、apt-getなどで書き込みを行なっても
よけいにファイルシステムの異常を助長する可能性があります。


この手順とファイルサーバー用のパーティションがおかしくなったことには
直接的な関係があるのか?それとも電源強制断の時点でおかしかったのかはわかりません。

どちらにしても、最初にすべきなのはファイルシステムのチェックです。


この段階で、よく考慮しなければならないのは
使われているファイルシステムが何か?です。
mke2fsによるスーパーブロック再生成という手順は
ext3で使われる方法です。

仮に、これがReiserFSやXFSであれば
mke2fsの使用、その前のmkfs.ext3が誤りとなります。

再フォーマットとスーパーブロック再生成をやった時点で
マウントが正常に行えないなら
Photorec等でのファイル復旧も困難になっている可能性もあります。

同じフォーマット形式でも、パラメーターの違いはありますから
ことなるパラメーターでフォーマットした状態であれば
Photorecも正しくファイルを認識できない可能性があります。

こういったフォーマット時のパラメーターの違いは
ディストリビューションごとのデフォルト値の違いや
管理者自身による変更によって生じます。

なお、フォーマット形式が何であったか?は起動パーティションの
/etc/fstabを参照できれば確認できます。

ほとんど余談ですが
特殊な組み合わせで、/dev/sdaと/dev/sdbが入れ替わることがあります。
ほとんどのシステムでストレージデバイスコントローラーが
二つか四つのデバイスを接続できる仕組みですが…

SATAなどでは、二つのSATAコントローラーの存在する環境で
別々のコントローラーに接続した二つのHDDの間に
/dev/sdbを開けて/deb/sdcを割り当てることがありません。

M/Bに二つのSATAコントローラーを内蔵していることもあるので
意識せずに、別々のコントローラーに二つのHDDを接続していて
それがLinuxディストリビューションの違いや、その他の原因によって
コントローラーの認識順の違いを招き、sdaとsdbが入れ替わることがあるのです。

(実際うちの録画サーバーでは、同じOS環境のまま
起動時に内蔵SATAとPCIe SATAカードが入れ替わることがあります)

fstabなどでは、こういったトラブルを回避するために
UUIDでのパーティション指定が一般化していますが…
手作業でのパーティション操作において、勘違いで
違うパーティションを自ら破壊してしまうこともありえます。
(またUUIDはスーパブロック再生成の手順で異なるUUIDになっているはずです)

とりあえず、読み出せるならfstabと
sudo fdisk -lの結果を掲示すると
なにかヒントが見つかるかもしれませんが…可能性は低いと思います。

この回答への補足

詳細な回答恐れ入ります。
現在、ファイル用HDDをWindowsマシンにつないで、
R-studio(ver2.0)による復元を試みております。
ですので、fstabとFdiskの結果を貼り付けられるのは、復元を試みた
後になりそうです。
今、手元にあるメモでは
OS用のHDD(160GB)とファイル用HDD(1TB)は物理的に別ドライブで、
ファイルフォーマットはEXT3でした。

補足日時：2010/01/15 17:52

この回答へのお礼

R-studio ver2.0では復元は出来ませんでした。
構成を元に戻して、Fdisk -lコマンドをした結果を示します。
# fdisk -l

???? /dev/sda: 160.0 GB, 160041885696 ???
??? 255, ??? 63, ???? 19457
Units = ????? of 16065 * 512 = 8225280 ???
Disk identifier: 0x0006034c

???? ??? ?? ?? ???? Id ????
/dev/sda1 * 1 19270 154786243+ 83 Linux
/dev/sda2 19271 19457 1502077+ 5 ????
/dev/sda5 19271 19457 1502046 82 Linux ???? / Solaris

???? /dev/sdb: 1000.2 GB, 1000204886016 ???
??? 255, ??? 63, ???? 121601
Units = ????? of 16065 * 512 = 8225280 ???
Disk identifier: 0xd739b570

???? ??? ?? ?? ???? Id ????
/dev/sdb2 1 121601 976760001 83 Linux

???? /dev/sdc: 1000.2 GB, 1000204886016 ???
??? 255, ??? 63, ???? 121601
Units = ????? of 16065 * 512 = 8225280 ???
Disk identifier: 0x0004f367

???? ??? ?? ?? ???? Id ????
/dev/sdc1 1 121601 976760001 83 Linux

fstabの中身です
# cat /mnt/etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# /dev/sda1
UUID=b232a6cf-058d-4731-81e8-66b22107cf4a / ext3 relatime,errors=remount-ro 0 1
# /dev/sda5
UUID=f27f0d70-d57b-45b6-90dc-87c64e40525b none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0
/dev/sdb /media/1TB ext3 defaults,errors=remount-ro 0
1
/dev/sdc /media/1TB_2 ext3 defaults,errors=remount-ro 0
1

お礼日時：2010/01/17 16:10