バックアップと復旧

バックアップに含まれるもの

JSONバックアップには次のものが含まれます。

• 下書き、予約公開の投稿、ゴミ箱の項目を含む、すべてのコンテンツのエントリー
• コンテンツモデルを構成する、コレクションとフィールドの定義
• タクソノミーの定義、ターム、各エントリーに割り当てられたターム
• メニューとメニュー項目、セクション、ウィジェットエリアとウィジェット、SEOのレコード、リビジョンの履歴、メディアのメタデータ、データベースのマイグレーションの履歴
• タイトル、キャッチフレーズ、URL、ロケール、ロゴ、表示の設定、ソーシャルプロフィール、SEOの既定値などのサイト設定。これらは site:、emdash:site_、emdash:locale の設定グループから取得されます。

次のものを含め、それ以外のデータベースのテーブルは含まれません。

• ユーザーアカウント、セッション、パスキー、OAuthのデータ、APIトークン、その他の認証のデータ
• プラグインの秘密情報を含む、プラグインのストレージとプラグインの設定
• コメントとリアクション、リダイレクトと404のログ、バイライン、コンテンツ間の関連と参照、監査ログ、レート制限、スケジュールされたタスクの状態
• メディアのフォルダー、メディアの使用箇所の記録、未完了または進行中のアップロード、メディアのファイルそのもの
• プレビュー用の署名の秘密鍵やバックアップのスケジュールを含む、その他のサイトのオプション

バックアップは、EmDashのプレビューの仕組みで使うものと同じスナップショット形式のJSONファイルで、作成したEmDashのリリースでバージョンが付けられます。

ワンクリックでのダウンロード

管理画面の「設定」→「バックアップ」にある「バックアップをダウンロード」ボタンは、新しいバックアップを作成し、JSONファイルとしてダウンロードします。管理者の権限が必要です。

ダウンロードしたファイルは、内容の確認や、独自の移行ツールに使うためのものです。一括インポート、スキーマの変更、大きなアップグレードの前には、次のいずれかの方法で、復元できるデータベースのバックアップを作成します。

ストレージへの自動バックアップ

サイトにストレージのバックエンド（CloudflareのR2、S3、ローカルのストレージ）が設定されている場合は、毎日の自動バックアップを有効にできます。

アーカイブは、バケットの backups/ 接頭辞の下に emdash-backup-<timestamp>-<random>.json として保存されます。管理画面の「保存済みのバックアップ」の一覧から個別のアーカイブをダウンロード・削除でき、「今すぐバックアップを作成」を選択すると、その場で1つ作成します。

自動バックアップは、定期メンテナンスの実行（予約公開を動かしているのと同じ仕組み）に便乗して動きます。CloudflareではWorkerのCronトリガー、Node.jsでは組み込みのスケジューラーです。デプロイした環境にCronトリガーが設定されていない場合は、代わりに「今すぐバックアップを作成」かダウンロードのボタンを使います。

メディアのオブジェクトのバックアップと復元

R2とS3互換のバケットでは、データベースに加えて、オブジェクト単位のバックアップが必要です。次のAWS CLIの例は、EmDashの backups/ のアーカイブを含むすべてのオブジェクトを、ローカルのバックアップ用のディレクトリにコピーします。AWS S3の場合は --endpoint-url を省略します。

aws s3 sync s3://emdash-media ./emdash-media-backup \
  --endpoint-url https://<account-id>.r2.cloudflarestorage.com

定期的なバックアップの処理には、読み取り専用のバケットの認証情報を使います。バックアップは本番のアカウントや障害の影響範囲の外に保管し、同じ時点に作成したデータベースのバックアップまたはTime Travelの時点を記録しておきます。

リクエストに応答している本番のバケットを上書きするのではなく、空の復旧用のバケットに復元します。

aws s3 sync ./emdash-media-backup s3://emdash-media-recovery \
  --endpoint-url https://<account-id>.r2.cloudflarestorage.com

復元の処理には、復旧用のバケットへの書き込み権限だけを与えます。本番以外のデプロイでそのバケットを使うように設定し、既知のメディアのURLをいくつか開き、使い捨てのファイルをアップロードして削除します。本番のバインディングやバケットの設定を切り替えるのは、復元したデータベースとメディアの組み合わせが両方とも確認に通ってからにします。

D1のTime Travelによるデータベースの復旧

リスクのある操作の前に、Time Travelに現在のブックマークを問い合わせ、デプロイや変更の記録と一緒に控えておきます。

npx wrangler d1 time-travel info my-database

復旧が必要になったら、サイトへの書き込みを止め、破壊的な復元のコマンドを実行する前に、使える復元ポイントを確認します。

npx wrangler d1 time-travel restore my-database --timestamp=2026-07-08T13:00:00Z

Time Travelは、コンテンツ、ユーザー、設定、プラグインのデータ、マイグレーションの記録を含む、データベース全体を復元します。R2のメディアのオブジェクトは復元しません。コマンドが完了したら、復元したデータベースに合うアプリケーションのバージョンをデプロイし、アクセスの受け付けを再開して、ログイン、コンテンツの読み取り、スキーマの変更、書き込みを確認します。

詳しくは、D1 Time Travelのドキュメントを参照してください。

D1のSQLダンプを別の場所に作成

データベースそのもの（ユーザーと認証のテーブルを含む）の完全なSQLダンプを作るには、Wranglerを使います。

npx wrangler d1 export my-database --remote --output=backup.sql

SQLファイルは、対応するアプリケーションのバージョンと、同じ時点に作成したメディアのバックアップと一緒に保管します。復旧のテストは、新しく作成した空のD1データベースにダンプをインポートし、本番以外のバインディングをそのデータベースに向け、サイトを確認して行います。

次のコマンドで、空の復旧用のデータベースにインポートします。

npx wrangler d1 execute my-recovery-database --remote --file=backup.sql

SQLiteのバックアップと復旧

SQLiteをオフラインでバックアップするには、データベースに書き込むすべてのプロセスを止めてから、データベースのファイルをコピーします。整合性のあるオンラインのバックアップには、SQLiteのbackupコマンドを使います。

sqlite3 emdash.db ".backup backup.db"

ローカルのアップロード用のディレクトリやS3互換のバケットは、別にバックアップします。復旧するには、すべてのサーバーのプロセスを止め、壊れたデータベースのコピーを残してから、確認済みのバックアップに置き換え、必要なメディアのオブジェクトを復元し、対応するアプリケーションのバージョンを起動します。アクセスの受け付けを再開する前に、ログイン、公開されているコンテンツ、編集、メディアの読み取りを確認します。

JSONのエクスポートからはサイトを復元できない

EmDashには、JSONから復元するための管理画面の操作、APIエンドポイント、CLIのコマンドがありません。上で説明したD1のTime Travel、D1のSQLダンプそのもの、SQLiteのデータベースのコピーを使います。