EmDashのバックアップと更新｜失敗を防ぐ確認

こんにちは。Osukeラーニング、運営者の「osuke」です。

EmDashで記事を公開できたあと、更新の案内を見て「バックアップを取れば、失敗しても元に戻せるだろうか」と気になりませんか。記事のデータ、画像、サイトのコードは別の場所にあり、一つを保存しただけでは必要なものがそろわない場合があります。

この記事は、2026年10月30日に確認したEmDashとCloudflareの公式資料に基づく調査記事です。復元や更新を実サイトで試した結果ではありません。操作を始める前に、何を残し、誰が何を確認するかを整理するための比較表と確認票をまとめます。

記事のポイント

• JSONの保存とサイトを復旧する備えは異なる
• DB・画像・コードや設定を同じ時点で対応させる
• 更新後の起動がDBの変更につながる場合がある
• 取得・復元確認・本番切替の承認を分ける

EmDashのバックアップで残すもの

まず「バックアップがある」という言葉を具体化します。保存した形式、含むもの、戻せる範囲、保存期限が分かると、不足を担当者へ確認しやすくなります。

JSON保存だけで復旧できるか

EmDashの管理画面で取得するJSONを、サイト全体を元どおりにする復元用ファイルだと考えないことが最初の注意点です。公式のバックアップ資料は、JSONは内容の確認や独自のツールで扱う用途に役立つ一方、その形式から復元する管理画面・API・CLIの機能はないと説明しています。ファイルがダウンロードできたことと、障害時に元の状態へ戻せることは別の確認です。

JSONには記事やコンテンツモデルなどが含まれますが、すべてのデータを含むわけではありません。たとえば、画像に関する情報が入っていても、画像ファイルそのものが保存されるとは限りません。利用者や認証、プラグインに関わるデータにも対象外があります。ここで大切なのは項目を暗記することではなく、自分が復旧後に必要とするものが、その保存形式に入るかを一つずつ照合することです。

想定例として、本文を保存したJSONだけを持ち、画像の保存先を誤って削除した場合を考えます。画像の名前や参照先が分かっても、消えたファイルまで取り戻せるとはいえません。逆に画像だけコピーしても、記事との関係や管理者の状態まで戻る保証にはなりません。公式のBackups and recoveryを見ながら、「確認用の出力」と「DB全体を戻すための復旧地点」を別の欄に記入します。

JSONを不要と考える必要はありません。内容の点検や比較に使う役割と、完全な復旧の役割を分ければ、保存したものの価値を見誤らずに済みます。担当者へは「バックアップはありますか」だけでなく、「どの形式を、どの方法で戻せると確認していますか」と尋ねると、次に不足する材料が見えます。この記事でも、JSONから復元できたという体験や操作手順は示していません。

DB・画像・設定を分けて整理する

復旧を考えるときは、DB、メディア、アプリケーションのコードや設定を別々に洗い出します。DBが戻っても、その時点で参照していた画像がなくなっていれば、表示は元どおりにならない可能性があります。コードが古いままでDBの構造だけ新しくなっている場合にも、組合せの確認が必要です。「一つのファイルに全部入っているはず」という前提を置かず、どこに何があるかを先に整理します。

さらに、暗号化したプラグイン設定を使う構成では、読み出しに必要な鍵の管理も関係します。鍵の値を一般の確認票やチャットへ書く必要はありません。確認票には保管先の管理方法、扱える担当者、対応する版を記録し、実際の秘密値は適切な秘密管理の仕組みで保護します。DBやSQLの出力にも認証関連の情報が含まれうるため、記事の下書きや誰でも開ける共有場所へ置く扱いは避けます。

たとえば、月曜のDB、火曜に差し替えた画像、水曜のコードをまとめて「最新バックアップ」と呼ぶと、どの時点のサイトへ戻すのかが曖昧になります。これは架空の例ですが、同じ日時にすべてを取得できない運用でも、取得時点の差を記録すれば、失う可能性のある変更を話し合えます。保存先の詳細な認証情報を出さずに、対応関係だけを一覧にすることから始められます。

D1の保存期間と復元範囲を読む

Cloudflare D1にはTime Travelという時点復元の仕組みがあります。ただし、無料プランでも一律に30日戻せると読むのは誤りです。2026年10月30日に確認した公式の制限表では、Workers Freeは7日、Workers Paidは30日とされています。長く戻せるという説明を見つけた場合も、使っているプランと適用条件まで照合してください。保持期間を超えた復旧を想定するなら、別の保全方法も検討項目になります。

戻るのはD1のDBであり、R2に置いた画像や外部の秘密管理にある鍵まで同時に戻るわけではありません。また、D1の復元は、現在のDBをその場で上書きし、実行中の問い合わせを中断する操作として案内されています。安全な別コピーが自動的にできて、現在の運用を変えずに試せる仕組みと混同しないでください。説明を読むことと、復元ボタンやコマンドを実行することの影響は大きく異なります。

公式のTime Travelの説明とD1の現行制限を確認先にできます。記録するのは「いつかのバックアップがある」ではなく、対象DB、戻す時点、利用できる期限、対応する画像やコードです。たとえば無料プランで1週間以上前の状態が必要になっても、Time Travelの期間内に残っているとはいえません。期限を把握せずに更新を重ねると、選べる復旧地点が狭まります。

「無料で履歴があるから、別の備えは要らない」と決める前に、どのくらい前の状態へ戻す必要がありうるかを書きます。長期保管、別の保存先、復元確認には、それぞれ費用や権限の検討も必要です。この記事ではプランを変更したり、DBの復元地点を取得したりしていません。読者のDBがどの状態で戻せるかを保証するものではなく、確認の順番を整理しています。

バックアップの公開と権限に注意する

バックアップは、失ったときの備えである一方、公開範囲を誤ると新たな情報流出につながる可能性があります。画像を配信するための保存先と、内部データを保管する場所は同じ基準で扱えません。公式資料は、公開R2ドメインなどの経路がある場合、バケット内のバックアップがURLから見えるおそれを説明しています。EmDashのメディア配信側で拒否していても、別の公開経路まで保護されるとは限りません。

たとえば、通常の画像はブログ読者に見せたい一方、DBの出力やJSONの控えは運営担当者だけが扱う、という違いがあります。保存先のフォルダ名を目立たない名前にしただけで、非公開になったとは判断できません。公開される経路、アクセスできる人、バックアップ専用の権限をそれぞれ確認します。既存の公開範囲を調べるために秘密ファイルを外から試しに開く、といった方法も必要ありません。

公式は、通常のメディアのバックアップには読取専用の認証を使い、復元用には復元先へ限定した書込み権限を与える考え方を示しています。本番と同じ障害の影響を受ける場所だけに保存してよいかも論点です。これは今すぐ新しい権限を発行する勧めではなく、既存の運用担当者に範囲を確認するための項目です。秘密値、接続用の認証、バックアップ本体を記事やSNSへ公開する必要はありません。

もし公開範囲や担当者が分からなければ、「安全だからこのまま」とも「危険だから全部止める」とも即断しません。まず対象と不明点を記録して、管理者へ確認します。保存先や権限の変更は、読者への影響や既存の画像配信への影響を確認してから承認する作業です。本稿の作成では、R2の公開設定、認証、アクセス権限を調査のために変更することはしていません。

復元できるか確認する項目を作る

バックアップの取得が成功しても、そのファイルが目的の環境へ戻せるとは限りません。戻すときに必要な順番、対応するアプリケーション、画像、認証などを合わせて確認する必要があります。公式資料にも、DBや保存先ごとに復旧の方法が分かれています。Cloudflare D1向けの説明を、SQLite、PostgreSQL、別のサービスのDBへそのまま流用しないことが大切です。

たとえばD1では、検索用の特殊なテーブルがある構成で単純な出力が失敗したり、出力したSQLがそのまま再投入できなかったりする注意点が公式に示されています。ファイルができた、容量がある、というだけでは読み込み後の整合性までは分かりません。本稿では複雑なコマンドを短く抜き出して貼り付け手順にせず、利用しているDBと構成に対応した現行の復旧資料を担当者が確認する項目として扱います。

確認票では、保存済み、復元方法が分かる、許可された別環境で復元できた、本番切替を承認した、という段階を分けます。実際に確認していない段階には未確認と書きます。たとえば既存記事が表示できても、管理者がログインできるか、画像が開くか、必要な設定が読めるかまで確認したことにはなりません。試験に別環境や追加の権限、費用が必要なら、その条件を先に説明して承認を得る順序にします。

EmDashの更新前後に確認すること

次に、何を更新すると何が変わるかを整理します。版を上げる作業、DBの変更、公開切替を一つの操作として扱わず、保全と確認を挟む場所を決めます。

本体とプラグインの版を区別する

EmDashの更新では、サイトに入っている本体と関連パッケージを区別して確認します。公式更新資料では、EmDash本体とCloudflare向けパッケージは同じ版を組み合わせる一方、プラグインは別の版番号を持ち、必要な本体の最低版を示すと説明されています。リリース一覧の先頭に表示されたプラグインの番号だけを見て、「自分の本体もこの版へ上げればよい」とは判断できません。

記録する項目は、現在の本体、Cloudflare向けパッケージの有無と版、利用中のプラグイン、更新先で必要になる条件です。テンプレートから最初にコピーしたレイアウトや設定ファイルも、依存パッケージを更新しただけですべて最新になるわけではありません。自分のサイトで変更した部分があるなら、最新版のテンプレートで上書きしてよいと決めず、必要な差分を確認する作業として扱います。

詳しい対象と変更内容は、EmDashの公式更新ガイドで確認できます。たとえば、公式が後方互換の修正として説明する更新でも、利用するプラグイン、独自のテンプレート、ビルド環境まで無関係とはいえません。版番号をそろえたことと、そのサイトの必要な機能が動くことを別に検査します。この記事では、実際のプロジェクトの依存関係や設置版を変更していません。

プラグインの形式や選定自体で迷う場合は、EmDashのプラグインを選ぶ確認事項へ分けて整理できます。本記事で新しいプラグインを追加したり、安全性を認定したりはしません。使っていない機能の導入を更新に紛れ込ませず、いま必要な更新と追加の作業を区別すると、変更範囲と確認範囲をそろえやすくなります。

起動とDB変更の関係を確認する

コードを取得する段階と、新しいアプリケーションを起動する段階では、DBへの影響が異なります。現行の更新ガイドでは、更新用の仕組み自体はDBへ接続して移行するものではない一方、起動や公開後の最初の要求によって、未適用の本体DB変更が動く構成が説明されています。「画面を見るだけだから何も変わらない」とは限らない点を、更新前に確認しておきたいところです。

公式の本体DBマイグレーションの管理資料は、既定の動作と、配置工程でDB変更を管理する方法を分けています。自分のサイトがどちらの構成か不明なまま、記事の断片的なコマンドを試すと、想定した段階より早く変更が始まる可能性があります。未適用の変更、接続先のDB、必要な復旧地点を確認し、新版を起動・配置する前に準備がそろっているか判断します。

また、更新用ツールの実行には、パッケージやスキルの追加・更新が含まれる場合があります。計画を表示するための操作でも、実行に必要なツールを取得する可能性があるため、「確認用だからPCへの影響はない」と無条件には勧めません。この記事では、ツールの導入、試験起動、配置、DBの確認コマンドを実行していません。実施する場合は、PCとリモートのどちらへ何が加わるかも説明を受けます。

たとえば、本人限定のサイトであっても、接続しているDBが本番と共有なら、外から見えないことだけで変更の影響を小さくできるとはいえません。公開範囲とデータの接続先は別の軸です。事前の説明には、見る画面だけでなく、コード・データ・保存先のどこへ変更が及ぶかを含めます。確認が取れない場合に起動を保留する判断も、更新の計画に組み込んでおきましょう。

コードの切戻しだけに頼らない

更新で問題が起きたとき、以前のコードを再配置するだけで元のサイトへ戻るとは限りません。DBの構造や内容も変わっている場合には、その時点と互換性のあるコード、画像、必要な設定を組み合わせて確認する必要があります。公式は本体DBマイグレーションを前方向の変更として説明しています。コードの版を下げることを、その変更を取り消す正式な逆操作と考えないようにします。

さらに、サイト独自のコレクションや項目を変える作業は、本体の内部DB変更と別です。公式の稼働中サイトのデータモデル変更の資料でも、コンテンツ編集、コードの配置、初期作成、データモデルの変更を分けています。たとえば本文に項目を一つ追加する作業と、本体を新しい版へ更新する作業を同時に行うと、表示不具合の原因と戻す対象が分かりにくくなることがあります。

想定例として、午前中に記事を追加し、午後にDBを変更する更新で不具合が起きた場合を考えます。前日のDBへ戻せば、午前中の記事も失われる可能性があります。「戻せる」という言葉だけで済ませず、何時以降の書込みがなくなるか、復旧前の状態を別に残す必要があるかを担当者と確認します。この事例は仕組みを説明する架空の場面であり、当サイトで実施した復旧ではありません。

通信が途切れた作業では、全部失敗したとも、全部成功したとも決めつけません。公式資料にも中断したDB操作の結果を確認する考え方が示されています。結果が不明なまま同じ変更を繰り返すより、同じ対象の現在状態を確認する段階へ戻すことが重要です。停止条件と連絡先を事前に決めておくと、障害時に焦って変更を積み重ねることを防ぎやすくなります。

更新後は表示と編集を別々に確認する

公開ページが一つ表示できても、更新後の確認はそれだけでは終わりません。読者が記事や画像を開けること、管理者がログインして内容を編集できること、必要な予約や連携が働くことは別の確認です。公式更新ガイドも、管理画面、公開ページ、編集と公開、メディアの扱いなどを確認対象にしています。利用していない機能まで試す必要はありませんが、自分のサイトの運用に必要な経路は確認票へ残します。

たとえば、ページは表示できるのに新しい画像が保存できない状態なら、閲覧だけの点検では見つかりません。逆に管理画面で保存できても、公開ページへ反映されるかは別に見る必要があります。予約投稿や隔離型プラグインを使うサイトでは、それぞれの経路も対象になります。試すための投稿や画像を本番へ増やす場合にも、作成範囲、公開範囲、後で削除する対象を事前に合意します。

初回のサイト作成と公開までの考え方は、EmDashの始め方を整理した記事へ分けています。すでにある初回確認の記録を、その後の版でもすべて確認済みだと読み替えないことが大切です。更新した版、対象、確認した日時を添えれば、同じサイトでもどこまで確認が続いているかを判断できます。実施していない負荷試験や長期運用は、未確認のまま残します。

バックアップと更新の承認票を残す

バックアップと更新の準備は、操作を始める前に一枚の承認票へまとめられます。目的、対象のサイト、現在と更新先の版、保存するもの、影響するDBや保存先、戻す条件を記入します。「記事を作ってほしい」「更新について調べてほしい」という依頼を、ソフトの導入やサイトの設定変更まで許可した意味へ広げないことも、依頼側と作業側で確認しておきたい点です。

承認はまとめて一度と考えず、資料調査、バックアップ取得、復元確認、実際の更新、本番切替に分けると変更範囲が明確になります。たとえば今回は資料だけ、次回は既存の環境から読取だけ、その次に書込みを伴う試験を相談する、という進め方もできます。追加の契約、ツール、認証権限が必要なら、何のために必要かと費用を説明してから判断します。読取用の確認であっても秘密情報を広く渡す必要はありません。

費用も、更新ソフトの代金だけではなく、保存容量、処理、試験用資源、作業時間を分けて考えます。無料枠を使っていても、保存する量やコピー先、契約の条件によって確認が必要です。費用の全体像はEmDashの料金と運用費の確認事項を参照できます。本記事では無料枠の利用量や請求を実測しておらず、特定の方法が必ず無料で完了するという保証はしていません。

この記事の結論は、何かをすぐ実行することではなく、保存物の限界と変更の境目を説明できる状態にすることです。未確認の箇所は未確認とし、必要な承認を得てから次の段階へ進みます。本稿の作成では、PCへの導入、EmDashの起動や更新、DBの保全・復元、実サイトや認証の設定変更を行っていません。