ZimaOSサーバーを別のNASにバックアップする最も安全な方法は、オペレーティングシステム全体をクローンすることではなく、再インストール後も残す必要があるデータを保護することです。 ユーザーフォルダー、永続的なDockerアプリデータ、アプリケーションデータベースをLAN上の保存先にバックアップし、さらに異なるメディアまたはオフサイトに少なくとももう1つコピーを保管してください。
ZimaOSは、復旧用のデュアルシステムスロットを備えた軽量なアプライアンス型システムです。そのため、復旧モデルはSynology DSMの移行用バックアップとは異なります。OSは個別に復旧または再インストールでき、重要なデータはストレージボリュームやアプリに割り当てられたフォルダーに保存されます。したがって目標は、実行中のシステムをバイト単位で複製することではなく、復旧可能なサーバーを用意することです。
ZimaOSのバックアップには実際に何を含めるべきか？
有用なバックアップ計画は、再作成可能なソフトウェアと、失うと取り戻せないデータを分けることから始まります。DockerコンテナやApp Storeパッケージは、通常再作成できます。一方、ファイル、アプリの設定、データベース、メディアライブラリは再作成できません。
ユーザーフォルダーと共有データ
Documents、Media、Photos、プロジェクトフォルダー、Webサイトのデータ、その他ユーザーやアプリケーションが頻繁に変更するディレクトリをバックアップしてください。現在のZimaOS 3-2-1バックアップガイドは、LAN、USB、クラウド、Zima間のコピー元と保存先に対応しています。
永続的なDockerアプリデータ
App Storeのコンテナは使い捨てにできますが、そこに割り当てられたフォルダーはそうではありません。ZimaOSのドキュメントによると、設定や永続ファイルは、設定されたApp Dataの保存場所にあるコンテナ外部に保存されます。バックアップ対象を決める前に、ZimaOSのアプリストレージパスを確認してください。
データベースと状態を保持するサービス
Nextcloud、WordPress、Home Assistant、Immich、MariaDB、PostgreSQLを利用するアプリケーションなどでは、稼働中のデータディレクトリをコピーするだけでは不十分な場合があります。上流のアプリケーションがデータベースダンプ、エクスポート、メンテナンス手順を提供している場合は、それを使用してください。整合性のない状態で書き込み中のデータベースをコピーするよりも、正常なデータベースバックアップとアプリの設定フォルダーを組み合わせた方が、通常は移植性に優れています。
LANバックアップジョブの構築方法
ステップ1：保存先のマシンを決める
Synology、別のNAS、ファイルサーバー、または別のZimaデバイスは、いずれもZimaOSから書き込み可能な共有フォルダーにアクセスできれば、LAN上の保存先として利用できます。共有領域に十分な空き容量があり、ZimaOSが使用するアカウントに、保持ポリシーで必要となるファイルの作成、変更、削除権限があることを確認してください。
ステップ2：データの種類ごとに個別のバックアップタスクを作成する
特別な理由がない限り、すべてを1つの巨大なジョブにまとめないでください。重要なドキュメント、メディア、アプリデータ、その他のカテゴリごとに独立したタスクを作成します。これにより、失敗の原因を特定しやすくなり、失うと取り戻せないデータに、再作成可能なメディアよりも頻繁なスケジュールを設定できます。
ステップ3：ジョブをスケジュールしてテストする
最初のバックアップは手動で実行し、保存先に想定したファイルが含まれていることを確認してから、スケジュールを有効にしてください。タスクの状態が緑色であるだけでは不十分です。いくつかの復元ファイルを開き、権限、ファイル名、タイムスタンプが許容できる状態か確認してください。
Dockerアプリはどのようにバックアップすべきか？
重要なのは、コンテナの一時ファイルシステムではなく、コンテナに割り当てられたホストパスをバックアップすることです。現在のZimaOSガイドでは、App Dataを小容量のシステムドライブではなく、メインのストレージプールに保存することを推奨しています。これにより、バックアップ対象の範囲も把握しやすくなります。
カスタムDocker Composeスタックを使用している場合は、Compose YAML、環境変数、カスタム設定ファイル、シークレットのコピーを保護された場所に保管してください。設定画面のスクリーンショットだけに頼らないでください。Composeファイルと永続データフォルダーがあれば、新しいハードウェア上でより簡単に再構築できます。
ZimaOSバックアップの概要は、各コピーをどこに保管するか計画する際に役立ちます。また、Dockerストレージの基礎では、コンテナとデータの境界について説明しています。
ZimaOSのシステム自体はどうすべきか？
ZimaOSにはデュアルスロットのシステム設計があります。現在のシステム復旧ガイドでは、一方のパーティションに問題がある場合に、もう一方のシステムスロットから起動する方法を説明しています。
この復旧方法は一部のOS障害から保護してくれますが、データバックアップの代わりにはなりません。システムディスク自体が故障した場合、実際の復旧手順は、ZimaOSを再インストールまたは復旧し、ストレージを再接続または再作成してから、アプリを再インストールし、永続的なアプリデータとユーザーファイルを復元することになります。
単一のLANコピーではなく3-2-1ルールを使う
別のNASへのLANバックアップは有用ですが、両方のデバイスが同じ盗難、停電、ランサムウェア攻撃、またはユーザーのミスの影響を受ける可能性があります。失うと取り戻せないデータについては、3-2-1方式に従ってください。つまり、3つのコピー、2種類の異なるストレージ、1つのオフサイトコピーを用意します。
たとえば、ZimaOS上に稼働中のコピー、Synology上にスケジュールされたコピー、さらに対応するクラウド保存先または別の場所に保管したローテーション式USBドライブに、暗号化したオフサイトコピーを保持します。
避けるべき一般的なバックアップの失敗
- Dockerイメージだけをバックアップする。 イメージは再度ダウンロードできます。重要なのはAppDataとデータベースです。
- RAIDをバックアップだと思い込む。 RAIDはドライブ故障には役立ちますが、誤削除、破損、ランサムウェアからは保護してくれません。
- 互換性を確認せず、ホストレベルのバックアップエージェントをインストールする。 ZimaOSは従来型の変更可能なDebianサーバーではないため、システムエージェントが保護されたOS設計と競合する可能性があります。
- 復元テストを一度も行わない。 復元したことのないバックアップは、単なる思い込みにすぎません。
- すべてのコピーを同じ筐体または同じ部屋に保管する。 これではデバイス単位またはサイト単位の損失から保護できません。
ZimaOSのバックアップが復旧可能かテストする方法
代表的な小規模のセットを選びます。1つのドキュメントフォルダー、1つのメディアファイル、1つのアプリ設定ディレクトリ、1つのデータベースエクスポートを用意します。これらを一時的な場所に復元し、ファイルを開いて、アプリが復元データを読み取れることを確認してください。ストレージやアプリケーションに大きな変更を加えた後は、このテストを繰り返します。
重要なサーバーでは、ストレージ名、アプリのポート、カスタムComposeスタック、データベースの復元コマンド、ドメインやリバースプロキシの依存関係を記載した簡潔な復旧メモも保管してください。このドキュメントは、未加工のシステムイメージよりも多くの時間を節約してくれることがあります。
よくある質問
ZimaOSはSynology Hyper Backupのようなシステム全体のイメージを作成できますか？
現在のZimaOSドキュメントは、OS、すべてのアプリ、すべての設定を異なるハードウェア上で再現する、ワンクリックの移行用イメージではなく、データバックアップとシステムスロットの復旧を中心に説明しています。
SynologyをZimaOSのバックアップ先として使用できますか？
はい。アクセス可能なSMB/LAN共有は、バックアップ設計の一部として利用できます。依存する前に、認証情報、空き容量、復元時のアクセスを確認してください。
Dockerコンテナ自体をバックアップする必要はありますか？
通常はありません。Compose定義、アプリケーション設定、割り当てられたAppData、データベースを保存してください。コンテナとイメージは通常、再作成できます。
ZimaOSのシステム復旧で、削除したユーザーファイルも復元できますか？
いいえ。スロット復旧が対象とするのはオペレーティングシステムの層です。削除または破損したユーザーデータには、別途バックアップが必要です。
