Discordソリューション

CasaOSサーバーを新しいハードウェアへ移行する方法

A user asked for a practical way to transfer an existing CasaOS server from one physical device to another.

最適な移行戦略:CasaOSをホストOS、アプリ定義、永続データの3層として扱います。CasaOSの再インストールは簡単です。重要なのは、コンテナが実際に使用するフォルダーと設定を保持し、新しいマシンで同じパスを再作成することです。

コピー前に棚卸しします

  • CasaOSとベースLinuxのバージョン。
  • コンテナイメージ、ポート、環境変数。
  • すべてのバインドマウントのソースパス。
  • /DATA/AppData カスタムアプリフォルダー。
  • メディア/データディスクのマウントポイント。
  • UID/GIDの所有権。
  • 固定IP、DNS、プロキシ、VPN、ファイアウォールのルール。

CasaOSのストアアプリは通常、/DATA/AppData/$AppIDにデータを保存します。CasaOS AppDataパターンは、Dockerコンテナだけをコピーしても移行にならない理由を示しています。

最終コピーの前に書き込みの多いアプリを停止します

コピー中にデータベースやアプリの状態が変化することがあります。最後のバックアップを作成する前に、関連するコンテナ、または最終同期の場合はDockerを停止します。

sudo systemctl stop casaos-app-management
sudo systemctl stop docker

次に、メタデータを保持できるrsyncなどのツールでコピーします rsync -aHAX ファイルシステムが対応している場合。

名前付きボリュームも棚卸しします

ホストのバインドマウントではなく、Dockerボリュームを使用するアプリもあります。Dockerの永続Dockerボリュームはコンテナより長く存続しますが、意図的に移行する必要があります。

まずストレージパスを再作成します

新しいホストでは、アプリを起動する前にディスクをマウントします。以前Jellyfinが使用していた場合 /DATA/Media/Movies同じパスに復元すれば、ライブラリの破損を避けられます。パスが変わる場合は、初回起動前にコンテナのマッピングを編集します。

数値形式の所有権を保持します

コンテナは数値のUID/GIDを使用します。旧システムと新システムで重要なディレクトリを比較します。

stat -c '%u:%g %a %n' /DATA/AppData/*

サービスを段階的に復旧します

  1. 対応しているLinuxベースをインストールします。
  2. CasaOSをインストールします。
  3. すべてのデータディスクをマウントします。
  4. 永続データを復元します。
  5. アプリ定義を再作成またはインポートします。
  6. 状態を保持するアプリを1つずつ起動します。
  7. データベース、メディア、権限、スケジュールを検証します。
  8. テストに合格してからIP/DNSのみを切り替えます。

CasaOSのDocker構造では、アプリデータとコンテナを別々に扱う理由を説明しています。CasaOSを再構築するのではなくZimaOSへ移行する場合は、セルフホスト型アプリプラットフォームが関連します。

コンパクトなx86置き換え環境には、ZimaBoard 2が小規模な構成に適しています。

各アプリを状態の種類ごとに分類する

すべてのコンテナを同じ方法で移行するわけではありません。

  • ステートレス: 設定はCompose/環境変数から再作成できます。
  • ファイルベース: バインドマウントされたフォルダーをコピーします。
  • SQLite: データベースファイルをコピーする前にアプリを停止します。
  • PostgreSQL/MySQL: 可能な場合は、稼働中のファイルシステムのコピーだけに頼らず、アプリケーション/データベースのバックアップを使用します。
  • 名前付きボリュームを使用するアプリ: Dockerボリュームを意図的にエクスポートまたはコピーします。

現在のDocker設定を取得する

重要な各コンテナについて、次を保存します。

docker inspect <container> > container-inspect.json

これはそのままインポートできるComposeファイルではありませんが、マウント、ポート、環境、ネットワーク、デバイスを記録しているため、再構築したサービスが以前のものと一致するか確認できます。

IPアドレスとホスト名の切り替えを計画する

クライアントがサーバーのホスト名を使用している場合、移行は簡単です。検証後にDNSを新しいIPアドレスへ向けます。すべてのアプリが古いIPアドレスにハードコードされている場合は、古いサーバーをオフラインにした後、新しいホストに以前の静的アドレスを割り当てる方法が適しているでしょう。

ロールバックが不要になるまで古いサーバーには手を加えない

最初のログインに成功した直後に、ソースを消去しないでください。少なくとも1回のバックアップサイクルと通常利用の期間が終わるまで、電源を切った状態でそのまま保持してください。これにより、スケジュールされたジョブ、データベース、リモートクライアントの見落としがあった場合に、既知の正常な状態へロールバックできます。

コンテナだけでなくデータを検証する

Dockerのステータスが緑色でも、プロセスが実行中であることしか証明できません。次を検証してください。

  • Jellyfinのライブラリと視聴状態。
  • Syncthingフォルダーの状態。
  • バックアップジョブと復元テスト。
  • データベースアプリケーション。
  • 外付けドライブのパス。
  • リバースプロキシの証明書。
  • リモートVPN/トンネルアクセス。

よくある質問

起動ディスクをクローンできますか?

場合によっては可能ですが、クローンにはハードウェア固有のネットワーク、起動、マウントに関する前提が引き継がれます。クリーンなホストにデータを復元するほうが、検証しやすいことがよくあります。

古いサーバーはいつ廃止できますか?

新しいホストで、アプリへのログイン、データベース、メディアパス、権限、スケジュールされたジョブ、バックアップ、リモートアクセスがすべて機能してからです。