バックアップパーティションは、ユーザーの対話なしでUUIDを変更します。

バックアップパーティションは、ユーザーの対話なしでUUIDを変更します。

最近、新しいハードドライブを購入する必要がありました。私がそこにいたので、提案されているように1つの代わりに2つを購入しました(どちらも同じモデルです)。 2番目のハードドライブにはまだ多くのスペースがあるため、ルートパーティションのフルバックアップにのみ使用します。

# single user mode.
# dd if=/dev/sda1 of=/dev/sdb3 bs=32M

その後、バックアップパーティションのUUIDを変更し、他のUUIDがあるかどうかを再確認しました。

# tune2fs -U random /dev/sdb3

その後数週間、すべてが順調に進み、毎日起動し、うまくいきました。

最近コンピュータを起動した後、突然実際のルートパーティション(sda1)の代わりにルートとしてバックアップパーティション(sdb3)が発生しました。

だから、コンピュータをシャットダウンして再起動した後、パーティションを再バックアップしました。起動コマンドラインを修正し、正しいデバイス(sda1)で直接起動し、何が起こっているかを確認しました。信じられないほどですが、バックアップパーティション(sdb3)は魔法のように実際のルート(sda1)と同じUUIDを持っています。

(未知の第三者の悪意のある操作がないと仮定した場合)どのようにこのようなことが起こりますか?システムですか? :)

私は自分が物理的にアクセスできる家庭用コンピュータでDebianテストを実行しています。

編集する:

  • バックアップスーパーブロックはすべてUUIDを修正しました。 dumpe2fsでこれを確認しました。
  • dump コマンドを再実行しませんでした。実際に私が最初に確認したのは、(すべてのbash履歴を検索して)再実行しなかったことです。
  • すべてのドライブのSMART情報を確認しました。構成リポジトリのすべてのバージョンを管理したので、スマート情報を以前のバージョンと比較しました。疑わしいことはありません。

答え1

まだテストしたことがないので、実際にそのようなことが起こるかどうかはわかりません。しかし、もし:

  1. sdb3のデフォルトのスーパーブロック(不良セクタなど)とバックアップスーパーブロックも失われました(確かに)。
  2. 自動的にスーパーブロックをバックアップしようとするとe2fsck(そうだがわからない)
  3. tune2fsメインスーパーブロックのみを更新してください。 (わかりません)

その後、fsckはバックアップからコピーして古いUUIDを復元し、デフォルトのスーパーブロックを復元します。

ddしかし、現実的には、更新バックアップを再実行してUUIDの変更を忘れる可能性が高いと思います。

partcloneまたはpartimageを見てみることをお勧めします。

関連情報