- ベストアンサー
MBR消去による復旧方法とデータの保護方法
- MBR消去による復旧方法とデータの保護方法について説明します。質問者は間違ってHDDのMBRを消去してしまい、現在はLinuxMintのサスペンドしかできない状況です。Gpartedでの修復は時間がかかるため他の方法を知りたいとのことです。また、ファイルマネージャからは特定のパーティションのデータにアクセスできるため、HDD全体をスキャンするより効率的な方法を知りたいです。
- また、grub-installとgrub-probeの結果によると、/dev/sda10にGRUBドライブが見つからず、ファイルシステムの自動検出も失敗しています。質問者はこれらの問題の解決方法も知りたいです。
- MBR消去による復旧方法とデータの保護方法について詳細に説明します。
- Linux系OS
- 回答数5
- ありがとう数6
- みんなの回答 （5）
- 専門家の回答
質問者が選んだベストアンサー
ddコマンドのオプションを見れば、No.1の言うほど 簡単な問題じゃ無いことは誰でもわかると思います。446じゃ無いし。 testdiskというツールで、パーティションテーブル破壊から復旧できる場合がありますが 現状、OSがパーティション情報を掴んでいるのであれば 私なら… 1.重要なデータのバックアップ 2.全データのバックアップ 3.設定ファイル等のバックアップ といった優先順で備えた上で 充分な空き容量のあるHDDがあるなら システムパーティション以外をアンマウントして パーティション単位のイメージバックアップができるかを試します。 が、よく考えたら、OSが握っているなら、それ/procにあるだろ? ってことで、ちょっと調べたら、1,2分で、/proc/partitionsが見つかりました。 cat /proc/partitionsして それをもとにパーティション作成をすればいいはずです。 作成には、スクリプトから操作しやすいparted mkpartオプションが便利そうですが 実際に使ったことはありません。 こういうトラブルはそうそう無いことだと思いますが… 大容量のHDDに換装するときなどに まったく同じパーティションサイズを作るときにも応用できそうです。
その他の回答 (4)
- yakan9
- ベストアンサー率54% (2251/4143)
> 私の Mint はなぜ自殺行為を受け付けてしまったのか、謎です。 多分、ddコマンドでは、壊されていなかったと思います。 その後の操作で壊してしまった可能性が大きいです。 ここまで来たら、Mintの再インストールした方が早そうです。
お礼
ご回答ありがとうございます。 dd 以外にはMBRをいじる操作は何もしていない筈ですので、 MBRが壊れた原因 は dd だったのだと思います。 とりあえず USB に Mint をインストールいたしました。 インストールの始めの部分の操作は10分ちょいくらいですが、 LTS の LinuxMint13 Maya だったので アップデートが２時間以上かかっておりました。 HDD はそのままにしておいて、 時間がある時に少しづつ復旧を試みて スキルを付けて行こうと思います。
- yakan9
- ベストアンサー率54% (2251/4143)
前回質問の回答番号1の「お礼」に、 > HDD にインストールしてある Debian において とありますので、下記の回答内容は、 > sdaの内蔵HDDの中のあるパーティションにLinux Mintがあり、 > ここからの起動で、このMintの端末からのddコマンドだと思います。 Mintではなく、Debianということですね。 こうした内蔵HDDのトップをゼロクリアするときは、別なOSで行います。 CD-ROM一枚で起動する、Live CDとか、USBメモリから起動をかけて行います。 前回の回答で、 > このddコマンドを出した後、すぐに応答があり、「512バイトを書き出しました」 > といった意味のメッセージは出なかったと思います。 ここの実際のメッセージは下記のようなメッセージです。 これが日本語で出ているか、英語で出ているかの違いがあるかも知れません。 1+0 レコード入力 1+0 レコード出力 512バイト (512 B) コピーされました、 0.00034972秒、1.5MB/秒 といった表示は、出なかったと思います。 記憶になければ大丈夫です。
お礼
ご回答ありがとうございます。 こちらの方も色々な質問でお世話になっておりますようでして、ありがとうございます。 前回質問時はDebianで作業していましたが 今回質問時は実家に帰省していることもありましてLinuxMintで作業しておりました。 dd にしても試行錯誤する中で何回も実行していますので 普段のような結果表示のメッセージが出たかは 既に記憶が定かでありません。 （若い人間でもこうなのですから、コンピューターはやはり恐ろしい・・・） ターミナルのログもとっていなかったですし。 reboot すると次のようなメッセージが出ました。 Intel UNDI, PXE-2.1 (build-083) Copyright (C) 1997-2000 Intel Corporation This product is covered by one or more of the following patents: （問題ないとは思いますが、ここは略） RealTek PCIe FE Family Controller Series v1.19(08/10/09) PXE-E61: Media test failure,check cable PXE-M0F: Exiting PXE ROM Reboot and Select proper Boot device or Insert Boot Media in selected Boot device and press a key 何回キーを押しても同じメッセージが出るだけで GRUBが起動しませんでしたので、 今はLive版のLinuxMintで作業しております。 私の Mint はなぜ自殺行為を受け付けてしまったのか、謎です。 MBRはマメにバックアップしとかないといけないですね。 現在（というかLive版起動前）の MBR を od で書き出した結果は以下のとおりです。 0000000 000000 000000 000000 000000 000000 000000 000000 000000 * 0000700 000001 177356 177777 000001 000000 101257 045205 000000 0000720 000000 000000 000000 000000 000000 000000 000000 000000 * 0000760 000000 000000 000000 000000 000000 000000 000000 125125 0001000
- yakan9
- ベストアンサー率54% (2251/4143)
> USB の MBR を消去しようとしていたのに > $ dd if=/dev/zero of=/dev/sda bs=512 count=1 > として、間違えてHDDのMBRを消去してしまいまし 貴殿が心配しているような事態にはなっていないはずです。 このddコマンドを出した後、すぐに応答があり、「512バイトを書き出しました」といった意味のメッセージは出なかったと思います。 出ないということは、実際実行しなかったということです。 理由は、sdaの内蔵HDDの中のあるパーティションにLinux Mintがあり、ここからの起動で、このMintの端末からのddコマンドだと思います。 もしそうであれば、このddは、実行されません。 自分を殺すような指示は無視します。 自殺行為は、受付けません。 ということで安心してよいと思います。 こうした実験は当方では検証しています。 大丈夫だと思います。
お礼
ご回答ありがとうございます。
- kteds
- ベストアンサー率42% (1884/4443)
いろいろ書いてありますが、結局何がしたいのか、ハッキリと伝わりません。 > 今のところ、LinuxMintはサスペンドとそこからの復旧はできています。 > Gparted,gdiskなどに分からせることができれば残りの領域にどういうパーティションがあるかだけ検査させれば良いでしょうから、・・・ 意味が解りません。 --- 結局のところ「Mintを起動できるようにしたい」、ということでしょう。 MBRを消しただけですので、grub-installでgrubをMBRにインストールすればいいです。 デバイスmap を確認して --root-directory= パラメータを指定して、MBRにインストールしてみてください。 質問文のエラーメッセージもそのように指摘しています。
お礼
ご回答ありがとうございます。
お礼
ご回答ありがとうございます。 色々な質問でお世話になりまして、ありがとうございます。 当方はLinuxを使いだしてまだ一年も経っておりませんもので、 /proc というディレクトリもよく知りませんでした。 /proc/partitions を見ると、確かにマウントされているパーティションは記載されていますね。 ただ、この内容だけではパーティションの正確な開始位置・終了位置が分からないようです。 Windowsのシステムパーティションが認識されていないので、 そこと その次のLinuxパーティションの境目がハッキリせず 詳細な検査がやはり必要になりました。 結局、testdisk をインストールして ２時間以上 deeper search をかけました。 回答 No.4 の方の欄に書き込みましたように、 今日になって全てのパーティションを認識できない状態になってしまいましたので、deeper search の結果を元に 復旧を試みないといけません。
補足
参考までに Mon Dec 30 23:06:59 2013 Command line: TestDisk TestDisk 6.13, Data Recovery Utility, November 2011 Christophe GRENIER <grenier@cgsecurity.org> http://www.cgsecurity.org OS: Linux, kernel 3.2.0-23-generic (#36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012) x86_64 Compiler: GCC 4.6 Compilation date: 2012-02-05T07:15:52 ext2fs lib: 1.42, ntfs lib: 10:0:0, reiserfs lib: none, ewf lib: none /dev/sda: LBA, HPA, LBA48, DCO support /dev/sda: size 1250263728 sectors /dev/sda: user_max 1250263728 sectors /dev/sda: native_max 1250263728 sectors /dev/sda: dco 1250263728 sectors Warning: can't get size for Disk /dev/mapper/control - 0 B - CHS 1 1 1, sector size=512 Hard disk list Disk /dev/sda - 640 GB / 596 GiB - CHS 77825 255 63, sector size=512 - ST9640320AS, S/N:5WX2X5LD, FW:0002DEM1 Disk /dev/sdb - 2004 MB / 1912 MiB - CHS 1018 62 62, sector size=512 - BUFFALO USB Flash Disk, FW:3.10 Disk /dev/sdd - 31 GB / 29 GiB - CHS 30144 64 32, sector size=512 - JetFlash Transcend 32GB, FW:1.00 Partition table type (auto): Intel Disk /dev/sda - 640 GB / 596 GiB - ST9640320AS Partition table type: EFI GPT Analyse Disk /dev/sda - 640 GB / 596 GiB - CHS 77825 255 63 hdr_size=92 hdr_lba_self=1 hdr_lba_alt=1250263727 (expected 1250263727) hdr_lba_start=34 hdr_lba_end=1250263694 hdr_lba_table=2 hdr_entries=128 hdr_entsz=128 Current partition structure: search_part() Disk /dev/sda - 640 GB / 596 GiB - CHS 77825 255 63 FAT16 at 0/32/33 FAT1 : 1-200 FAT2 : 201-400 start_rootdir : 401 Data : 433-204796 sectors : 204797 cluster_size : 4 no_of_cluster : 51091 (2 - 51092) fat_length 200 calculated 200 FAT16 at 0/32/33 MS Data 2048 206844 204797 [DellUtility] FAT16, 104 MB / 99 MiB NTFS at 12/223/20 filesystem size 30720000 sectors_per_cluster 8 mft_lcn 786432 mftmirr_lcn 16 clusters_per_mft_record -10 clusters_per_index_record 1 MS Data 206848 30926847 30720000 [Recovery] NTFS, 15 GB / 14 GiB NTFS at 1925/27/23 filesystem size 146800625 sectors_per_cluster 8 mft_lcn 786432 mftmirr_lcn 16 clusters_per_mft_record -10 clusters_per_index_record 1 MS Data 30926848 177727472 146800625 [OS] NTFS, 75 GB / 69 GiB NTFS at 11063/6/15 filesystem size 146800625 sectors_per_cluster 8 mft_lcn 786432 mftmirr_lcn 16 clusters_per_mft_record -10 clusters_per_index_record 1 MS Data 177727487 324528111 146800625 NTFS, 75 GB / 69 GiB recover_EXT2: s_block_group_nr=0/39, s_mnt_count=12/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192 recover_EXT2: s_blocksize=4096 recover_EXT2: s_blocks_count 1310719 recover_EXT2: part_size 10485752 MS Data 324538368 335024119 10485752 [CentOS-6.4-x86_] EXT4 Large file Sparse superblock, 5368 MB / 5119 MiB recover_EXT2: s_block_group_nr=0/1593, s_mnt_count=9/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192 recover_EXT2: s_blocksize=4096 recover_EXT2: s_blocks_count 52227328 recover_EXT2: part_size 417818624 MS Data 335026176 752844799 417818624 [DataEXT3] EXT3 Large file Sparse superblock, 213 GB / 199 GiB recover_EXT2: s_block_group_nr=0/156, s_mnt_count=2/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8160 recover_EXT2: s_blocksize=4096 recover_EXT2: s_blocks_count 5119744 recover_EXT2: part_size 40957952 MS Data 752846848 793804799 40957952 [recover] EXT3 Large file Sparse superblock, 20 GB / 19 GiB FAT32 at 49412/48/45 FAT1 : 86-46154 FAT2 : 46155-92223 start_rootdir : 92352 root cluster : 6 Data : 92224-188741631 sectors : 188741632 cluster_size : 32 no_of_cluster : 5895294 (2 - 5895295) fat_length 46069 calculated 46057 FAT32 at 49412/48/45 MS Data 793806848 982548479 188741632 [DATAFAT32] ..................