複数のクライアントサイトを管理するWordPress制作会社にとって、強固なバックアップ戦略は欠かせません。予期せぬ障害、プラグインの不具合、人為的なミスが生じた場合でも、バックアップでデータを迅速に復元できれば、サイトのダウンを最小限に抑え、リスクを軽減することができます。
Kinstaでは、バックアップが果たす重要な役割を理解し、毎日の自動バックアップ、手動バックアップ、システム生成バックアップ、ダウンロード可能バックアップ、さらに時間単位(1時間または6時間ごと)のバックアップと外部バックアップ(Amazon S3またはGoogle Cloud Storage)アドオンの全6種類のバックアップを提供しています。
バックアップの管理は、コントロールパネルのMyKinstaから簡単に行えますが、KinstaのAPIを利用して、反復的なタスクを自動化することも可能です。
Slackでコマンドを入力したり、MyKinstaの企業アカウントのすべてのWordPressサイトのバックアップをトリガーするcronジョブを設定するだけで、何十、何百ものサイト管理画面を手動で移動して操作する必要がなくなります。
このように顧客の要件を優先するサーバーサービスを選ぶことで、生産性向上を目指した独自のソリューションを構築できるのは、大きなメリットです。
今回は、Kinsta APIを活用して複数のサイトのバックアップを自動化する方法をご紹介します。お好きなスタックとの統合、Slackのようなツールの使用、またはスケジュールの設定など、バックアッププロセスを合理化し、ワークフローを強化するのに役立つはずです。
全サイトまたは特定のサイトのバックアップを実装する方法
作業に入る前に、まずはMyKinstaアカウント内のすべてのサイトのバックアップをトリガーする方法と、Kinsta APIを使用して特定のサイトや環境のバックアップをトリガーする方法を理解しておきましょう。
バックアップ作成の基本を押さえておけば、プロセスの自動化を簡単に統合することができます。
MyKinstaアカウント内の全サイトのバックアップをトリガーする
すべてのAPIに言えることですが、1つのエンドポイントで必要な操作をすべて行えるとは限りません。期待する結果を得るには、複数のエンドポイントを組み合わせる必要があります。
Kinsta APIも同様で、バックアップ管理用のエンドポイントはありますが、各エンドポイントは環境IDのような特定のパラメータを必要とし、他のエンドポイントに追加のリクエストを行うことで取得します。
例えば、サイトの手動バックアップをトリガーするには、その環境のIDが必要です。そして環境IDを取得するには、サイトIDが必要になります。つまり、サイトIDの取得、環境IDの取得、そしてバックアップのトリガーと、複数のAPI呼び出しを行わなければなりません。
ステップ 1. Kinsta APIですべてのWordPressサイトを取得する
最初のステップは、MyKinstaアカウントに紐づけられているすべてのサイトを取得します。Kinsta APIは、サイトIDやサイト名など、関連情報を含むデータを取得するエンドポイントを提供しています。GET /sites
エンドポイントを使用すると、企業アカウントにあるすべてのサイト一覧を引き出すことができます。
以下は、Node.jsとFetch APIを使用した例です。
require('dotenv').config();
const KINSTA_API_URL = 'https://api.kinsta.com/v2';
const API_KEY = process.env.KINSTA_API_KEY;
async function getAllSites() {
const response = await fetch(`${KINSTA_API_URL}/sites`, {
headers: {
Authorization: `Bearer ${API_KEY}`
}
});
const data = await response.json();
return data.company.sites; // すべてのサイトの配列を返す
}
この関数は、アカウント内のすべてのサイトの配列を返します。各サイトには、サイトID、サイト名、環境などの情報が含まれています。
ステップ2. 各WordPressサイトの環境IDを取得する
各サイトは複数の環境(本番環境やステージング環境など)を持つことができ、バックアップは環境ごとにトリガーされます。各サイトの環