VPS移行チェックリスト: バックアップ、DNS、TLS、ロールバック
セルフホストアプリケーションの実用的な移行手順: 棚卸し、一貫性のあるバックアップ、テスト済みの宛先、制御された書き込み、DNS カットオーバー、復元経路。
概要
制御されたVPS移行は、サービスとデータを棚卸しし、一貫性のあるバックアップを作成し、復元された宛先を検証し、ホスト名と TLS ルーティングをテストし、最終書き込みと DNS を調整し、データを考慮したロールバックを保持します。チェックリストだけでダウンタイムゼロを保証するものではありません。
移動する前にアプリケーションを棚卸しする
アプリケーションが動作するために必要なサービス、バージョン、ポート、スケジュールされたタスク、データベース、アップロードされたファイル、構成を列挙します。書き込みがどこで発生し、どの外部サービスに依存しているかを特定します。データが別の場所にある場合、ウェブディレクトリをコピーしただけでは完全な移行ではありません。
現在の DNS 名、アクティブな IPv4 と IPv6 レコード、証明書更新方法、復旧アクセス経路を記録します。シークレットは非公開のデプロイツールに保管してください。パスワード、秘密鍵、データベースダンプを公開ドキュメントルートや共有移行チェックリストに置かないでください。
一貫性のあるバックアップを作成し、復元できることを証明する
書き込みが続いている間に任意のファイルをコピーするのではなく、データベースがサポートするバックアップ機構を使用してください。SQLite の場合、オンラインバックアップ API が一貫性のあるデータベーススナップショットを作成します。WAL モードでは、WAL ファイルが永続的なデータベース状態に関与するため、メインデータベースファイルだけをコピーするとコミット済みの変更が欠落する可能性があります。
一貫性のあるデータベースバックアップは、別々に保存されたアップロード、キュー、ファイルと自動的に一貫しているわけではありません。アプリケーションと調整して取得してください。別のテスト場所に復元し、そのバックアップが使用可能とみなす前にレコード、ファイル参照、アプリケーションの挙動を検証してください。
DNS を変更する前に宛先を準備する
新しいサーバー上に予定しているユーザー、権限、ランタイムバージョン、サービス、アプリケーションディレクトリを作成します。テストバックアップを、該当する場合は公開ウェブルート外の宛先データ場所に復元します。実際にアプリケーションを実行するサービスアカウントを使用して、所有権とアクセスを確認してください。
共有サーバー上の無関係なサイトを保持します。専用のドキュメントルート、仮想ホスト、ランタイムを使用し、ウェブサーバー構成を検証し、この変更が所有するファイルと構成のみを復元するロールバックを準備してください。
新しいサーバーで実際のホスト名と証明書をテストする
ベアIPアドレスへのブラウザリクエストは、ホスト名ベースのルーティングや証明書検証を再現しません。curl --resolve を使用すると、通常のホスト名と TLS チェックを保持したまま、テストで意図したホスト名と選択した宛先IPを使用できます。HTTPステータスと期待されるアプリケーション内容も確認してください。例ではドキュメント専用の値を使用しています。自分の確認済みドメインと宛先に置き換えてください。
そのテストが成功するには、有効な証明書と許可されたネットワーク経路がすでに存在している必要があります。移行準備完了というために証明書検証を無効にしないでください。DNS ベースの ACME 検証は、ウェブサーバーアドレスを変更せずにドメインを検証できます。HTTPベースの検証では到達可能性の要件が異なります。初回発行とは別に更新をテストしてください。
curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/書き込み制御と最終同期の計画を選ぶ
短いメンテナンス期間、またはアプリケーションに適した別の一貫性機構をスケジュールします。特定した書き込み側を停止またはリダイレクトし、最終的な一貫性のあるデータベースバックアップを取得し、対応する可変ファイルを同期し、結果を検証します。公開インターフェースが静かに見えても、キューワーカー、Webhook、cronタスクは書き込むことがあります。
ファイル同期の前にドライランを使用してください。ショートカットとして削除フラグを追加したり、システムディレクトリ全体をコピーしたりしないでください。新しいアプリケーションを確認し、書き込みに対してどの場所が権威であるかを確立するまでは、古いサービスを復旧可能な状態に保ってください。
DNS を変更し、両方のアドレスファミリを観察する
サービスに必要なレコードを更新し、既存のリゾルバキャッシュを考慮します。権威応答と複数の通常クライアント経路を確認してください。古い AAAA レコードがアクティブなままの場合、IPv6 クライアントは古いサーバーに到達し続け、IPv4 クライアントは新しいサーバーに到達することがあります。
新しいサービスでサインイン、読み取り、書き込み、アップロード、バックグラウンドジョブ、外部コールバックをテストします。移行中に同じアプリケーションの独立した書き込み可能コピーを2つ実行しないでください。まだ古い宛先に到達するトラフィックの処理について明確なルールを維持してください。
ロールバックを DNS の判断だけでなくデータの判断にもする
ロールバックをトリガーする障害条件と、カットオーバーを制御する人を定義します。新しい書き込みが宛先に到達した後は、DNS を元に戻すだけでは不十分です。古いコピーに戻る前にそのデータを保持または調整する必要があります。
適切な復旧期間、ソースとバックアップを保持します。宛先、バックアップ、更新、監視が確認された後にのみ、古いアクセスを削除し、リソースを退役させてください。保持と削除は、一般的な固定時間数ではなく、実際のサービス方針に従うべきです。