rsyncでVPSデータを安全に移行する

コピー前に一覧化する

アプリケーションファイル、所有者、ACL、拡張属性、データベース、秘密情報、定期ジョブ、サービス、ファイアウォール規則、DNS、証明書、外部ストレージを一覧化してください。宛先の容量が十分であり、利用者、ファイルシステム、OSパッケージ、アプリケーションの版に互換性があることを確認します。切り替え前にDNS TTLを短くするのは、その変更がDNS計画に合う場合だけにしてください。キャッシュされたレコードは想定より長く残る場合があります。

送信元の独立したバックアップを作り、検証します。最初の転送中は送信元を変更せず、利用可能な状態に保ってください。保守時間を告知する前に、成功判定とロールバック判断を定義します。

• /proc、/sys、/dev、/runなどの仮想ファイルシステムを通常データとしてコピーしない。
• 必要に応じて、データベース固有のバックアップ、複製、ダンプ用ツールを使う。
• 秘密鍵をコマンド履歴や共有メモに決して残さない。

予行実行でアプリケーションデータを段階的にコピーする

/srv/app/のようなディレクトリでは、送信元からsudo rsync -aHAX --numeric-ids --info=progress2 --dry-run -e "ssh -i /root/.ssh/migration_key" /srv/app/ admin@DESTINATION:/srv/app/を実行して操作を試します。利用者、鍵のパス、宛先、データのパスを置き換えてください。末尾の斜線は、ディレクトリ階層を一つ増やすのではなく、送信元ディレクトリの内容をコピーすることを意味します。

すべてのパスとエラーを確認してください。遠隔アカウントが宛先へ安全に書き込めることを確認します。rootログインは不要で、多くの場合無効です。予行実行の結果が正しければ、--dry-runを外して同じコマンドを実行します。ディレクトリを同じにするという理由だけで--deleteを追加しないでください。送信元または宛先を誤ると、重要なデータを削除する可能性があります。

• 大規模転送では永続的な端末セッション内でコマンドを実行する。
• コピーが本番通信に影響する場合は帯域を制限する。
• 移行記録にコマンドオプションとツールの版を残す。

書き込みを静止して最終実行する

アプリケーションを文書化した保守状態または読み取り専用状態にします。対応する手順で正確な書き込みサービスを停止し、最終データベースバックアップまたは複製を完了してください。同じrsyncコマンドを再実行し、変更されたファイルデータだけを転送します。検証が完了するまで保守状態を維持してください。

意図した構成で宛先のサービスを起動し、可能なら最初は外部アクセスを制限します。状態、ログイン、書き込み、キュー、証明書、ログ、依存先を確認してください。試験に通った後でのみDNSまたは経路を更新します。複合リスクを明示的に受け入れない限り、同じ時間枠でアプリケーションの版とホスティング所在地の両方を変更しないでください。

• 最終書き込み停止時刻と同期結果を記録する。
• ファイル所有者と強制アクセス制御を確認する。
• DNS切り替え中は旧・新両方のエンドポイントを監視する。

検証、観測、ロールバック維持

より詳しくファイルを比較するには、適切な時間帯に元のrsyncコマンドへ--checksum --dry-runを付けて実行します。チェックサムは両方のデータセットを読み、高負荷になる場合があります。データベースとオブジェクトストレージでは、アプリケーションレベルの整合性検査を優先してください。切り替え後は、エラー、遅延、リソース使用量、バックグラウンドジョブ、外部コールバックを監視します。

ロールバック期間が終わるまで送信元をそのまま維持し、スプリットブレインの書き込みを防いでください。その後、保存・安全な削除計画に従います。バックアップ、監視、文書、復旧手順が宛先を参照するようになって初めて、移行は完了です。