このコミュニティチュートリアルの2ページ目では、「ddをどう実行するか？」という判断を、「実際に何を保護する価値があるのか？」という判断へと変えています。ユーザーはすでに大容量の稼働中NVMeを使用しており、起動可能なOSを失うことよりも、DATAを失うことをはるかに重視していました。gelbuildingの助言は、稼働中のブートNVMeを再パーティションしないこと、まずDATAとAppDataを保護すること、そしてリカバリー時間の短縮効果が追加のバックアップ容量に見合う場合に限り、raw形式のシステムクローンを保持することでした。
この優先順位は、現在のZimaOSのアーキテクチャに適しています。OSには迅速な復旧のためのA/Bシステムスロットがある一方、置き換えのきかないユーザーデータ、AppData、ストレージメタデータは、これらの不変システムイメージの外部に保存されています。ディスク全体のクローンは、マシンを特定の時点の状態へ迅速に戻せますが、独立した世代管理付きDATAバックアップの代替にはなりません。
ddは小さなOSスロットだけでなく、デバイス全体をクローンする
元のチュートリアルでは、概念的に次のようなコマンドを使用しています。
dd if=/dev/NVME_DEVICE | gzip > USB_BACKUP.img.gzシステムが1 TBのNVMe上にある場合、rawイメージの作成処理はブロックデバイス全体を読み取ります。圧縮によってファイルサイズを小さくできる場合はありますが、バックアップ先と処理は、ZimaOSのシステムパーティションで使用している数GBだけでなく、物理ディスクのレイアウトに左右されます。
ddを小さくするためだけに、正常に稼働しているシステムを再パーティションしない
gelbuildingは、稼働中のブートNVMeの再パーティションを高リスクとしました。ミスによってダウンタイムやデータ損失が発生する可能性があるためです。現在のレイアウトが正常に機能している場合は、パーティション境界を変更する前に、検証済みのデータバックアップを作成してください。
OSクローンより先にDATAとAppDataを保護する
復旧可能性を優先する場合は、次のものをバックアップしてください。
- ユーザーファイルとストレージプール;
- 簡単には再作成できないAppData、データベース、設定;
- 重要なアプリ固有のエクスポート;
- 必要に応じて、
local-storage.dbなどのZimaOSストレージメタデータ; - その後、必要に応じてシステムディスク全体。
現在のZimaOS 3-2-1ガイダンスでは、独立した保存先へのスケジュール済みバックアップと、世代管理された復元ポイントが推奨されています。
現在のZimaOS 3-2-1バックアップモデルを使用してください。
現在のZimaOSには、すでにA/Bシステム復旧機能がある
ZimaOSは、約6 GBのシステムスロットを2つ使用します。一方のスロットに障害が発生した場合、現在の復旧ガイドでは、GRUBからもう一方のスロットを起動できます。
現在のA/Bシステム復旧手順を使用してください。
クリーンインストールでOSは再構築できるが、正確な環境が自動的に復元されるわけではない
constgenが指摘したように、不変OSは再インストールするだけで済む場合があります。これに対してgelbuildingは復旧時間を重視しました。ディスククローンなら、取得時点のアプリ、設定、システム状態を正確に復元できますが、再インストールではAppDataの再割り当て、アプリの再インストール、ストレージメタデータの再接続が必要になる場合があります。
どちらも有効な復旧戦略ですが、最適化する対象が異なります。
専用の小容量ブートディスクにすると、ディスク全体のクローンが簡単になる
gelbuildingは、最終的にZimaOSを小容量の32～64 GB専用デバイスへ移し、大容量のNVMeやRAIDストレージをDATA/AppDataとして使用することを推奨しました。現在のZimaOSのインストールに必要な最小容量は、正確には25 GB以上です。
これにより、分離しても問題のないOSと大容量データストレージを切り分けられ、完全なシステムイメージを大幅に小さくできます。
raw復元コマンドは破壊的である
ddイメージを復元すると、保存先ディスクに直接書き込まれます。誤った/dev/...の保存先を選択すると、別のドライブを破壊する可能性があります。元のチュートリアルはテスト用として明示的に共有されたものであり、これらのコマンドは、モデル名やシリアル番号でディスクを特定し、DATAを別の場所に保持した後にのみ使用してください。
バックアップの作成だけでなく、復旧手順もテストする
復元方法が分からなければ、バックアップは役に立ちません。DATAについては、代表的なファイルを復元してください。rawシステムイメージについては、実際の障害発生時にデバイスやパスの前提条件を確認することになるのを避けるため、可能であれば予備のメディアで手順をテストしてください。
ZimaOSのクローンとバックアップに関するFAQ
ZimaOSのデータを保護するために、システムディスク全体のクローンは必須ですか？
いいえ。DATA、AppDataのバックアップとストレージメタデータはA/Bシステムパーティションとは別に存在し、置き換えのきかない情報についてはこちらが優先されます。
それでもraw形式のOSクローンを保持する理由は何ですか？
手動で再構築する代わりに、取得時点のシステムやアプリの設定を正確に復元できるため、復旧時間を短縮できます。
クローンを小さくするためだけに、稼働中のNVMeを再パーティションすべきですか？
元の推奨事項は、すべきではないというものでした。まずDATAをバックアップし、不要な稼働中のパーティション変更は避けてください。
