バックアップと復旧

Last updated
Tags Server v2.x 管理者

ここでは Services マシンのフェイルオーバーや交換について説明します。 Services マシンの定期的なバックアップイメージまたはスナップショットを実装するためのバックアップ戦略および手順については、以下の「バックアップ」セクションを参照してください。

災害復旧

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

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

CircleCI データのバックアップ

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

CircleCI を HA 構成で実行している場合、外部データストアの標準のバックアップ機構を使用する必要があります。 より詳細なドキュメントは、support@circleci.com にお問い合わせ下さい。

データベースのバックアップ

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

「Snapshots Disabled 」とは、Replicated の内蔵スナップショット機能がデフォルトでオフになっていることを指します。

オブジェクトストレージのバックアップ

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

AWS EBSのスナップショットの作成

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

  1. 手動でバックアップを作成するには、EC2 コンソールでインスタンスを選択し、[アクション] > [イメージ] > [イメージの作成] を選択します。

  2. ダウンタイムを避けたい場合は、[再起動しない] オプションを選択します。 リストア用の新しい EC2 インスタンスとしてすぐに起動できる AMI が作成されます。

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

バックアップからのリストア

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

  1. 先述の手順で新たに作成された AMI を使用して、新しい EC2 インスタンスを開始します。

  2. 管理コンソール (ポート8800) で実行されているアプリがあれば、停止します。

  3. 管理コンソールのポート8800 で設定されているホスト名が、正しいアドレスを反映していることを確認します。 ホスト名が変更されている場合、対応する GitHub OAuth アプリケーションの設定も変更するか、新しい OAuth アプリケーションを復旧テスト用に作成し、そのアプリケーションにログインする必要があります。

  4. Debian/Ubuntuの`/etc/default/replicated`および`/etc/default/replicated-operator`、または RHEL/CentOS の`/etc/sysconfig/*`にある、バックアップされたインスタンスの公開および非公開 IP アドレスへの参照をすべて、新しい IP アドレスに変更します。

  5. Services ボックスのルートディレクトリから、sudo rm -rf /opt/nomad`を実行します。 状態が `/opt/nomad フォルダに保存され、インストールをバックアップからリストアする際に実行されるビルドに支障をきたす可能性があります。 このフォルダとその中身は、Nomad の起動時に再び作成されます。

  6. 管理コンソールのポート8800 で、アプリケーションを再起動します。

ビルドレコードのクリーンアップ

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

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

circleci dev-console
# コンソールのロードを待つ
user=> (admin/delete-build "https://my-circleci-hostname.com/gh/my-org/my-project/1234")


ドキュメントの改善にご協力ください

このガイドは、CircleCI の他のドキュメントと同様にオープンソースで、GitHub で使用できます。 ご協力いただき、ありがとうございます。