資料のUrBackupインストールは、正常に動作するまでに複数の独立した理由で失敗しました。イメージ取得が中国本土専用のミラー経由に書き換えられていたこと、最初のバインドパスがZimaOSホスト上に存在しなかったこと、バックアップディレクトリの権限が誤っていたこと、そしてアプリランチャーのURLとポートが分かりにくかったことです。
重要な教訓は、UrBackupを通常の状態保持型Dockerアプリケーションとして扱うことです。実在するホストストレージパスを使用し、バックアップデータとUrBackupのデータベース／状態の両方を永続化し、実行ユーザーの権限を確認し、クライアントのバックアップを任せる前にWebUI、ネットワーク、リスナーを確認してください。
最初のイメージ取得は使用できないミラーに書き換えられた
デーモンは、次のイメージに対するプル拒否メッセージを返しました。 docker.1panel.live/uroni/urbackup-server公式UrBackupダウンロードページでも、現在は uroni/urbackup-server 公式Dockerイメージとして。
現在の公式UrBackup Dockerイメージを参照してください。
バインドマウントは実在するZimaOSホストフォルダーを指す必要がある
動作した構成では、次のような実際のストレージを使用していました。 /media/Safe-Storage/UrBackup/backups および /media/Safe-Storage/UrBackup/dataを /backups および /var/urbackup実際のホストパスを確認し、資料にあるストレージ名をそのままコピーしないでください。
権限拒否はコンテナユーザーが書き込めないことを意味する
この資料では 「/backups/urbackup_tmp_files」にアクセスする権限がありません修正では特定のUID/GIDと、それに対応するホスト側の所有者設定を使用しました。 1000:100 普遍的な識別子として使用します。現在の実行ユーザーを確認してください。
バックアップとUrBackupの状態の両方を保持する
リポジトリにはクライアントのバックアップデータが含まれており、 /var/urbackup サーバーのデータベースと状態を含みます。実用的な復旧計画では、必要に応じて両方を保持する必要があります。
この資料ではホストネットワークを使用した
保守されている uroni/urbackup-server このイメージでは、ホストネットワークをサポートされているDockerパターンの1つとして現在案内しており、UrBackupの標準サービス用ポートを公開しています。ホストネットワークを使うと検出は簡単になりますが、Dockerネットワークによる分離はなくなります。
WebUIには正しいポートが必要
この資料では、ZimaOSランチャーのポートを55414に修正しました。ランチャーは便宜的なURLにすぎないため、実際のサービスの稼働状況はログとリスナーで確認してください。
再現可能なCompose定義を優先する
現在のZimaOS App Store 2.0およびカスタムアプリのワークフローでは、標準のDocker Composeがサポートされています。イメージ、永続パス、タイムゾーン、再起動ポリシー、ネットワークを1つのCompose定義にまとめてください。
現在のZimaOS Composeモデルを使用してください。
ダッシュボードが稼働しているだけでは最終テストにならない
1台のクライアントを登録して小規模なバックアップを完了し、コンテナまたはホストを再起動してから、ファイルを復元します。これにより、ネットワーク、権限、データベースの永続性、バックアップストレージをまとめて検証できます。
バックアップリポジトリはシステムディスクではなくデータストレージに配置する
UrBackupは数百GB以上を消費する可能性があります。リポジトリパスは、容量と健全性が把握されている実際のZimaOSストレージ領域を指す必要があり、小容量のオペレーティングシステム用ドライブを指してはいけません。
クライアントを登録する前に、ZimaOS上のホストパスを確認し、最初のフルバックアップ中に空き容量を監視してください。
UrBackupデータベースは復元システムの一部です
下のファイルは /backups 使用可能なサーバーの一部にすぎません。UrBackupの状態データベースは /var/urbackup クライアント、バックアップメタデータ、保持設定、サーバー構成を追跡します。
両方の永続マッピングを記録して保護し、コンテナを再作成しても、期待されるサーバー状態を伴わないバックアップファイルが大量に残らないようにします。
最小権限の書き込みアクセスを使用する
出典固有のUID/GID調整で1つのデプロイメントは修正できましたが、ストレージプール全体の所有権を再帰的に変更するのは危険です。専用のUrBackupディレクトリを作成し、NAS内の無関係なデータに広範な書き込み権限を与えるのではなく、コンテナのIDにそのディレクトリへのアクセス権を付与してください。
ホストネットワークによりUrBackupサービスがZimaOS上に直接公開される
ホストネットワークを使用すると、UrBackupのリスナーはホスト上のリスナーになります。ZFWなどのファイアウォールでNASを保護している場合は、バックアップや検出に必要なポートとクライアントネットワークのみを許可してください。UrBackupのサービスポートをパブリックインターネットに直接公開しないでください。
バックアップサーバーの完了と判断する前に復元をテストする
1台のクライアントのバックアップを最後まで完了し、ZimaOSを再起動するかコンテナを再作成し、クライアント履歴が残っていることを確認してから、複数のファイルを別の場所に復元します。これにより、イメージの可用性、権限、永続状態、ネットワーク、実際の復元可能性を、緑色のダッシュボード表示だけでなく検証できます。
ZimaOS上のUrBackup FAQ
出典のユーザーは最終的にUrBackupを動作させられましたか？
はい。
すべてのZimaOSシステムでPUID 1000とPGID 100を使用すべきですか？
いいえ。これらは出典固有の値でした。
ホストネットワークは必須ですか？
一律ではありません。これは文書化されたイメージオプションで、出典では正常に使用されていましたが、ネットワーク分離が弱まります。
