最近、新しいハードドライブを購入する必要がありました。私がそこにいたので、提案されているように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
まだテストしたことがないので、実際にそのようなことが起こるかどうかはわかりません。しかし、もし：
- sdb3のデフォルトのスーパーブロック（不良セクタなど）とバックアップスーパーブロックも失われました（確かに）。
- 自動的にスーパーブロックをバックアップしようとすると
e2fsck（そうだがわからない） tune2fsメインスーパーブロックのみを更新してください。 （わかりません）
その後、fsckはバックアップからコピーして古いUUIDを復元し、デフォルトのスーパーブロックを復元します。
ddしかし、現実的には、更新バックアップを再実行してUUIDの変更を忘れる可能性が高いと思います。
partcloneまたはpartimageを見てみることをお勧めします。