Backup & Restore の概要

FPT Database Engine の backup は 4 つの要素で構成され、必要な要素がすべて揃って初めてデータが保護されます。最も多い失敗は、最初の要素で止まってしまうことです。

危険

Kafka の backup は非推奨であり、2026年9月15日に削除されます。 その日まで backup と restore のすべての機能を利用できます。削除後、既存の Kafka backup ファイルはすべて完全に削除され、restore できなくなります。

Kafka の backup データを保持する必要がある場合は、その日までに新しい database cluster へ restore してください。他の engine は影響を受けません。

要素	役割	単体では
backup サービス	保存容量を確保し、すべての job が使う共通ポリシーを保持します	何も backup されません
backup job	復旧ポイントを実際に生成するスケジュールです	復旧可能なデータを作るのはこれです
PITR	archived log を保持し、特定の時点まで復旧できるようにします	full backup job が必要で、有効化後の次の full backup 完了まで効果はありません
restore	復旧ポイントまたは特定時点から新しい database を作成します	元の database を上書きすることはありません

警告

backup サービスを有効にするだけでは何も backup されません。データが保護されるのは、backup job が存在し、それが 1 回以上実行された後です。

設定する順序

各ステップが次のステップの前提であり、大半は console 側で強制されます。

1. 通知先を設定します。 メールアドレスか Telegram チャネルが 1 つ以上ないと backup を有効化できません。アラートの管理 を参照してください。
2. backup サービスを有効にします。 database 全体の backup 容量を設定します。Backup サービスの管理 を参照してください。
3. full backup job を作成します。 backup スケジュールの設定 を参照してください。
4. PITR を有効にします。 秒単位の復旧が必要な場合のみです。PITR の有効化と無効化 を参照してください。

ステップ 1 から 3 は、database の作成 の付加サービスのステップでも設定できます。

backup job の種類

種類	対象	対応 engine
Full	database 全体	対応するすべての engine。Kafka では 2026年9月15日まで。
Differential	直近の full backup 以降の変更分のみ	PostgreSQL, MySQL, MariaDB, SQL Server

differential job は full job に依存します。retention は job ごとに、保持する世代数で設定します。

データを復旧する

どちらの復旧経路も既存の database を修復するのではなく新しい database を作成するため、2 つ目の database 用の quota を見込み、アプリケーションの接続先を切り替える前提で計画してください。

必要なもの	使う機能	対応 engine
ある backup 時点の状態	backup からの restore	対応するすべての engine。Kafka では 2026年9月15日まで。
特定の時点の状態	特定時点への復旧	PostgreSQL, MySQL, MariaDB

プラットフォーム外へのコピー

backup は FPT が管理する分離された専用 storage に保存されます。長期保管、オフサイトのコピー、他システムへのデータ引き渡しなど、自分の管理下にコピーが必要な場合は backup データを S3 に転送する を使ってください。

費用

backup の保存容量は database とは別に課金され、PITR は archived log を backup と併せて保持するためさらに費用が増えます。容量は job ごとではなく database のすべての backup job に適用されるため、どちらも有効化する前に見積もっておく価値があります。

次のステップ

• Backup サービスの管理。ここから設定を始めます
• レポートの概要。複数の database をまたいで backup の実行状況を確認します
• 機能。使用中の engine が何に対応しているかを確認します