完全に準備ができているため、データとシステムを簡単に復元できるようにUbuntuシステムのバックアップを作成する必要があります。だからddフルHHD画像を作ることにしました。
私が作成した画像は次のとおりです。
dd if=/dev/current_drive of=/dev/backup_drive/backup.img conv=sync status=progress
画像がエラーなく完了しました。その後、新しいドライブをテストするためにイメージを復元することにしました。
dd if=/backup_drive/backup.img of=/dev/new_drive conv=sync status=progress
今まではそんなに良くなった。イメージの回復にエラーはありません。ただし、回復イメージの新しいハードドライブから起動しようとすると、initramfs次のエラーが発生します。
そのため、手動で実行した後、fsckエラーが解決され、新しいハードドライブから起動できました。しかし、イメージをドライブに復元するプロセスを数回試しましたが、毎回起動に問題が発生しました。私の元のシステムドライブと新しいシステムドライブによるとまったく同じです。
sudo fdisk -l:
/dev/sda/新しいハードドライブです。
/dev/sdb/画像が作成された元の画像。
Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xf11c2eb5
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 455024639 455022592 217G 83 Linux
/dev/sda2 455026686 488396799 33370114 15.9G 5 Extended
/dev/sda5 455026688 488396799 33370112 15.9G 82 Linux swap / Solaris
Disk /dev/sdb: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xf11c2eb5
Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 2048 455024639 455022592 217G 83 Linux
/dev/sdb2 455026686 488396799 33370114 15.9G 5 Extended
/dev/sdb5 455026688 488396799 33370112 15.9G 82 Linux swap / Solaris
もしそうなら、私が何が間違っているのか、イメージの復元後に起動エラーが発生する理由を知っていますか？元のハードドライブに障害が発生した場合は、新しいハードドライブを修理する必要がある実際の状況に遭遇したくありません。
しかし、元のドライブはSSDで、新しいドライブはHDDでした（重要な場合）。
ベストアンサー1
時をdd、
- ソースデバイス/ファイルシステムを変更/インストール/記録しないでください。
- と
conv一緒に使用しないでください。noerrorsync破損したデータ bs=1M（またはbs=64K）を次のように追加します。パフォーマンス上の理由
デフォルトでは、正常で一貫した直接ディスクコピーは、Live CDなどのスタンドアロンシステムを介してのみ達成できます。それでも注意してください。ユーザーが知らない間にファイルシステムが自動的にマウントされることに関連しています。
syncまた、読み取りエラー（したがってnoerrorその他のオプション）が予想される場合は、使用する方がconvより安定していますddrescue。読み取りエラーを正しく処理し、再試行および回復機能も備えています。
全体として、ブロックレベルのコピーはエラーが発生しやすいため、信頼できない傾向があります。これを行う唯一の理由は、これがコピーを作成する唯一の方法だからです。完璧な一貫性（正しく実行された場合のみ）。
他のすべての方法は十分実際には決して完璧ではありません。データの半分はメモリに、残りの半分はディスクに保持する実行中のプロセスの完全なコピーを作成する方法はありません。完全な画像を取得するには、この機能をオフにする必要があります。 （またはすべてを仮想化して凍結します。）
他のオプションもあります：
- cp、rsync、または専用バックアッププログラムを使用したファイルベースのバックアップボグ
- ファイルシステム固有のツール（xfsdump、btrfs転送/スナップショット...）
- 左心室容積スナップ写真（しかしbtrfsを使用しない)
- データベースは特別な処理を必要とし、独自のバックアップツールを提供します。
ブロックレベルのコピーである必要がある場合は、mdadmシステムを乱用してソースドライブにRAID 1レイヤーを配置し、それを使用してターゲットドライブを追加して、実行中のシステムから一貫したコピーを作成することもできます。 RAIDは両方のパーティを完全な同期状態に保ち、不一致の問題を大幅に防ぎます（ターゲットドライブを削除する前に同期を完了できるようにした場合）。
# RAID creation (before installing Linux)
mdadm --create /dev/md0 --level=1 --raid-devices=1 --force /dev/source
# /proc/mdstat
md0 : active raid1 sda2[3]
134306472 blocks super 1.2 [1/1] [U]
# Add the target drive.
mdadm --grow /dev/md0 --raid-devices=2 --force
mdadm --manage /dev/md0 --add --write-mostly /dev/target
# Wait for RAID resilvering.
mdadm --wait /dev/md0
sync
# Remove the target drive.
mdadm /dev/md0 --fail /dev/target
mdadm /dev/md0 --remove /dev/target
mdadm --grow /dev/md0 --raid-devices=1 --force
ただし、これはハッキングであり、コピーは正しくアンマウントされていないファイルシステムとして表示され続けます。sync予期せず停電した場合、これは実行できないため、これは停電より少し悪いです。しかし、dd画像の前半の状態が後半の状態より数時間遅れているよりもはるかに優れています。
私は毎週この方法を使用して、HDD待機をブロックせずに単一のSSDドライブをHDDにミラーリングします。 SSDに障害が発生すると、HDDが簡単に起動できます。
もちろん、ファイルベースのコピーを使用しても同じ目的を達成できます。
UUIDについて言及したので、ブロックレベルでドライブを複製すると、UUIDが複製され、結果として災害が発生する可能性があります。 （上記のRAID攻撃の場合、RAIDレイヤーの後ろに便利に隠されています。）
新しいファイルシステムへのファイルベースのコピーには新しいUUIDがありますが、回避策は非常に簡単です。
chroot、編集/etc/fstab、initramfsアップデート、ブートローダの再インストール（chrootメソッドはデフォルトですべてのLinux Wikiで見つけることができます）- それ以外の場合は、Change Old UUIDを使用して古いUUIDを復元します
tune2fs -U <UUID>。他のファイルシステムにも同様のツールがあります（文書が必要です。そうしないと、必要なUUIDがわかりません）。繰り返しますが、重複しないように注意し、古いデバイスが完全に消えた場合にのみこれを実行してください。