☰

rsyncを使用してルートのディレクトリからルートを復元できますか？

tag-icon • tag-icon rsync backup root
rsyncを使用してルートのディレクトリからルートを復元できますか？

私が期待するイベントの順序は次のとおりです。

ほとんどのルートディレクトリのバックアップ

sudo rsync -aAXv --delete --exclude={/dev/*,/proc/*,/sys/*,/mnt/*,/media/*} / /BACKUP

反転プロセス

sudo rsync -aAXv --delete --exclude={/dev/*,/proc/*,/sys/*,/mnt/*,/media/*} /BACKUP /

私は最初に完全な確認をせずにパート2を試すことについて緊張したので、この記事を書いています。出力は--dry-runすべて良く見えますが、まず確認したいです。

答え1

rsyncを使用したシステム全体のバックアップの回復には、次のことが正常に使用されました。

バックアップコマンド：

sudo rsync -aHAXS --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /* /backup

-Hハードリンクも追加しました。私はそれを使用することをお勧めします。そして、-Sファイルがまれな場合。仮想マシン用としてたくさん持っています。

復元するには、ライブCD / USBを使用して新しくフォーマットされた空のディスクをマウントし/mnt、

回復コマンド：

sudo rsync -aHAXS --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /backup/* /mnt

今後起こること/etc/fstab（/mnt/etc/fstab）をよく見てgrub.cfg、再起動するとうまくいくでしょう。

除外に関しては、lost+foundXFSなどの一部のファイルシステムでは使用できないため、これらのファイルシステムを使用する場合を含めても問題はありません。

答え2

実際に最高の健全性チェックはバックアップから起動。
実際のテストで100％確信できる唯一の方法です！
私が知っている限り、ルートディレクトリ内のフォルダではこれを行うことはできません。 （実際に私が使用しているターゲットは「ルートツリー内のフォルダ」ですが、/media/$USER/RootBackupでは実際には別のファイルシステムです。）すぐに使用するためにバックアップを復元する必要もなく、ただ急な場合や悪いこと発生した場合は、バックアップから起動してそこから復元してください！

を使用すると、rsync必要に応じて非常に迅速にルートバックアップを更新できます。私はUbuntu 20.04でカーネルと他のコアパッケージを更新する前に毎回これを行います。

観察：LVMも使用している場合は、LVMスナップショットを非常に遅いオプションで破棄してください。

私はこのコマンドを使用しています。
sudo rsync -axHAXv --delete-excluded / --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /media/$USER/RootBackup/
次に、数回実行して、重要なファイルが変更されていないことを確認します。
--delete-excludedの重要性は、実際に同期を維持することです（同じ）。

また、/bootはそこにマウントされた別のパーティションなので、別々にバックアップしました。
sudo rsync -axHAXv --delete-excluded /boot/ --exclude=/lost+found /media/$USER/RootBackup/boot/

初めて実行した後、次のことを行いました。
grub-update
しかし、ここではうまくいかず、私が作成した新しいファイルシステムではなくLVMデバイスを指しているので、次のようにしました。

mount |grep RootBackup #copy the device name, ex.: sdb4
ls /dev/disk/by-uuid/ -l |grep sdb4 # copy the UUID ex.: 4e97fe69-93ae-4e6a-a2cc-3406cb21176c

grub-updategrub.cfgから/boot/grub/custom.cfgに新しいメニュー項目をコピーします。 （私はここでgptを使用しています。これは必要ないかもしれません。必要に応じて作成されたメニュー項目をコピーして変更するだけです。）

menuentry 'RootBackup by UUID' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'osproberfailed-manualadjustment-gnulinux-simple-4e97fe69-93ae-4e6a-a2cc-3406cb21176c' {
    insmod part_gpt
    insmod ext2
    set root='hd3,gpt13'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd3,gpt13 --hint-efi=hd3,gpt13 --hint-baremetal=ahci3,gpt13  4e97fe69-93ae-4e6a-a2cc-3406cb21176c
    else
      search --no-floppy --fs-uuid --set=root 4e97fe69-93ae-4e6a-a2cc-3406cb21176c
    fi
    linux /boot/vmlinuz root=UUID=4e97fe69-93ae-4e6a-a2cc-3406cb21176c ro quiet splash $vt_handoff debug --verbose
    initrd /boot/initrd.img
}

観察：メニュー項目を自動的に作成した後に必要な重要な修正grub-updateは次のとおりです。

  • 正しいUUIDが設定されていることを与えます。完全バックアップは単一パーティションで終了するため、searchコマンドは同じUUIDを使用します。linux
  • vmlinuzとinitrdは "/boot/"で検索する必要があり、自動シンボリックリンクを使用して維持する必要はありません。
  • root=UUID=.../dev/sdb4がランダムにsdc4に変更され、信頼できないため、linuxコマンドを使用する必要があります。
  • PARTUUIDは機能しないので使用しないでください。

復元するには、バックアップから起動します。これにより、ソースパスは/になり、ターゲットパスはインストールする必要がある別のパスになります。

あまりにも長い間、デフォルトのルートバックアッププロセスを実行していない場合に備えて、次の手順を実行します。

  • 作業中のバックアップルートから起動
  • 作るプライマリルートFSからの2番目のバックアップ
  • 作業中のバックアップルートをデフォルトルートFSに復元する
  • デフォルトルートFSからの起動
  • 欠落している項目や不正な項目が見つかった場合は、作成した2番目のバックアップから必要な項目を取得します。

中断することなく、重要なシステムファイルを重要なアップデートに更新することなく、デスクトップコンピュータで今のように心の平和を享受することを願っています。 :)

関連情報