選択したコンテンツデータのオフラインコピーが必要な場合は JSON バックアップを使用します。EmDash はそのファイルをインポートできません。リカバリプランには、生のデータベースバックアップまたはポイントインタイムリカバリと、メディアバイナリの別コピーが必要です。
バックアップの内容
JSON バックアップには以下が含まれます:
- すべてのコンテンツエントリ(下書き、予約投稿、ゴミ箱のアイテムを含む)
- コンテンツモデルを構成するコレクションとフィールドの定義
- タクソノミーの定義、用語、各エントリに割り当てられた用語
- メニューとメニューアイテム、セクション、ウィジェットエリアとウィジェット、SEO レコード、リビジョン履歴、メディアメタデータ、データベースマイグレーション履歴
- タイトル、タグライン、URL、ロケール、ロゴ、表示設定、ソーシャルプロフィール、SEO デフォルトなどのサイト設定。これらは
site:、emdash:site_、emdash:locale設定グループから取得されます。
以下を含む他のすべてのデータベーステーブルは省略されます:
- ユーザーアカウント、セッション、パスキー、OAuth データ、API トークン、その他の認証データ
- プラグインストレージとプラグイン設定(プラグインシークレットを含む)
- コメントとリアクション、リダイレクトと 404 ログ、著者行、コンテンツリレーションとリファレンス、監査ログ、レート制限、スケジュールタスクの状態
- メディアフォルダー、メディアの使用場所の記録、不完全または進行中のアップロード、メディアファイル自体
- プレビュー署名シークレットやバックアップスケジュールを含むその他のサイトオプション
バックアップは EmDash のプレビューシステムで使用されるのと同じスナップショット形式の JSON ファイルで、作成した EmDash リリースでバージョン管理されます。
ワンクリックダウンロード
管理画面の Settings → Backups で、Download backup ボタンが新しいバックアップを生成し JSON ファイルとしてダウンロードします。管理者ロールが必要です。
ダウンロードは検査やカスタムマイグレーションツール用です。一括インポート、スキーマ変更、メジャーアップグレードの前に、以下のオプションのいずれかを使用して復元可能なデータベースバックアップを作成してください。
ストレージへの自動バックアップ
サイトにストレージバックエンド(Cloudflare の R2、S3、またはローカルストレージ)が設定されている場合、毎日の自動バックアップを有効にできます:
-
管理画面の Settings → Backups を開きます。
-
Daily automatic backups をオンにします。
-
保持するバックアップ数を選択します(1〜30)。古いアーカイブは自動的に削除されます。
-
保存します。バックアップは EmDash の定期メンテナンスの一部として実行されます — 追加の cron 設定は不要です。
アーカイブはバケット内の backups/ プレフィックスの下に emdash-backup-<timestamp>-<random>.json として保存されます。管理画面の Stored Backups リストで個々のアーカイブをダウンロードまたは削除でき、Back up now でオンデマンドで作成できます。
自動バックアップは定期メンテナンスティック(予約公開と同じメカニズム)に便乗します — Cloudflare では Worker の cron トリガー、Node では組み込みスケジューラーです。デプロイメントに cron トリガーが設定されていない場合、代わりに Back up now またはダウンロードボタンを使用してください。
メディアオブジェクトのバックアップと復元
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 を開き、使い捨てファイルをアップロードして削除します。復元されたデータベースとメディアセットが一緒にチェックに合格した後にのみ、本番バインディングまたはバケット設定を切り替えます。
Time Travel で D1 データベースを復旧する
リスクのある操作の前に、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 ダンプ(ユーザーと認証テーブルを含む)には、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 のバックアップコマンドを使用します:
sqlite3 emdash.db ".backup backup.db"
ローカルアップロードディレクトリまたは S3 互換バケットは別途バックアップします。リカバリするには、すべてのサーバープロセスを停止し、破損したデータベースのコピーを保持し、検証済みバックアップで置き換え、必要なメディアオブジェクトを復元し、対応するアプリケーションバージョンを起動します。トラフィックを再開する前に、サインイン、公開コンテンツ、編集、メディアの読み取りを確認してください。
JSON エクスポートではサイトを復元できない
EmDash には JSON 復元用の管理アクション、API エンドポイント、CLI コマンドがありません。上記のように D1 Time Travel、生の D1 SQL ダンプ、または SQLite データベースのコピーを使用してください。