バックアップと復旧

Services マシンの災害復旧用に同じ仕様の予備マシンを別の場所に設定します。 障害発生時に備えて、バックアップスナップショットを使ってホットスペアのイメージを定期的に作成することをお勧めします。

少なくとも、CircleCI のシステム管理者に、Services マシンの設定の最新のスナップショットを保有する代替サーバーをインストールする同等のサーバーのホスト名と場所（同じ場所の場合も含む）を通知します。 イメージをバックアップイメージに置き換えたインストール手順により復旧を完了します。

このドキュメントでは、CircleCI アプリケーションをバックアップし、事故や予期しない理由により Services マシン内の CircleCI データが消失した場合の復旧方法について説明します。

CircleCI を外部サービス用に設定*していない*場合、CircleCI データをバックアップするためのベストプラクティスとして、Services マシンのルートボリュームとして機能する、仮想ディスクの VM スナップショットを使用することをお勧めします。 基盤となる仮想ディスクが、AWS EBSと同様に動作をサポートしていれば、ダウンタイムなくバックアップを実行できます。 再起動せずにスナップショットを作成すると、ファイルシステムと分散によっては一部のデータが破損してしまうリスクが僅かにありますが、これは実際には稀です。

ビルドアーティファクト、出力、キャッシュは、通常 AWS S3 などのオブジェクトストレージサービスに保存されます。 これらのサービスは冗長性が高いため、別のバックアップを必要とする可能性は低いと考えられます。 ただし、インスタンスがディスク上に直接、または NFS ボリューム上で、Services マシンに大きなオブジェクトをローカルに保存するようセットアップされている場合は例外となります。 この場合、これらのファイルを別にバックアップし、リストア時に必ず同じ場所へマウントされるようにする必要があります。

AWS EBSスナップショットには、バックアップ処理を簡単にするため、いくつかの機能が搭載されています。

また、AWS APIを使用して、このプロセスを自動化することもできます。 それ以後の AMI やスナップショットは、前回のスナップショットから異なる分 (変更されたブロック) の大きさしかないため、頻繁にスナップショットを作成してもストレージコストが必ずしも増加するわけではありません。詳細については、 Amazon EBS スナップショットの利用料金 を参照してください。

テスト用バックアップのリストア、または本番環境でリストアを実行するとき、公開または非公開 IP アドレスが変更されている場合は、新たに開始されたインスタンスにいくつかの変更が必要になることがあります。

ファイルシステムレベルのデータインテグリティーの問題は稀であり、防止可能ですが、ビルドがシステムで実行中の特定の時間に作成されたバックアップでは、一部のデータ異常の可能性が高くなります。 たとえば、バックアップの時点でビルトが半分しか完了していなかった場合、コマンド出力の後半が存在せず、アプリケーションは恒久的に実行中の状態として表示される可能性があります。

復旧後に、データベース内の異常なビルドレコードをクリーンアップするには、Servicesマシンで次のコマンドを実行します。例のビルド URL を、CircleCI アプリケーションの実際の URL に置き換えてください。