バックアップを考えるとき、最初に出てくる問いは「どのツールで保存するか」になりがちである。mysqldump、binary log、PITR、レプリケーション、スナップショット、rsync、オブジェクトストレージ、WORM、Git、SaaS エクスポートなど、技術的な選択肢はいくらでもある。しかし、これらはすべて手段である。先に問うべきなのは、何が失われると困るのか、それは再生成できるのか、どの時点まで戻せればよいのか、誰が障害時に迷わず戻せるのかである。
本稿は、WordPress の日次バックアップ以後に書いた原稿をどう守るかという具体的な問題から出発する。そこから、データ保全とは何か、バックアップと復元は何が違うのか、同期やレプリケーションはなぜバックアップではないのか、業務システムでは RPO、RTO、復旧水準をどう定義するべきか、実務でどのようなチェックリストと設計テンプレートを用意するべきかまで展開する。最後に、保全戦略を数理モデルとして定式化し、「高度な方式を選ぶこと」と「よい保全戦略を選ぶこと」が同一ではないことを示す。
1. 発端：日次バックアップでは守れないものがある
発端は WordPress の原稿保全である。WordPress の DB は日次で mysqldump しており、deferred-sync によって日々退避している[1]。さらにリモートホストからも取得しており、本番サーバーが失われても、少なくとも直近の日次バックアップ時点までは戻せる。この時点で、バックアップ運用が存在しないわけではない。むしろ基準バックアップとしては一応成立している。
しかし、日次バックアップには必ず時間的な空白がある。たとえば夜に明日公開する予約投稿を書き、WordPress 上で future 状態にしたとする。WordPress の投稿状態には publish、future、draft、pending、private などがあり、future は将来公開予定の投稿を表す[2]。この投稿は WordPress 上では存在するが、次回の日次 dump 取得前に本番 DB が壊れれば、日次バックアップには含まれない。
この問題は予約投稿に限られない。WordPress REST API の投稿オブジェクトには id、date、slug、status、title、content などが含まれ、status と content は投稿の状態と本文を構成する[3]。したがって、日次バックアップ以後に新規投稿を書いた場合、下書きを更新した場合、公開済み記事を編集した場合、固定ページを書き換えた場合も同じである。日次バックアップはサイト全体の基準点を守るが、バックアップ後に人間が行った本文作業は守らない。
ここで重要なのは、問題を「予約投稿が消えるかもしれない」と狭く見ないことである。より正確には、これは「日次バックアップの RPO と、人間の原稿作業の価値が一致していない」という問題である。バックアップ取得間隔は 1 日でよいかもしれない。しかし、その 1 日の間に書いた本文は、場合によっては数時間の作業、数千字から数万字の思考、表、参考文献、HTML 構造、数式を含む。DB の時間粒度と、人間が失いたくない価値の粒度がずれている。
この構造は WordPress に固有ではない。多くのシステムでは、定期バックアップの周期と、人間や業務が実際に価値を生成する周期が一致しない。たとえば、GitHub issue に重要な設計判断を書いた直後、Slack や Teams で運用変更に合意した直後、Google Docs で契約文書や仕様書を大きく編集した直後、会計ソフトに取引データを入力した直後、写真管理アプリに撮影データとメタデータを取り込んだ直後にも、同じ種類の空白が発生する。システム全体としては「日次バックアップ済み」であっても、その後に発生した意味内容、判断、合意、入力、編集は、まだバックアップの保護範囲に入っていない。
| 対象システム | 定期バックアップ後に発生し得る価値ある変更 | 失われるものの本質 |
|---|---|---|
| WordPress | 予約投稿、下書き、公開済み記事の編集、固定ページの更新。 | 記事本文、HTML 構造、参考文献、数式、編集判断。 |
| GitHub issue | 設計判断、障害対応方針、レビュー結論、仕様変更の合意。 | 意思決定の履歴、なぜそうしたかという判断文脈。 |
| Slack / Teams | 運用変更の合意、障害対応中の判断、担当割り当て、暫定対応の指示。 | 組織的な合意、対応根拠、口頭に近い非同期判断。 |
| Google Docs | 仕様書、契約文書、議事録、設計資料の大幅編集。 | 文書本文、表現、構成、合意済みの記述。 |
| 会計ソフト | 取引入力、証憑登録、勘定科目修正、締め処理前の調整。 | 取引事実、証跡、会計判断、再入力が困難な業務記録。 |
| 写真管理アプリ | 写真の取り込み、撮影メタデータ整理、選別、補正、タグ付け。 | 元データ、撮影文脈、選別判断、編集履歴。 |
つまり、ここで問題になっているのは「WordPress の予約投稿をどう守るか」ではなく、「定期バックアップ以後に発生した価値ある変更をどう扱うか」である。バックアップは一定時点のシステム状態を固定するが、人間の作業はその後も連続的に進む。システム状態の保存周期と、意味内容の生成周期がずれると、その隙間に未保全の価値が生まれる。これを放置すると、障害時には DB やファイルは戻っているのに、もっとも重要な判断や本文や編集結果だけが失われるという状態になる。
したがって、データ保全では、最初に「システム全体を何時間ごとにバックアップしているか」だけを見てはいけない。むしろ、「そのバックアップ以後に、失うと再生成しにくい価値ある情報が発生していないか」を見る必要がある。日次バックアップがあることと、日次以後の作業が保全されていることは別である。この区別を置くことで、問題は単なる WordPress 運用から、バックアップ・リカバリー設計全体の基本問題へ広がる。
2. 現在の WordPress バックアップ構成
現在の構成では、WordPress DB は日次 mysqldump によって SQL ファイルとして保存されている。WP-CLI の wp db export は、WordPress の設定を使って mysqldump を実行し、DB を SQL ファイルとしてエクスポートするコマンドである[4]。MySQL の mysqldump は、データベースオブジェクト定義とテーブルデータを再現する SQL 文を生成する logical backup の手段である[5]。
この構成の強みは、単純であること、復元の基準点が明確であること、日次の世代として扱いやすいことである。本番障害時には、直近の日次 dump を戻し、WordPress の DB をその時点へ復元できる。リモートホスト側からも取得していれば、本番ホストそのものが失われた場合にも、少なくともバックアップファイルを取り出す経路が残る。
一方で、この方式は dump 取得後の更新を保持しない。mysqldump は取得時点の状態を保存するものであり、その後の更新履歴を自動的に含むわけではない。したがって、日次 dump は「基準バックアップ」として有効だが、「日次以後の変更履歴」には無力である。これは mysqldump の欠点というより、方式の性質である。
運用設計では、このように既存方式の強みと弱みを明示する必要がある。すでに日次バックアップがあるなら、追加で考えるべきことは「すべてを置き換えること」ではない。日次バックアップで守れるものと守れないものを分け、守れないものだけに追加の保全策を当てることである。
| 観点 | 日次 mysqldump で守れるもの | 日次 mysqldump だけでは守れないもの |
|---|---|---|
| 復元時点 | dump を取得した時点の DB 状態。 | dump 取得後に発生した投稿、編集、コメント、設定変更。 |
| 復元粒度 | DB 全体、または dump から抽出可能なテーブル単位の状態。 | 特定時刻までの細かいトランザクション履歴。 |
| 運用負荷 | 比較的低い。取得、保存、世代管理、復元手順が理解しやすい。 | 高頻度更新や任意時点復旧を求める場合は、追加設計が必要になる。 |
| 障害対応 | 本番 DB が壊れた場合に、直近の安定した基準点へ戻せる。 | 誤操作直前、障害直前、予約投稿作成後など、細かい時点には戻せない。 |
| 人間の作業保全 | dump 取得前に完了していた作業は含まれる。 | dump 取得後に書いた本文、判断、編集結果は含まれない。 |
この整理は WordPress に限らない。多くのシステムでは、日次 dump、日次 snapshot、日次 export、夜間バッチによる退避など、一定時点を保存する基準バックアップが置かれる。これは運用上きわめて重要である。基準バックアップがなければ、復旧の出発点が存在しない。障害時にどの状態へ戻すかを判断できず、復旧作業は場当たり的になる。
しかし、基準バックアップは万能ではない。基準バックアップは「ある時点の状態」を守るものであり、「その後に発生した価値」を自動的に守るものではない。業務システムであれば、日次バックアップ後に登録された注文、承認された申請、更新された顧客情報、入力された会計仕訳、作成されたドキュメント、合意された運用判断がこの空白に入る。個人ブログであれば、それが予約投稿、下書き、公開済み記事の編集になる。
したがって、既存バックアップ方式を評価するときは、「この方式は不完全だから駄目だ」と考えるべきではない。むしろ、「この方式は何を守るためのものか」を明確にする必要がある。日次 mysqldump は、WordPress の基準復旧点を作る方式としては有効である。しかし、日次以後の本文作業を守る方式ではない。この区別を置けば、次に必要なのは mysqldump の置き換えではなく、mysqldump の外側にある未保全領域への追加対策だと分かる。
| 一般的なバックアップ方式 | 主に守るもの | 守れないもの | 追加で考えるべき対策 |
|---|---|---|---|
| 日次 DB dump | 取得時点の DB 論理状態。 | dump 後の更新履歴、任意時点復旧。 | binary log、WAL、短周期 dump、重要データの個別 export。 |
| 日次ファイルバックアップ | 取得時点のファイル群。 | 取得後に作成・編集・削除されたファイル。 | 世代管理、差分同期、重要ファイルの即時コピー。 |
| VM snapshot | 取得時点の仮想マシン全体。 | アプリケーション整合性、snapshot 後の更新。 | アプリケーション整合性を考慮した backup、DB dump、ログ退避。 |
| SaaS export | export 時点の文書、チケット、設定、データ。 | export 後の編集、会話、合意、承認。 | 重要決定の Markdown 化、定期 export、API backup。 |
| クラウド同期 | 現在状態の複製。 | 誤削除、破損、暗号化、論理破壊からの復元。 | 世代管理、snapshot、削除保護、オフラインコピー。 |
この章で確認すべき本質は、既存のバックアップ方式には役割があるということである。日次 mysqldump は不要ではない。むしろ、それがあるから WordPress 全体の復旧基準点が確保されている。しかし、それは日次以後に人間が生成した意味内容を守るものではない。よって、設計上の問いは「日次バックアップをやめて別方式にするか」ではなく、「日次バックアップを基準層として維持し、その上にどのような補助層を置くか」である。
3. 最初に見えていた問題：予約投稿や下書きが失われる可能性
最初に見えていた問題は、予約投稿が失われる可能性だった。予約投稿は公開前である。したがって、公開済みページとして外部に存在しない。検索エンジンのキャッシュや Web アーカイブにも期待できない。WordPress DB が唯一の保存場所であれば、日次バックアップ前の本番障害で消える。
下書きも同じである。下書きは作業途中であるため、むしろ公開済み記事より保全が弱い。公開済み記事なら、古い版が日次バックアップや外部キャッシュに残っている可能性がある。しかし下書きや予約投稿は、WordPress 内部にしか存在しない。これは、システム内部状態に意味内容を閉じ込めている状態である。
公開済み記事の編集はさらに気づきにくい。障害後に日次バックアップを戻しても、記事そのものは存在する。しかし、編集前の本文に戻っている可能性がある。つまり、見た目には「記事は復旧した」ように見えるが、実際には編集作業が失われている。この種の損失は、完全消失より検出が難しい。差分を覚えていなければ、失われたことに気づかない。
したがって、保全対象は「新規投稿」だけではなく、「前回バックアップ以後に発生した本文の差分」である。この認識がないと、バックアップ設計は見かけ上は成立していても、人間の作業を保全できない。
| WordPress 上の状態 | 失われ方 | 検出しやすさ | 失われるものの本質 |
|---|---|---|---|
| 予約投稿 | 日次バックアップ前の障害で投稿そのものが消える。 | 比較的検出しやすい。 | 公開予定だった本文、構成、参考文献、公開準備作業。 |
| 下書き | 作業途中の本文がバックアップに含まれず消える。 | 比較的検出しやすい。 | 未完成だが再生成困難な思考過程、文章断片、構成案。 |
| 公開済み記事の編集 | 記事は存在するが、編集前の状態へ戻る。 | 検出しにくい。 | 差分、修正判断、表現改善、追記した情報。 |
| 固定ページの更新 | ページは存在するが、更新前の状態へ戻る。 | 検出しにくい。 | 案内文、プロフィール、リンク、運用上の最新情報。 |
| 投稿メタデータ変更 | カテゴリー、タグ、スラッグ、予約日時などが古い状態へ戻る。 | 内容によって異なる。 | 公開制御、分類、導線、読者への見え方。 |
この構造は、WordPress に限らず多くの業務システムに存在する。新規作成されたデータが消える問題は分かりやすい。しかし、より厄介なのは、対象自体は存在しているのに、内容だけが古い状態へ戻る問題である。顧客レコードは存在するが最新住所が消えている。契約書ファイルは存在するが修正版ではない。議事録は存在するが重要な合意事項が追記前に戻っている。設定ファイルは存在するが障害対応後の修正が反映されていない。こうした損失は、完全消失ではないため、復旧直後には見落とされやすい。
つまり、データ損失には「存在の喪失」と「差分の喪失」がある。存在の喪失とは、予約投稿や新規ファイルのように対象そのものが消えることである。差分の喪失とは、対象は存在するが、ある時点以後に加えた変更だけが消えることである。実務上は後者の方が危険な場合がある。なぜなら、見た目には復旧できているように見えるため、失われた変更を人間が思い出せない限り、損失が発見されないからである。
| 一般化した損失類型 | 典型例 | 何が危険か | 必要な保全策 |
|---|---|---|---|
| 存在の喪失 | 新規投稿、新規ファイル、新規チケット、新規取引データが消える。 | 対象がないため発見はしやすいが、再生成できない場合の被害が大きい。 | 短周期バックアップ、即時エクスポート、重要データの個別保存。 |
| 差分の喪失 | 既存記事、既存文書、既存顧客情報、既存設定が古い状態へ戻る。 | 対象は存在するため、失われた変更に気づきにくい。 | 差分記録、バージョン管理、変更後ファイルの保存、監査ログ。 |
| 判断文脈の喪失 | Slack、Teams、GitHub issue、議事録上の合意や判断根拠が消える。 | 結果だけ残っても、なぜそうしたかが分からなくなる。 | 重要判断の Markdown 化、設計書反映、決定事項ログ。 |
| 整合性の喪失 | DB は戻ったが添付ファイル、検索インデックス、外部連携状態がずれる。 | 個別データは存在しても、システム全体として正しく使えない。 | 復旧単位の設計、整合性確認、復旧後チェックリスト。 |
この観点から見ると、バックアップ設計では「消えたら分かるもの」だけを守っても不十分である。むしろ、消えたことに気づきにくい差分、判断文脈、整合性をどう守るかが重要になる。WordPress の公開済み記事編集は、その典型例である。記事は残っているため、復旧後の画面確認では問題がないように見える。しかし、実際には修正後の本文、追加した参考文献、整えた HTML 構造、更新した表が失われている可能性がある。
したがって、この章で確認すべき本質は、保全対象を「データが存在するかどうか」だけで判断してはいけないということである。重要なのは、前回バックアップ以後に加えた変更が、復旧後にも再現できるかである。バックアップ設計の対象は、単なるデータ本体ではなく、データに対して人間が加えた意味ある差分である。
4. 問題の再定義：守りたいのは DB 全体ではなく日次以後の本文変更である
ここで問題を再定義する。最初は DB の復元粒度を細かくする話に見える。しかし、実際に失いたくないものを分解すると、本当に守りたいのは DB 全体ではなく、日次バックアップ以後に人間が書いた本文変更である。
WordPress DB には多くの情報が入っている。投稿 ID、投稿状態、投稿日時、スラッグ、カテゴリー、タグ、投稿メタ、コメント、オプション値、リビジョンなどである。これらはシステム状態としては重要である。しかし、すべてが同じ価値を持つわけではない。投稿 ID は変わってもよい場合が多い。カテゴリーやタグは再設定できる。予約日時も人間が覚えていれば再設定できる。だが、数万字の本文、表、参考文献リンク、MathJax、HTML アンカー、段落構造、論理展開は簡単には再生成できない。
| 対象 | システム上の役割 | 失った場合の実害 | 再生成可能性 | 今回の保全優先度 |
|---|---|---|---|---|
| 投稿 ID | WordPress 内部で投稿を識別する。 | 内部参照や URL 構造に影響する場合がある。 | 再作成時に変わってもよい場合が多い。 | 中 |
| カテゴリー、タグ | 記事を分類する。 | 一覧表示や読者導線に影響する。 | 手作業で再設定できる。 | 中 |
| 予約日時 | 公開タイミングを制御する。 | 公開スケジュールが崩れる。 | 人間が把握していれば再設定できる。 | 中 |
| 本文 HTML | 記事内容そのものを構成する。 | 思考、構造、表、数式、参考文献が失われる。 | 長文記事では再生成が困難である。 | 高 |
この表から分かるのは、DB 全体の復元能力と、本文の保全能力は別問題だということである。DB 全体を任意時点に戻せれば強いが、本文だけを守りたいなら、より単純な方法がある。逆に、本文だけ保存しても DB 全体は戻らない。しかし、今回の問題が本文消失であるなら、本文を直接守る方が合理的である。
この再定義は、WordPress だけでなく、あらゆるデータ保全設計に当てはまる。多くのシステムでは、技術的な保存単位と、人間や業務にとっての価値単位が一致しない。DB はテーブルや行を保存する。ファイルシステムはファイルを保存する。SaaS は内部 ID、状態、履歴、権限、コメントを保存する。しかし、人間が本当に失いたくないものは、必ずしもその技術単位そのものではない。失いたくないのは、判断、文章、合意、証跡、取引事実、設計理由、作業結果、再生成できない文脈である。
したがって、バックアップ設計では、まず「技術的に何を保存できるか」ではなく、「失われると困る価値は何か」を分解する必要がある。DB 全体を守ることは重要である。しかし、DB 全体の中に含まれるすべての要素が同じ重要度を持つわけではない。逆に、DB の一部でしかない本文や取引記録や承認履歴が、システム全体よりも重要な復旧対象になることもある。保全対象は、保存媒体の単位ではなく、価値の単位で決めるべきである。
| 領域 | 技術的な保存単位 | 人間や業務にとっての価値単位 | 設計上の注意点 |
|---|---|---|---|
| WordPress | DB、投稿テーブル、投稿メタ、オプション値、アップロードファイル。 | 記事本文、構成、参考文献、公開判断、編集差分。 | DB 全体の復元と本文保全を分けて考える。 |
| 業務 DB | テーブル、行、インデックス、トランザクションログ。 | 注文、契約、承認、入出金、顧客との合意。 | テーブル単位ではなく業務イベント単位で復旧影響を評価する。 |
| GitHub issue | issue、comment、label、state、assignee。 | 設計判断、調査結果、合意事項、なぜそうしたかという文脈。 | 重要な結論は issue 内部に閉じ込めず、設計文書へ反映する。 |
| Slack / Teams | メッセージ、スレッド、リアクション、添付ファイル。 | 運用判断、障害対応方針、担当割り当て、暫定合意。 | 流れる会話と永続的な決定記録を分ける。 |
| Google Docs | 文書 ID、本文、コメント、共有権限、変更履歴。 | 文書本文、承認済み表現、契約文言、議事録上の結論。 | 文書そのものだけでなく、確定版や提出版を可搬形式で保持する。 |
| 会計ソフト | アプリケーション DB、取引テーブル、添付証憑、設定。 | 取引事実、証憑、勘定判断、締め処理の結果。 | DB 復元だけでなく、帳票、証憑、監査可能性を守る。 |
この観点では、バックアップ方式の評価軸も変わる。高度な方式で広範囲を保存できることは、それだけでは十分ではない。重要なのは、価値ある単位を復元できるかである。たとえば DB 全体を戻せても、どの注文を戻したいのか、どの承認を生かしたいのか、どの文書差分を復元したいのかが分からなければ、実務上の復旧は成立しない。逆に、システム全体は完全には戻せなくても、失ってはいけない本文や証憑や意思決定を可搬形式で保持していれば、業務上の損失を大きく抑えられる場合がある。
保全優先度を決めるときは、少なくとも再生成可能性、業務影響、検出容易性、復旧容易性、代替経路の有無を見る必要がある。再生成できないもの、失っても気づきにくいもの、後から証明が必要になるもの、復旧時に判断基準になるものは、優先して守るべきである。WordPress の本文 HTML は、この条件に該当する。完全に同じ論理で、業務 DB の注文、会計ソフトの証憑、Slack の合意事項、GitHub issue の設計判断も、単なるシステム状態ではなく価値ある意味内容として扱う必要がある。
| 評価軸 | 見るべき問い | 優先度が上がる条件 | WordPress 本文での該当性 |
|---|---|---|---|
| 再生成可能性 | 失った後に同じものを作り直せるか。 | 長文、判断、構成、表、参考文献などが含まれ、再作成が困難である。 | 高い。数万字の論考や参考文献構造は再生成しにくい。 |
| 業務影響 | 失うと公開、顧客対応、会計、契約、監査に影響するか。 | 公開予定、提出期限、顧客影響、法務影響がある。 | 中から高。個人ブログでも公開予定や編集履歴に影響する。 |
| 検出容易性 | 失われたことにすぐ気づけるか。 | 既存対象の差分だけが消える場合は気づきにくい。 | 高い。公開済み記事編集の巻き戻りは検出しにくい。 |
| 復旧容易性 | 保存しておけば簡単に戻せるか。 | 可搬形式で保存でき、手作業で復元できる。 | 高い。HTML として保存すれば貼り直せる。 |
| 代替経路 | 別の場所から取り戻せるか。 | 外部公開前、未同期、未反映、内部状態のみの場合は代替経路が少ない。 | 高い。予約投稿や下書きは WordPress 内部に閉じている。 |
この章で到達すべき結論は、バックアップ対象を「DB」「ファイル」「システム」といった技術名だけで定義してはいけないということである。技術単位は復旧手段を決めるためには必要だが、保全優先度を決める単位ではない。保全優先度は、価値、再生成可能性、検出容易性、復旧容易性によって決めるべきである。今回の問題をこの基準で見ると、DB 全体の任意時点復旧よりも、日次以後の本文 HTML を直接保存する方が、目的に対して合理的である。
5. 技術的に考えられる方法
MySQL の binary log は、テーブル作成やテーブルデータ変更などの DB 変更をイベントとして記録し、レプリケーションや復旧に用いられる[6]。したがって、DB の更新履歴を細かく追うなら binary log と PITR は正攻法である。日次 dump を基準バックアップとして取得し、その後の binary log を保存しておけば、基準バックアップを戻した後に binary log を適用することで、特定時点に近い状態まで DB を進められる。これは、いわゆるバックアップ＆ロールフォワード方式である。
バックアップ＆ロールフォワード方式の本質は、過去の基準点へ戻したうえで、その後の変更履歴を順番に再適用することにある。フルバックアップだけでは、取得時点にしか戻れない。しかし、フルバックアップ以後の変更ログが連続して残っていれば、取得時点から障害直前、あるいは誤操作直前まで状態を進められる。これは高頻度更新される DB、注文、決済、会計、業務トランザクションのように、日次単位の損失を許容できないデータでは非常に重要である。
| 構成要素 | 役割 | 欠けた場合に起きること |
|---|---|---|
| 基準バックアップ | 復旧の出発点になる DB 状態を保存する。 | 変更ログだけでは復旧を開始できない。 |
| 変更ログ | 基準バックアップ以後の更新を順番に記録する。 | 基準時点以後の更新を再現できない。 |
| 適用開始位置 | どのログ位置からロールフォワードするかを決める。 | 更新の重複適用や適用漏れが起きる。 |
| 適用停止位置 | どの時刻または event position で止めるかを決める。 | 誤削除や破壊的更新まで再適用してしまう。 |
| 復旧検証環境 | 復元結果を本番反映前に確認する。 | 壊れた復旧結果を本番へ戻す危険がある。 |
| 復旧手順書 | 障害時に誰でも同じ判断で作業できるようにする。 | ログは残っていても正しく戻せない。 |
この方式は強力である一方、運用は重くなる。まず、基準バックアップと binary log の対応関係を正確に管理しなければならない。どの dump がどの binary log file と position に対応するかが曖昧だと、復旧時にどこからログを適用すべきか判断できない。次に、binary log が途中で欠けてはいけない。1 本でも欠ければ、その区間の更新を連続的に再現できなくなる。さらに、復旧時にはどこで止めるかを判断する必要がある。障害直前まで進めるべき場合もあれば、誤削除直前で止めるべき場合もある。これは単なる機械作業ではなく、障害原因と業務影響を理解した判断である。
運用コストも無視できない。binary log を保持するには容量が必要になる。ローテーションや削除期限を誤ると、必要なログが消える。リモートホストへ退避するなら、転送、暗号化、保存先容量、権限、監視が必要になる。復旧手順も定期的に検証しなければならない。バックアップファイルとログが存在していても、実際に戻したことがなければ、それは復旧可能性の保証ではない。さらに DB のバージョン変更、設定変更、運用スクリプト変更、保存先変更があるたびに、復旧手順も追随させる必要がある。
| 運用項目 | バックアップ＆ロールフォワード方式で必要な管理 | 維持コスト |
|---|---|---|
| 取得管理 | 基準バックアップの取得成功、取得時刻、対応する log file / position を記録する。 | 中 |
| ログ保持 | 基準バックアップ以後の binary log を連続して保持する。 | 高 |
| 容量管理 | binary log の増加量を監視し、保存先容量を管理する。 | 中から高 |
| 遠隔退避 | 本番障害に備えて、ログを別ホストや別ストレージへ退避する。 | 中から高 |
| セキュリティ管理 | DB 更新内容を含むログを暗号化し、アクセス権を制限する。 | 高 |
| 復旧訓練 | 基準バックアップからログを適用し、指定時点へ戻せることを検証する。 | 高 |
| 手順更新 | DB バージョン、保存先、運用スクリプト、権限変更に追随して手順を更新する。 | 中 |
| 障害時判断 | どの時点までロールフォワードするかを判断する。 | 高 |
一方で、正攻法が常に最適とは限らない。PITR は DB 全体の任意時点復元に近づくが、運用設計が重い。レプリケーションは本番ホスト障害に強いが、誤削除や誤更新も複製される。短周期 dump は分かりやすいが、復旧時にどの dump を選ぶかの判断が残る。HTML 手元保存は DB 全体を戻せないが、本文を守るという目的には直接効く。
| 方法 | 主に守るもの | 強み | 弱み | 今回の目的との関係 |
|---|---|---|---|---|
| binary log / PITR | DB 全体の更新履歴。 | 指定時点へ近い粒度で復元できる。 | 設定、退避、復元検証、停止位置判断が重い。 | 正攻法だが本文保全だけには過剰になりやすい。 |
| バックアップ＆ロールフォワード | 基準バックアップ以後の DB 変更。 | フルバックアップ取得後の更新を再適用できる。 | 基準点、ログ連続性、停止位置、復旧検証の管理が必要になる。 | 高頻度更新 DB には有効だが、本文単体の保全には重い。 |
| レプリケーション | 本番 DB の直近状態。 | 本番ホスト喪失時に直近状態を取り出せる。 | 誤操作や破壊的更新も複製される。 | 可用性には効くが過去状態保全には不十分である。 |
| 短周期 dump | DB の近い時点の世代。 | binary log より理解しやすい。 | 保存数、容量、復元時点選択が増える。 | 妥協案だが対象範囲が広すぎる。 |
| HTML 手元保存 | 日次以後に書いた本文。 | 最も単純で、復旧時に人間が扱いやすい。 | DB 全体やメタデータは戻せない。 | 本文保全という目的に最も直接対応する。 |
ここで比較すべきなのは、技術的な強さだけではない。復旧能力、運用負荷、維持コスト、復旧時の判断負荷、セキュリティリスクを合わせて見る必要がある。バックアップ＆ロールフォワード方式は、DB 全体の復旧能力という点では強い。しかし、その強さは、ログを欠かさず保持し、正しい位置まで適用し、復旧結果を検証できるという運用能力に依存している。運用が追いつかなければ、仕組みは高度でも実効性は落ちる。
これに対して、HTML 手元保存は復旧対象を意図的に狭める方式である。DB 全体を戻すことはできない。投稿 ID、投稿状態、カテゴリー、タグ、予約日時、コメント、設定変更までは守れない。しかし、今回もっとも失いたくない本文 HTML は直接守れる。しかも、復旧時の手順は単純である。日次バックアップから WordPress を戻し、失われた本文を HTML ファイルから貼り直す。これは自動復旧ではないが、認知負荷が低く、数年後の自分でも理解しやすい。
| 比較軸 | バックアップ＆ロールフォワード方式 | HTML 手元保存方式 |
|---|---|---|
| 復旧対象 | DB 全体の状態。 | 記事本文 HTML。 |
| 復旧粒度 | 時刻または log position による細かい復旧が可能である。 | ファイル単位、記事単位での手作業復旧である。 |
| 必要な前提 | 基準バックアップ、連続したログ、位置情報、復旧手順、検証環境が必要である。 | 対象記事の HTML ファイルが手元にあればよい。 |
| 平時の運用負荷 | 高い。ログ退避、容量、監視、権限、復旧訓練が必要である。 | 低い。日次以後に書いた本文を保存するだけである。 |
| 復旧時の判断負荷 | 高い。どの時点までロールフォワードするか判断する必要がある。 | 低い。対象記事の本文を貼り直すだけである。 |
| セキュリティリスク | 高くなりやすい。DB 変更内容を含むログを追加で守る必要がある。 | 比較的低い。本文 HTML のみを守ればよい。 |
| 維持コスト | 高い。DB 設定、ログ保持、復旧手順、監視の継続的な管理が必要である。 | 低い。命名規則と保存場所を守れば維持できる。 |
| 向いている対象 | 注文、決済、会計、頻繁に更新される業務 DB。 | 原稿、記事、文書、手作業で復旧可能な意味内容。 |
したがって、技術選択では「より完全に戻せる方式」を無条件に選ぶべきではない。重要なのは、守りたい価値に対して、復旧能力と運用コストが釣り合っているかである。注文 DB や会計 DB であれば、バックアップ＆ロールフォワード方式の煩雑さを受け入れる価値がある。日次単位の損失が許されず、復旧対象も DB 全体の整合性だからである。しかし、今回のように守りたいものが日次以後の本文であり、復旧は手作業でよいなら、同じ方式は過剰である。
この章で確認すべき本質は、正攻法と最適解は一致しない場合があるということである。binary log / PITR やバックアップ＆ロールフォワードは、DB 復旧の正攻法である。しかし、正攻法は対象が DB 全体である場合に強い。対象が本文 HTML という意味内容であるなら、DB 全体を復旧するより、本文を可搬形式で直接保存する方が単純で、安く、間違いにくい。運用設計では、技術的な完全性だけでなく、維持可能性、復旧時の認知負荷、将来の自分が迷わず扱えるかまで含めて判断しなければならない。
6. binary log / PITR という正攻法
binary log による Point-in-Time Recovery は、DB 復旧の正攻法である。MySQL の公式 documentation では、フルバックアップを復元した後、binary log を使って特定時点まで更新を再適用する一般的な考え方が説明されている[7]。mysqlbinlog は binary log ファイルを処理するためのユーティリティであり、binary log を読んで SQL として適用できる[8]。さらに、イベント位置を使えば、問題のある更新の直前で適用を止める復旧もできる[9]。
これは非常に強力である。日次 dump だけでは dump 時点までしか戻れないが、binary log があれば dump 後の更新を再適用できる。誤操作が発生した時刻や event position が分かるなら、その直前まで戻すこともできる。業務 DB では、この能力は重要である。
しかし、PITR は「binary log を有効にすれば終わり」ではない。基準バックアップと log position の対応が必要である。binary log の保存期間と退避先が必要である。復元先でどの dump を戻し、どの binary log をどこからどこまで適用するかを決める必要がある。
MariaDB の documentation でも、binary log は DB 変更を記録し、レプリケーションと Point-in-Time Recovery に用いられるものとして整理されている[10]。また、PITR ではバックアップされたデータディレクトリーを復元したうえで、binary log data を特定時点まで復元するという考え方が示されている[11]。つまり、PITR は DB 復元の標準的な考え方である。ただし、復元手順の訓練と検証まで含めて初めて運用になる。
この考え方は MySQL や MariaDB に固有ではない。PostgreSQL では、base backup と WAL archive を組み合わせる[12]。Oracle Database では、バックアップと archived redo log、RMAN、Flashback などを組み合わせる[13][14]。SQL Server では、full backup、differential backup、transaction log backup を組み合わせ、STOPAT などによって特定時点への復元を行う[15][16]。Snowflake では、従来型の binary log を利用者が直接管理するのではなく、Time Travel、Fail-safe、バックアップ、レプリケーション、フェールオーバーといったマネージドな機能によって、過去状態参照、オブジェクト復元、災害復旧を扱う[17][18]。実装名は異なるが、技術思想としては「ある時点の状態」と「その後または過去の状態を再構成する仕組み」を組み合わせる点で共通している。
| 製品・方式 | 基準状態 | 履歴・変更・過去状態の仕組み | 復旧の考え方 | 利用者が管理する主なもの |
|---|---|---|---|---|
| MySQL | mysqldump、物理バックアップ。 | binary log。 | 基準バックアップをリストアし、binary log を必要な時点または event position まで適用する。 | binary log の有効化、保持期間、退避、基準 backup との対応、mysqlbinlog による適用範囲。 |
| MariaDB | mariadb-backup、dump、物理バックアップ。 | binary log。 | バックアップ済みデータをリストアし、binary log data を特定時点まで適用する。 | binary log、backup metadata、復旧対象時刻、ログの連続性。 |
| PostgreSQL | base backup、ファイルシステムバックアップ。 | WAL archive。 | base backup をリストアし、archived WAL を recovery target まで再生する。 | WAL archive の継続性、archive_command、restore_command、recovery target、base backup との対応。 |
| Oracle Database | RMAN backup、datafile backup。 | redo log、archived redo log、Flashback log。 | バックアップをリストアし、archived redo log などを使って指定時点、SCN、restore point へ復旧する。 | RMAN catalog、ARCHIVELOG mode、archived redo log、restore point、Flashback 設定。 |
| SQL Server | full backup、differential backup。 | transaction log backup。 | full backup と必要な differential backup を戻し、transaction log backup を STOPAT などで目標時点まで適用する。 | recovery model、log backup、backup chain、tail-log backup、復旧停止時刻。 |
| Snowflake | マネージドストレージ上のデータ、必要に応じた backup。 | Time Travel、Fail-safe、zero-copy clone、backup、replication / failover。 | 保持期間内の過去データを参照・clone・復元し、Fail-safe は Snowflake 側の最終的な復旧手段として扱う。 | DATA_RETENTION_TIME_IN_DAYS、オブジェクト種別、Time Travel 保持期間、Fail-safe の制約、バックアップセット、レプリケーション設計。 |
ここで重要なのは、製品ごとの用語差に惑わされないことである。MySQL の binary log、PostgreSQL の WAL、Oracle の redo log、SQL Server の transaction log は、いずれも「変更を記録し、整合した状態へ戻すための履歴」という意味では同型である。ただし、それぞれの DBMS でログの物理構造、保存場所、復旧手順、管理ツール、停止位置の指定方法、バックアップとの対応づけは異なる。したがって、抽象的には同じ PITR でも、運用手順は製品ごとに別物として設計しなければならない。
| 共通する構造 | 内容 | 実務上の意味 |
|---|---|---|
| 基準点が必要である。 | フルバックアップ、base backup、RMAN backup、full backup など、復元の出発点が必要である。 | 変更ログだけでは復旧できない。 |
| 履歴が連続している必要がある。 | binary log、WAL、archived redo log、transaction log backup が途中で欠けてはいけない。 | 1 区間でも欠けると、その先の状態を正しく再構成できない。 |
| 停止点を決める必要がある。 | 時刻、event position、LSN、SCN、restore point、STOPAT などで復旧目標を指定する。 | 誤操作後まで進めると、壊れた状態を再現してしまう。 |
| 復旧検証が必要である。 | 復旧先環境で、DB とアプリケーションが業務上使えるかを確認する。 | ログ適用に成功しても、業務復旧に成功したとは限らない。 |
| ログ自体が機密情報を含み得る。 | 変更後の値、SQL、取引、個人情報、本文などが履歴に含まれる場合がある。 | バックアップファイルだけでなくログも本番データと同等に保護する必要がある。 |
一方で、差異も大きい。MySQL / MariaDB では binary log がレプリケーションと PITR の両方に関わるため、DB 管理者はログファイルの保持、ローテーション、退避、mysqlbinlog による適用を意識しやすい。PostgreSQL では WAL がクラッシュリカバリー、ストリーミングレプリケーション、PITR の基盤であり、archive_command と restore_command の設計が重要になる。Oracle では RMAN、ARCHIVELOG mode、SCN、restore point、Flashback など、復旧体系がより統合的に整理されている。SQL Server では recovery model と log backup chain が重要であり、full backup、differential backup、transaction log backup の順序を崩さないことが重要になる。Snowflake では、利用者が低レベルのログファイルを直接扱うのではなく、Time Travel や Fail-safe などのマネージド機能として過去状態や復旧可能性を扱う。
| 観点 | 従来型 RDBMS の PITR | Snowflake の Time Travel / Fail-safe |
|---|---|---|
| 利用者が扱う単位 | バックアップファイル、ログファイル、LSN、SCN、position、時刻。 | テーブル、スキーマ、データベース、保持期間、UNDROP、CLONE、AT / BEFORE。 |
| 復旧思想 | 基準バックアップを戻し、ログをロールフォワードする。 | 保持期間内の過去状態をサービス側の機能として参照・複製・復元する。 |
| 運用負荷 | ログ退避、容量管理、停止位置判断、復旧訓練が必要になる。 | 低レベルログ管理は不要だが、保持期間、コスト、権限、オブジェクト種別の制約を理解する必要がある。 |
| 復旧可能期間 | バックアップとログを保持している範囲に依存する。 | Time Travel の retention period と Fail-safe の仕様に依存する。 |
| 制約 | ログが欠けると復旧できず、適用停止位置を誤ると壊れた状態まで進む。 | Time Travel の保持期間外は通常の利用者操作では戻せず、Fail-safe は利用者が自由に過去参照する機能ではない。 |
| 向いている復旧 | トランザクション整合性を維持した DB 全体または一部の時点復旧。 | 分析基盤における過去データ参照、誤削除復旧、clone による検証、マネージドなデータ保護。 |
Snowflake は、従来型 RDBMS の PITR と同じ問題領域を扱うが、設計思想が異なる。MySQL や PostgreSQL では、管理者がバックアップとログを管理し、必要な範囲をリストアしてロールフォワードする。一方、Snowflake では、Time Travel によって保持期間内の過去状態を問い合わせたり clone したりし、ドロップされた table、schema、database を UNDROP できる。Fail-safe は Time Travel の保持期間後に続く復旧可能性の層だが、利用者が自由に過去データへアクセスするための機能ではなく、極端な障害時に Snowflake 側が復旧するための仕組みとして扱う必要がある。
この違いは、技術の進化を示している。従来型 RDBMS では、復旧は「バックアップファイルとログファイルを管理者が扱う運用」である。クラウドデータプラットフォームでは、復旧は「サービス側が履歴データを保持し、利用者が保持期間と復旧操作を制御する機能」へ移っている。しかし、抽象化されても本質は消えない。保持期間を過ぎれば戻せない。権限がなければ復元できない。復旧対象が table なのか database なのか、履歴を参照するのか clone するのか、本番へ戻すのかを判断しなければならない。つまり、低レベルのログ管理が見えなくなっても、復旧設計の判断は残る。
この章で確認すべき本質は、PITR とは特定製品の機能名ではなく、「基準状態と履歴を組み合わせて、望ましい時点の状態を再構成する設計思想」だということである。MySQL では binary log、PostgreSQL では WAL、Oracle では archived redo log、SQL Server では transaction log backup、Snowflake では Time Travel / Fail-safe という形を取る。名前や操作体系は違うが、どれも「現在だけでなく過去状態を保持し、必要に応じて復元可能にする」ための仕組みである。
ただし、この正攻法は強力である一方、すべての問題に対して最適ではない。業務 DB、注文、会計、決済、顧客データのように、DB 全体の整合性と細かい復旧時点が重要な場合には、PITR やそれに相当する仕組みを設計する価値が高い。一方、今回の WordPress 原稿のように、守りたい価値が日次以後に書いた本文 HTML であり、復旧は手作業でよい場合、DB 全体の PITR は過剰になる。技術を横断的に見ても、最終的な判断は同じである。高度な復旧機構を知ったうえで、対象価値に対して必要十分な方式を選ぶべきである。
7. 手元物理マシンへのレプリケーション
MySQL では GTID を使ったレプリケーションにより、source と replica の間でトランザクション識別子を扱い、複製状態の追跡やフェールオーバーを扱いやすくできる[19]。GTID は、どのトランザクションがどのサーバーで発生し、どこまで replica に適用されたかを識別するための仕組みである。従来の file / position ベースのレプリケーションでは、復旧時にどの binary log のどの位置から再開するかを人間が慎重に扱う必要があった。GTID ベースでは、トランザクション単位で進捗を追えるため、replica の追加、source の切り替え、フェールオーバー後の再構成が扱いやすくなる。
ただし、ここで考えるべき本質は MySQL の GTID そのものではない。レプリケーションとは、単一障害点を減らすために、ある場所の状態を別の場所へ継続的に複製する仕組みである。単一障害点とは、その一点が壊れると全体が止まる箇所である。本番 DB サーバーが 1 台だけなら、そのサーバーが壊れた時点で DB は利用不能になる。本番 DB が単一データセンターにしかなければ、その拠点障害で止まる。本番 DB のバックアップが同じホスト上にしかなければ、そのホスト喪失でバックアップも失われる。レプリケーションは、このような単一障害点を分散し、本番障害時にも別の系でサービス継続またはデータ取り出しを可能にするための技術である。
手元物理マシンへの replica 配置は、この考え方の個人運用版である。本番 VPS の DB を手元物理マシンへ複製しておけば、本番サーバーが消失しても、手元に近い状態の DB を保持できる。これは、本番ホスト喪失という物理障害に対しては一定の意味がある。特に、VPS 事業者側の障害、ストレージ破損、アカウント凍結、誤ってインスタンスを削除した場合には、本番とは別の管理境界に replica があること自体がリスク低減になる。
しかし、レプリケーションはバックアップではない。レプリケーションは現在状態を複製する仕組みであり、可用性を高める技術である。誤って記事を削除すれば、その削除も replica に流れる。アプリケーションの不具合で本文が壊れれば、壊れた本文も replica に流れる。攻撃者が本番 DB を改ざんすれば、その改ざんも replica に反映される可能性がある。つまり、レプリケーションは本番障害には強いが、論理破壊、誤操作、ランサムウェア、アプリケーションバグに対しては、むしろ壊れた状態を高速に複製する仕組みになり得る。
| 目的 | レプリケーションが効く理由 | レプリケーションだけでは不十分な理由 |
|---|---|---|
| 本番ホスト障害への対策 | 別ホストに近い状態の DB を保持できる。 | フェールオーバー手順、DNS、アプリケーション接続先、整合性確認が別途必要である。 |
| ストレージ障害への対策 | 別ストレージにデータが存在する。 | 破壊的更新や誤削除はそのまま複製される。 |
| 読み取り負荷分散 | 読み取り replica に SELECT を逃がせる。 | 更新系の可用性や過去状態復元とは別問題である。 |
| 災害対策 | 別拠点や別リージョンに replica を置けば拠点障害に耐えやすくなる。 | レプリケーション遅延、ネットワーク断、昇格手順、データ欠損リスクを扱う必要がある。 |
| 誤操作対策 | 遅延 replica を使えば、一定時間内なら誤操作前の状態が残る可能性がある。 | 通常の即時 replica では誤操作も即座に複製される。 |
レプリケーションには複数の方式がある。単純な primary-replica 型、同期レプリケーション、非同期レプリケーション、準同期レプリケーション、遅延レプリケーション、論理レプリケーション、物理レプリケーション、マルチ primary、クラウドマネージドな Multi-AZ、フェールオーバーグループなどである。名称は製品ごとに異なるが、設計上の軸は、同期性、複製単位、昇格方法、書き込み可能なノード数、障害検知、自動フェールオーバー、地理分散、整合性保証に分けられる。
| 方式 | 概要 | 強いもの | 弱いもの |
|---|---|---|---|
| 非同期 primary-replica | primary の変更を replica へ遅れて適用する。 | 構成が比較的単純で、遠隔地にも置きやすい。 | 障害直前の変更が replica に届いていない可能性がある。 |
| 同期レプリケーション | replica 側への反映を待ってから commit を完了させる。 | データ損失を小さくしやすい。 | 遅延やネットワーク障害が本番性能と可用性に影響する。 |
| 準同期レプリケーション | 一部の replica への到達を確認してから commit を返す。 | 性能と損失抑制の折衷になる。 | 完全同期ではなく、障害条件によっては損失が残る。 |
| 遅延レプリケーション | 意図的に replica への適用を遅らせる。 | 誤削除や破壊的更新の直後なら、遅延 replica から救える可能性がある。 | 本番障害時の最新状態復旧には向かない。 |
| 物理レプリケーション | ストレージブロック、WAL、redo、binary log など低レベルの変更を複製する。 | DB 全体の整合性を保ちやすい。 | 一部データだけを柔軟に複製する用途には向かない場合がある。 |
| 論理レプリケーション | テーブルや行変更など論理的な変更単位を複製する。 | 一部テーブル複製、異種構成、移行に向く。 | DDL、シーケンス、制約、競合解決などを別途考える必要がある。 |
| マルチ primary | 複数ノードで書き込みを受け付ける。 | 地理分散や書き込み可用性を高められる。 | 競合解決、整合性、運用複雑性が大きくなる。 |
| クラウド Multi-AZ / managed failover | クラウド側が standby や failover を管理する。 | 障害検知と切り替えの運用負荷を下げられる。 | サービス仕様、リージョン、コスト、ブラックボックス性に依存する。 |
製品ごとに見ると、同じ「レプリケーション」でも構造はかなり異なる。MySQL は binary log と GTID による source-replica 構成が代表的であり、GTID によりトランザクション単位で複製進捗を追える[20][21]。PostgreSQL は streaming replication により primary から standby へ WAL を送る物理レプリケーションを持ち、さらに logical replication によってテーブル単位の変更複製も扱える[22][23]。Oracle Database は Data Guard によって standby database を作成、維持、管理、監視し、災害やデータ破損に備える[24]。SQL Server は Always On Availability Groups によって、複数の user database を availability group として扱い、フェールオーバー環境を構成できる[25]。Snowflake は replication group や failover group によって、複数のデータベースやアカウントオブジェクトをポイントインタイムの整合性を保って複製し、グループ単位でフェールオーバーできる。MongoDB は replica set によって複数の mongod が同じデータセットを保持し、primary と secondary を構成する。
| 製品・基盤 | 代表的な仕組み | 複製単位 | フェールオーバーの考え方 | 単一障害点を減らす上での特徴 |
|---|---|---|---|---|
| MySQL | binary log replication、GTID replication、Group Replication。 | トランザクション、DB 変更イベント。 | replica を新 source に昇格し、アプリケーション接続先を切り替える。 | GTID により昇格後の複製再構成を扱いやすくできるが、フェールオーバー運用は別途設計が必要である。 |
| PostgreSQL | streaming replication、logical replication。 | WAL による物理変更、または logical change stream。 | standby を promote し、接続先を切り替える。 | 物理 standby は DB 全体の可用性に強く、logical replication は部分複製や移行に向く。 |
| Oracle Database | Data Guard、Active Data Guard。 | primary database と standby database。 | switchover や failover により standby を primary 化する。 | 災害対策と高可用性を前提に、監視、管理、切り替えが体系化されている。 |
| SQL Server | Always On Availability Groups。 | availability database の集合。 | availability group 単位で replica 間の failover を行う。 | 複数 DB をひとまとまりにして切り替えられるため、アプリケーション単位の可用性設計に向く。 |
| Snowflake | replication group、failover group。 | database、account object、指定されたオブジェクト群。 | フェールオーバーグループを単位として target account 側へ切り替える。 | 低レベルログではなく、マネージドなオブジェクト複製とフェールオーバーとして扱う。 |
| MongoDB | replica set。 | 同一データセットを保持する mongod の集合。 | primary 障害時に secondary から election により新 primary を選ぶ。 | 複数ノードと投票により、単一ノード障害への耐性を持たせる。 |
| Amazon RDS | Multi-AZ deployment、read replica。 | DB instance または cluster。 | 障害時に RDS が standby または replica へ failover する。 | クラウド側が障害検知と切り替えを管理するため、運用負荷を下げられる。 |
単一障害点をなくすには、単に replica を 1 台置くだけでは足りない。DB サーバーを二重化しても、接続先が固定 IP なら接続先が単一障害点になる。replica が同じラック、同じ AZ、同じクラウドアカウント、同じ認証情報、同じ削除権限の下にあれば、障害ドメインは十分に分離されていない。監視が 1 系統しかなければ、レプリケーション停止に気づけない。フェールオーバー手順が 1 人の記憶にしかなければ、人間が単一障害点になる。つまり、単一障害点はハードウェアだけではなく、ネットワーク、認証、権限、DNS、監視、運用手順、人間の知識にも存在する。
| 単一障害点 | 典型例 | レプリケーションだけで解消できるか | 追加で必要な設計 |
|---|---|---|---|
| DB サーバー | 本番 DB が 1 台だけである。 | 一部解消できる。 | replica、standby、フェールオーバー手順、昇格確認が必要である。 |
| ストレージ | DB と backup が同じディスク上にある。 | 一部解消できる。 | 別ストレージ、別ホスト、別拠点への退避が必要である。 |
| データセンター / AZ | すべてが同一拠点にある。 | 別拠点 replica なら解消に近づく。 | 地理分散、ネットワーク断時の挙動、RPO / RTO の定義が必要である。 |
| 接続先 | アプリケーションが単一ホスト名や IP に固定されている。 | 解消できない。 | VIP、DNS 切り替え、proxy、connection endpoint、サービスディスカバリが必要である。 |
| 認証情報 | 本番と replica の管理権限が同じ認証情報に依存している。 | 解消できない。 | 権限分離、秘密情報管理、緊急時アクセス手順が必要である。 |
| 監視 | レプリケーション停止や遅延を検知できない。 | 解消できない。 | lag 監視、heartbeat、アラート、定期確認が必要である。 |
| 運用者 | 復旧手順を特定の 1 人しか知らない。 | 解消できない。 | 手順書、訓練、権限委譲、復旧チェックリストが必要である。 |
| 論理破壊 | 誤削除、誤更新、バグ、侵害による改ざん。 | 通常の即時 replica では解消できない。 | バックアップ、PITR、遅延 replica、世代管理、隔離が必要である。 |
個人運用で手元物理マシンに常時 replica を置く場合、さらに固有の問題がある。手元マシンは常時起動しているのか。スリープや再起動で replication lag が発生したときにどう扱うのか。自宅回線の切断、グローバル IP 変更、ファイアウォール、VPN、NAT 越えをどう扱うのか。認証情報を手元に保存することで、本番 DB へ入る経路を増やしていないか。レプリケーション停止をどう検知するのか。復旧時に replica をどのように使うのか。replica を本番へ昇格するのか、dump の取り出し元として使うだけなのか。これを決めない限り、手元 replica は安心材料にはなるが、実運用上の復旧手段にはならない。
| 個人運用での確認項目 | 確認すべき問い | 曖昧な場合に起きること |
|---|---|---|
| 常時稼働性 | 手元物理マシンは常時起動しているか。 | 停止中の変更が蓄積し、復旧時点が不明確になる。 |
| ネットワーク | 本番から手元へ安全に接続できるか。 | VPN、ファイアウォール、NAT、IP 変更が運用負荷になる。 |
| 認証情報 | replication user の権限と秘密情報をどう保護するか。 | 本番 DB への攻撃面が増える。 |
| 遅延監視 | replication lag をどう検知するか。 | 最新状態だと思っていた replica が古い可能性がある。 |
| 停止検知 | レプリケーション停止時にどう気づくか。 | 必要なときに replica が役に立たない。 |
| 復旧用途 | replica を昇格するのか、dump 取得元にするのか。 | 障害時に使い方を判断できない。 |
| 論理破壊対策 | 誤削除や改ざんも複製されることをどう補うか。 | 壊れた状態だけが手元にも残る。 |
ここで重要なのは、レプリケーションによって「何の単一障害点を消したいのか」を明確にすることである。本番 VPS の物理喪失を恐れているなら、手元 replica は一定の意味がある。本番 DB の誤削除を恐れているなら、即時 replica では不十分であり、遅延 replica、PITR、世代バックアップが必要になる。自宅と VPS の両方の災害を考えるなら、第三の遠隔拠点やクラウドストレージも必要になる。単一障害点を消すには、対象とする障害ドメインを明示しなければならない。
したがって、レプリケーション設計の本質は「コピーを増やすこと」ではない。単一障害点を洗い出し、それを別の障害ドメインへ分散し、障害時にどの replica をどのように昇格または利用するかを事前に決めることである。レプリケーションは可用性を高める強力な技術だが、バックアップではない。過去状態へ戻る能力は、世代バックアップ、PITR、遅延 replica、隔離された保存先によって別途設計する必要がある。
今回の WordPress 原稿保全に戻ると、手元物理マシンへの replica は、本番ホスト障害への対策としては意味がある。しかし、日次バックアップ以後に書いた本文を守るという目的に対しては、過剰であり、しかも誤削除や本文破壊を防げない。手元 replica を維持するには、常時起動、ネットワーク、認証情報、遅延監視、停止検知、復旧手順が必要になる。これに対して、本文 HTML を手元に保存する方法は、DB 全体の可用性は高めないが、失いたくない意味内容を直接守る。したがって、レプリケーションは別目的の技術として理解し、今回の本文保全とは切り分けるべきである。
8. hourly dump や短周期 dump
日次 dump より細かい短周期 dump は、直感的には分かりやすい。1 時間ごとに dump を取れば、最悪でも 1 時間前程度まで戻せる。小規模な WordPress であれば、DB サイズも大きくなく、取得負荷や保存容量も許容できる可能性がある。binary log / PITR のように event position を扱う必要もなく、レプリケーションのように source と replica の状態を常時監視する必要もない。仕組みとしては「今より頻繁に dump を取る」だけなので、理解しやすく、導入時の心理的抵抗も小さい。
しかし、短周期 dump は「日次バックアップより細かく戻せる」方式であって、「守りたい意味内容だけを正確に守る」方式ではない。1 時間ごとの dump は、DB 全体を 1 時間単位で保存する。したがって、投稿本文だけでなく、コメント、アクセス統計、プラグイン設定、セッション系データ、投稿メタ、リビジョン、cron 関連情報、その他の内部状態もまとめて保存される。これは強みでもあるが、同時に弱みでもある。復旧時には、本文だけ戻したいのか、DB 全体を 1 時間前へ戻したいのかを判断しなければならない。
短周期 dump の最大の利点は、仕組みの単純さと RPO の短縮である。日次 backup では最大 24 時間分の更新が失われる可能性があるが、hourly dump なら理屈上は最大 1 時間程度に抑えられる。さらに、SQL dump は人間が概念として理解しやすい。ファイルとして保存され、世代が見え、復元も比較的説明しやすい。binary log の連続性や event position を扱うより、運用者にとって認知負荷が低い場合がある。
| 観点 | 短周期 dump のメリット | 実務上の意味 |
|---|---|---|
| RPO | 日次 backup より失われる時間範囲を短くできる。 | 日中に発生した更新をある程度守れる。 |
| 理解容易性 | dump ファイルを世代として持つだけなので構造が分かりやすい。 | binary log / PITR より導入と説明が容易である。 |
| 独立性 | 各 dump は単独の復元候補になる。 | ログの連続性が欠けると復旧不能になる方式より扱いやすい。 |
| 検証容易性 | 任意の dump を検証環境へ戻しやすい。 | 復元テストや差分確認を実施しやすい。 |
| 小規模環境との相性 | DB が小さければ負荷と容量が許容範囲に収まりやすい。 | 個人ブログや小規模 CMS では現実的な選択肢になる。 |
一方で、短周期 dump には明確な限界がある。第一に、取得頻度を上げても、dump 間の空白は残る。1 時間ごとなら最大 1 時間、10 分ごとなら最大 10 分の空白がある。第二に、DB 全体を戻す方式であるため、目的外の更新まで巻き戻す可能性がある。たとえば 15 時の dump を戻せば、15 時以後に書いた本文は戻るかもしれないが、同時に 15 時以後のコメント、別記事の更新、プラグイン設定変更、ユーザー操作も巻き戻る。第三に、dump の世代数が増えれば、保存容量、転送量、削除ポリシー、復旧時の選択肢が増える。選択肢が増えることは、復旧時の判断負荷が増えることでもある。
| 限界 | 内容 | 実務上の問題 |
|---|---|---|
| 空白は残る | 取得間隔を短くしても、最後の dump 以後の更新は守れない。 | 完全なゼロ損失にはならない。 |
| 復旧単位が広い | 本文だけでなく DB 全体を戻す。 | 目的外の更新を巻き戻す可能性がある。 |
| 世代が増える | 1 日 1 世代ではなく、1 日 24 世代、10 分ごとなら 144 世代になる。 | 保存容量、転送量、削除ルール、管理対象が増える。 |
| 復旧判断が増える | どの時点の dump を戻すかを選ばなければならない。 | 障害時に誤った世代を選ぶ危険がある。 |
| 整合性確認が必要 | dump 取得中の更新、アプリケーション状態、ファイルとの整合を考える必要がある。 | DB だけ戻っても WordPress 全体として正しいとは限らない。 |
| 機密データが増える | DB 全体のコピーを大量に保持する。 | 漏えい時の影響範囲と保護対象が増える。 |
短周期 dump の難しさは、技術的には単純でも、運用上は「復旧候補が増える」ことにある。日次 dump なら、通常は「昨日の dump を戻す」という判断で済む。hourly dump では、13 時、14 時、15 時、16 時のどれを戻すのかを選ぶ必要がある。誤削除が 15 時 20 分なら 15 時の dump が候補になるが、その間に別の重要な更新があれば、それも失われる。短周期 dump は RPO を短くするが、復旧時の粒度は依然として dump 単位であり、トランザクション単位ではない。
ここで、バックアップ＆ロールフォワード方式との違いが見える。短周期 dump は、複数の基準点を細かく作る方式である。PITR は、少数の基準点と連続した変更ログを組み合わせる方式である。前者は単純だが、復旧点は dump の時刻に離散化される。後者は細かく戻せるが、ログ連続性、停止位置、復旧手順の管理が重い。どちらも「日次 backup より細かく戻したい」という目的に対応するが、設計思想が異なる。
| 方式 | 復旧点の作り方 | 強み | 弱み | 向いている対象 |
|---|---|---|---|---|
| 短周期 dump | 1 時間ごと、10 分ごとなどに DB 全体の基準点を多数作る。 | 理解しやすく、各 dump が単独の復元候補になる。 | 復旧点は dump 時刻に限られ、保存量と世代管理が増える。 | 小規模 DB、簡易な世代復旧、低負荷な個人・小規模運用。 |
| バックアップ＆ロールフォワード | 基準バックアップから変更ログを適用して任意時点へ近づける。 | 細かい時点まで復旧しやすく、トランザクション単位の整合性を扱える。 | ログ保持、停止位置、復旧訓練、セキュリティ管理が重い。 | 注文、決済、会計、顧客 DB など高頻度更新の業務 DB。 |
| HTML 手元保存 | 日次以後に作成・編集した本文を記事単位で保存する。 | 守りたい意味内容を直接保全でき、復旧時の認知負荷が低い。 | DB 全体、投稿メタ、コメント、設定変更は戻せない。 | 原稿、文書、手作業で戻せる意味内容。 |
各製品によっても、短周期 backup に対する考え方は異なる。MySQL では mysqldump による logical backup を短周期化することは可能だが、DB サイズが大きくなると取得負荷、ロック、I/O、転送量が問題になる。そのため、実務では物理バックアップ、binary log、レプリケーション、クラウドスナップショットを組み合わせることが多い。PostgreSQL では、単に pg_dump を頻繁に取るよりも、base backup と WAL archive によって連続的な復旧可能性を確保する発想が強い。Oracle では RMAN による backup、incremental backup、archived redo log、Flashback を組み合わせ、復旧要件に応じて設計する。SQL Server では full backup、differential backup、transaction log backup の組み合わせが基本になる。Snowflake では、利用者が hourly dump を取るというより、Time Travel、zero-copy clone、retention period、Fail-safe、replication / failover のようなマネージドな過去状態管理を使う発想になる。
| 製品・基盤 | 短周期 backup に相当する考え方 | 設計思想 | 注意点 |
|---|---|---|---|
| MySQL | 短周期 mysqldump、物理 backup、binary log の組み合わせ。 | logical dump は分かりやすいが、細かい復旧には binary log を併用する。 | dump 負荷、ロック、容量、binary log の保持を考える必要がある。 |
| MariaDB | mariadb-dump、mariadb-backup、binary log の組み合わせ。 | logical backup と物理 backup を用途に応じて使い分ける。 | データ量が増えるほど dump の短周期化は重くなる。 |
| PostgreSQL | pg_dump の短周期化、base backup と WAL archive。 | 頻繁な dump より、WAL による継続的な履歴保全を重視しやすい。 | WAL archive の連続性、restore_command、recovery target が重要になる。 |
| Oracle Database | RMAN backup、incremental backup、archived redo log、Flashback。 | 単純な dump ではなく、復旧体系全体として backup と recovery を管理する。 | ARCHIVELOG mode、RMAN catalog、restore point、保持ポリシーを理解する必要がある。 |
| SQL Server | full backup、differential backup、transaction log backup。 | full backup を基準に、差分と transaction log で復旧点を細かくする。 | recovery model、backup chain、tail-log backup、STOPAT の理解が必要である。 |
| Snowflake | Time Travel、zero-copy clone、retention period、Fail-safe、replication。 | 利用者が dump を頻繁に取るのではなく、サービス側の過去状態管理を利用する。 | 保持期間、コスト、権限、Fail-safe の制約を理解する必要がある。 |
ここで見えてくるのは、製品ごとの哲学の違いである。MySQL や MariaDB のような構成では、管理者が dump、binary log、物理 backup、replication を組み合わせて自分で設計する色彩が強い。PostgreSQL では WAL を中心に、base backup と archive recovery を組み合わせる発想が強い。Oracle や SQL Server では、商用 DB として backup / recovery の体系が製品機能として厚く用意されており、管理者はその体系に沿って設計する。Snowflake のようなクラウドデータプラットフォームでは、低レベルのファイルやログを直接扱うのではなく、保持期間と過去状態参照の機能として復旧を考える。
つまり、短周期 dump は、分かりやすいが万能ではない。小規模で、復旧点が多少粗くてもよく、DB 全体を戻しても問題が少ない環境では有効である。しかし、更新頻度が高い業務 DB、厳密な整合性が必要な DB、復旧時点を細かく指定したい DB では、短周期 dump だけでは限界がある。その場合は、WAL、binary log、redo log、transaction log、PITR、managed Time Travel のような、履歴を扱う仕組みを検討すべきである。
一方で、今回の WordPress 原稿保全では、短周期 dump はまだ対象範囲が広すぎる。本文を守りたいだけなのに、DB 全体を 1 時間ごとに保存することになる。しかも、復旧時には dump を戻すことで他の更新を巻き戻す可能性がある。日次以後に書いた本文を HTML として保存しておけば、DB 全体を戻さずに、失われた本文だけを復元できる。これは短周期 dump よりも復旧範囲が狭く、判断が単純で、維持コストも低い。
したがって、短周期 dump は「日次 dump より細かいから良い」と単純には言えない。RPO を短くする効果はあるが、復旧単位が DB 全体であること、保存世代が増えること、復旧時の選択肢が増えること、目的外の更新を巻き戻すこと、機密データのコピーが増えることを考えなければならない。技術選択の本質は、取得頻度を上げることではなく、守りたい価値に対して適切な粒度で、維持可能な復旧経路を作ることである。
9. 投稿本文を HTML として手元保存する方法
最終的に採用したのは、投稿本文を HTML として手元に保存する方法である。これは WordPress 全体の完全復元ではない。DB の任意時点復元でもない。投稿メタ、カテゴリー、タグ、予約日時、コメント、カスタムフィールド、画像ファイル本体を包括的に守る方法でもない。しかし、日次バックアップ以後に人間が書いた本文を守るという目的には最も直接効く。
記事本文を HTML として扱う運用では、HTML は単なる出力形式ではなく、本文の可搬な正本に近い。段落、見出し、表、参考文献リンク、MathJax、アンカー、注釈構造を保持できる。DB がなくてもテキストエディターで読める。Git に置けば差分も取れる。別の WordPress、静的サイト、ローカル HTML としても再利用できる。
ここで重要なのは、HTML 保存が「低機能な代替策」ではないということである。むしろ、守りたい対象を本文という意味内容に限定した場合、HTML 保存はきわめて根源的な方法である。WordPress の DB スキーマ、プラグインの内部仕様、投稿リビジョンの保持方式、REST API の挙動、テーマの表示仕様、ブロックエディターの内部表現に依存せず、本文そのものを人間が読める形式で保持する。これは、システム内部状態を完全に保存する方法ではなく、価値ある意味内容をシステムから抽出して保存する方法である。
| 観点 | WordPress DB 内部に閉じた状態 | HTML として手元保存した状態 |
|---|---|---|
| 可読性 | DB、管理画面、API、復元環境が必要になる。 | テキストエディターやブラウザーで直接読める。 |
| 可搬性 | WordPress の DB 構造や環境に依存する。 | 別 WordPress、静的 HTML、ローカル保存、Git 管理へ移せる。 |
| 差分管理 | DB dump 全体の差分は読みにくい。 | Git や diff で本文差分を確認しやすい。 |
| 復旧単位 | DB 全体またはテーブル単位になりやすい。 | 記事単位、本文単位で戻せる。 |
| 依存関係 | MySQL、WordPress、プラグイン、テーマ、管理画面に依存する。 | 標準的なテキスト形式と HTML の知識だけで扱える。 |
| 障害時の判断負荷 | どの DB dump を戻すか、何を巻き戻すかを判断する必要がある。 | 失われた本文ファイルを開き、必要な箇所を貼り直せばよい。 |
この方法は、ベンダーロックインを避けるという意味でも重要である。ベンダーロックインとは、特定製品、特定サービス、特定 DB、特定クラウド、特定プラグインの仕様に依存しすぎて、データの移動や復旧や再利用が難しくなる状態である。WordPress はオープンソースであり、DB も MySQL / MariaDB として扱えるため、典型的な閉鎖的 SaaS とは異なる。しかし、それでも投稿本文を WordPress の内部状態にだけ置けば、復旧時には WordPress 環境、DB、文字コード、テーブル構造、投稿状態、管理画面の操作に依存する。本文を HTML として保持すれば、この依存を大きく減らせる。
この意味で、HTML 保存は「WordPress を信用しない」という話ではない。WordPress は公開と管理のための優れたアプリケーションであり、日次 mysqldump は基準バックアップとして有効である。しかし、記事本文という価値そのものを WordPress の内部状態に完全依存させる必要はない。アプリケーションは意味内容を扱うための環境であり、意味内容そのものではない。環境は壊れる。仕様は変わる。プラグインは廃止される。DB バージョンは変わる。テーマは変更される。だが、本文 HTML があれば、少なくとも記事としての中核は残る。
| ロックインの対象 | 依存すると起きる問題 | HTML 保存で軽減できること |
|---|---|---|
| DB スキーマ | テーブル構造やメタデータの意味を理解しないと復旧しにくい。 | 本文だけなら DB 構造を理解しなくても読める。 |
| 管理画面 | 管理画面に入れないと本文を確認・編集できない。 | ローカルのテキストエディターで確認できる。 |
| プラグイン仕様 | ショートコード、ブロック、カスタムフィールドの扱いが変わる。 | 記事本文として必要な HTML 構造を独立して保持できる。 |
| クラウド・ホスティング | サーバー、アカウント、ストレージ、管理権限の障害に巻き込まれる。 | 手元に本文の正本を残せる。 |
| 製品バージョン | 将来の仕様変更で古いデータの扱いが変わる。 | 標準的な HTML として長期的に読める。 |
製品間の仕様に振り回されないことも、この運用の利点である。MySQL には binary log がある。PostgreSQL には WAL がある。Oracle には archived redo log や RMAN がある。Snowflake には Time Travel や Fail-safe がある。どれも強力だが、いずれも製品ごとの思想、用語、権限、保持期間、復旧手順、制約を理解しなければならない。これに対して、HTML 保存は、DB 製品の差異をいったん横断してしまう。本文という意味内容を HTML として保存する限り、MySQL であろうが PostgreSQL であろうが、WordPress であろうが静的サイトであろうが、復旧の中核は変わらない。
これは、技術を軽視する態度ではない。むしろ逆である。技術を理解したうえで、どの層で問題を解くべきかを選ぶ態度である。DB 全体の整合性を守るなら、binary log、WAL、redo log、transaction log、PITR、replication を検討すべきである。しかし、本文という意味内容を守るだけなら、DBMS の復旧機構に入る前に、本文を可搬形式で保持する方が本質的である。問題を低い層で解くほど、製品仕様、運用手順、権限管理、復旧訓練が重くなる。問題を意味内容の層で解けるなら、その方が単純で、長期的に壊れにくい。
| 解決する層 | 代表的な方法 | 強み | 負担 | 今回の本文保全との相性 |
|---|---|---|---|---|
| DBMS 層 | binary log、WAL、redo log、transaction log、PITR。 | DB 全体を整合的に戻せる。 | 製品別手順、ログ管理、停止位置判断、検証が必要になる。 | 強力だが過剰になりやすい。 |
| アプリケーション層 | WordPress export、REST API、管理画面からの export。 | アプリケーション意味に近い単位で取り出せる。 | アプリケーション仕様、認証、エクスポート形式に依存する。 | 有効だが、仕様依存は残る。 |
| 意味内容層 | 本文 HTML、Markdown、plain text、CSV、PDF。 | 人間が読め、移動しやすく、再利用しやすい。 | システム全体の完全復元はできない。 | 今回の目的に最も合う。 |
| 運用記憶層 | Markdown ルール、復旧手順、チェックリスト。 | 未来の自分が判断しやすい。 | 更新を怠ると実態とずれる。 | 本文 HTML と組み合わせると強い。 |
この考え方は、システム運用に限らない。日常のデータ管理でも同じである。写真管理アプリに写真を置くだけではなく、元ファイルと撮影メタデータを可搬な形で残す。家計簿アプリに入力するだけではなく、CSV や PDF の帳票を残す。クラウドメモに考えを書くだけではなく、重要な文章を Markdown として保存する。チャットで合意するだけではなく、決定事項を文書に反映する。SaaS は便利だが、意味内容を閉じ込める箱にしてはいけない。
| 日常領域 | システム内部に閉じた状態 | 可搬形式として残す対象 | 得られる効果 |
|---|---|---|---|
| 写真 | 写真管理アプリやクラウドアルバムだけに保存する。 | JPEG、RAW、撮影日時、位置情報、整理メモ。 | アプリ移行やアカウント障害に強くなる。 |
| 家計・会計 | 会計ソフトや家計簿アプリだけに記録する。 | CSV、PDF 帳票、証憑ファイル。 | 監査、確定申告、サービス移行に耐えやすい。 |
| 調査メモ | ブラウザー履歴やブックマークだけに頼る。 | Markdown、URL 一覧、引用メモ、判断メモ。 | 調査過程と結論を再利用しやすい。 |
| 仕事上の合意 | Slack / Teams の会話だけに残す。 | 議事録、設計書、決定事項ログ。 | 後から判断根拠を確認しやすい。 |
| 文章・原稿 | CMS、クラウド文書、投稿画面だけに保存する。 | HTML、Markdown、plain text。 | 環境に依存せず本文を復元できる。 |
この運用の哲学は、単純化ではなく抽象化である。単純化とは、面倒だから機能を削ることではない。抽象化とは、対象の本質を取り出し、それをより少ない依存関係で扱える形にすることである。今回の本質は、WordPress の DB を完全に再現することではなく、日次バックアップ以後に書いた本文を失わないことである。ならば、本文を HTML として保存する。これは、目的を狭めた妥協ではなく、目的を正確に定義した結果である。
また、単純な方法は、未来の自分に対して親切である。障害時の自分は、平時の自分ほど冷静ではない。数年後の自分は、現在の細かい DB 設定や検討経緯を忘れている。複雑なレプリケーション、PITR、ログ退避、クラウド API、権限設定に依存した復旧手順は、維持されていなければ使えない。一方、YYYYMMDD-N.html という名前で保存された HTML ファイルは、見れば意味が分かる。ブラウザーで開ける。エディターで編集できる。WordPress に貼り直せる。これは、運用負荷を下げるだけでなく、復旧時の認知負荷を下げる。
したがって、この章で明示すべき結論は、HTML 手元保存が「簡単だから採用する」方式ではないということである。これは、価値ある意味内容をベンダー、製品、DBMS、プラグイン、クラウド、管理画面の仕様から切り離し、人間が理解できる可搬形式で保持する設計である。高度な技術を使わないことが目的なのではない。高度な技術を検討したうえで、今回の目的に対しては、より根源的で、依存関係が少なく、維持可能な層で解くことが合理的だという判断である。
10. 採用しなかった方法の理由
binary log / PITR を採用しなかった理由は、技術的に劣るからではない。むしろ DB 復元としては正攻法である。しかし、今回の目的は DB 全体の任意時点復元ではなく、日次バックアップ以後の本文保全である。目的に対して方式が過剰であれば、方式の高度さは価値ではなく負荷になる。
HTML 保存は完全ではない。ただし、今回の価値の中心が本文であるなら、必要十分である。これは「面倒だから諦めた」のではなく、「守る対象を分解した結果、DB 全体ではなく本文を守ればよいと判断した」ということである。高度な仕組みを知ったうえで採用しないことは、手抜きではなくスコープ制御である。
ただし、ここで誤解してはいけないのは、シンプルな方法が常に正解だという話ではないことである。DBMS やクラウドサービスが提供するバックアップ、PITR、レプリケーション、スナップショット、Time Travel、フェールオーバー機構には明確な価値がある。注文、決済、会計、顧客情報、契約、監査証跡のように、データ全体の整合性、更新順序、復旧時点、可用性、証跡が重要な領域では、システム側の機構に任せるべき場面が多い。人間が HTML や CSV を手元保存するだけでは、業務 DB の整合性やトランザクション履歴は守れない。
したがって、比較すべきなのは「複雑な仕組み」と「単純な仕組み」の優劣ではない。比較すべきなのは、保全対象、許容損失、復旧時間、整合性要件、監査要件、運用体制に対して、その方式が過不足なく合っているかである。システムに任せる方式は、正しく設計され、監視され、復旧訓練されていれば強い。一方で、設定しただけで放置すれば、復旧できると思い込むだけの危険な安心材料にもなる。シンプルな方法は、対象が明確で人間が手作業で戻せる場合には強いが、広範囲の整合性や高可用性を要求する用途には向かない。
| 方式 | 採用しなかった理由 | それでも有効な場面 | 今回の判断 |
|---|---|---|---|
| binary log / PITR | DB 全体の任意時点復旧を扱うため、本文保全だけには運用が重い。 | 注文、決済、会計、顧客 DB のように日次単位の損失を許容できない場合。 | 正攻法として理解するが、今回の本文保全には過剰である。 |
| レプリケーション | 現在状態の複製であり、誤削除や本文破壊も複製される。 | 本番ホスト障害、可用性向上、読み取り負荷分散、災害対策。 | 本番障害対策としては有効だが、日次以後の本文差分保全とは目的が違う。 |
| 短周期 dump | DB 全体を頻繁に保存するため、復旧時に本文以外の更新まで巻き戻す可能性がある。 | 小規模 DB で、1 時間単位や 10 分単位の世代復旧で十分な場合。 | 日次 dump の補強にはなるが、本文だけを守るには範囲が広すぎる。 |
| VM snapshot | OS やアプリケーション全体の状態を保存するため、本文保全には粒度が大きすぎる。 | 短時間で環境全体を戻したい場合や、構成変更前の退避。 | 環境復旧には有効だが、本文差分の復旧単位としては粗い。 |
| WordPress export | アプリケーション層の export であり、取得タイミング以後の変更は守れない。 | サイト移行、投稿データのアプリケーション単位退避、定期的な可搬化。 | 補助的には有効だが、日次以後の本文即時保全には HTML 保存の方が直接的である。 |
| HTML 手元保存 | DB 全体、投稿メタ、コメント、画像本体、設定変更は守れない。 | 原稿、文書、記事本文、手作業で復旧可能な意味内容を守る場合。 | 今回の目的に対して最も直接的で、維持コストが低い。 |
製品ごとのソリューションにも、それぞれの思想がある。MySQL や MariaDB では、dump、binary log、replication、物理バックアップを組み合わせて、管理者が復旧設計を組み立てる色彩が強い。PostgreSQL では、base backup と WAL archive による PITR、streaming replication、logical replication を使い分ける。Oracle Database では、RMAN、ARCHIVELOG mode、Data Guard、Flashback などにより、バックアップ、ロールフォワード、スタンバイ、過去状態復元が体系化されている。SQL Server では、full backup、differential backup、transaction log backup、Always On Availability Groups によって、復旧と高可用性を設計する。Snowflake では、Time Travel、Fail-safe、zero-copy clone、replication / failover group のように、低レベルログを利用者が直接扱うのではなく、マネージドな過去状態管理と複製機構として提供される。
| 製品・基盤 | 主なソリューション | 向いている使い所 | 今回の本文保全との距離 |
|---|---|---|---|
| MySQL / MariaDB | mysqldump、mariadb-dump、binary log、replication、物理バックアップ。 | WordPress の基準バックアップ、DB 全体の復旧、PITR、replica 構成。 | DB 層の保護としては有効だが、本文単体の可搬保全には粒度が大きい。 |
| PostgreSQL | pg_dump、base backup、WAL archive、streaming replication、logical replication。 | アプリケーション DB の PITR、高可用性、移行、部分複製。 | DB 整合性には強いが、原稿本文だけを守る用途では過剰になりやすい。 |
| Oracle Database | RMAN、archived redo log、Flashback、Data Guard。 | 大規模業務 DB、監査要件、災害対策、厳密な復旧手順が必要な環境。 | 企業システムには強力だが、個人ブログ本文の退避には重すぎる。 |
| SQL Server | full backup、differential backup、transaction log backup、Always On Availability Groups。 | 業務アプリケーションの復旧、可用性、トランザクション単位の保全。 | 業務 DB には適するが、本文 HTML という意味内容の直接保全とは層が違う。 |
| Snowflake | Time Travel、Fail-safe、zero-copy clone、replication / failover group。 | 分析基盤の過去状態参照、誤削除復旧、検証用 clone、アカウント間複製。 | マネージドな復旧機構として強いが、CMS 原稿の手元正本とは目的が異なる。 |
| SaaS / クラウド文書 | 履歴管理、export、API backup、管理者監査ログ、保持ポリシー。 | 組織的な文書管理、監査、削除復元、移行。 | サービス内部の保護には有効だが、重要内容は可搬形式でも残す方が安全である。 |
この比較から分かるのは、製品機能を使うこと自体は正しいが、製品機能に問題定義を支配させてはいけないということである。MySQL を見れば binary log を使いたくなる。PostgreSQL を見れば WAL archive を考えたくなる。Oracle を見れば RMAN や Data Guard が視野に入る。Snowflake を見れば Time Travel や clone が自然に見える。しかし、製品ごとの機能一覧から出発すると、問題が「その製品でできること」に引っ張られる。今回の本質は、WordPress の DB を細かく戻すことではなく、日次バックアップ以後に書いた本文を失わないことである。
もちろん、システムや仕組みに任せるメリットは大きい。人間の手作業は忘れる。保存し忘れる。命名を間違える。古い版を残し忘れる。手元ディスクだけでは故障に弱い。これに対して、DBMS やクラウドの機能は、適切に設定すれば自動化、継続性、監視、世代管理、アクセス制御、監査ログ、復旧点の明確化を提供できる。特に複数人運用、業務システム、法的証跡、金融・会計・契約のような領域では、人間の任意運用ではなく、システム化された保全が必要になる。
| 観点 | システム化された保全の強み | シンプルな手元保全の強み |
|---|---|---|
| 継続性 | 自動実行により、人間の保存忘れを減らせる。 | 対象を限定すれば、少ない手順で確実に実行しやすい。 |
| 整合性 | DB 全体やトランザクション単位の整合性を守りやすい。 | 本文や文書の意味内容を直接守れる。 |
| 復旧粒度 | 時刻、position、LSN、SCN、snapshot、retention period で復旧点を扱える。 | 記事単位、文書単位、ファイル単位で直感的に戻せる。 |
| 監査性 | ログ、権限、操作履歴、保持ポリシーを組み込める。 | ファイル履歴や Git 管理により本文差分を確認しやすい。 |
| 運用負荷 | 初期設計と継続管理は重いが、一度安定すれば自動化できる。 | 初期設計は軽いが、人間が保存する運用規律に依存する。 |
| 障害時の扱いやすさ | 手順が整っていれば広範囲を一貫して戻せる。 | 対象が狭いため、何を戻すべきか迷いにくい。 |
したがって、採用しなかった方法を「間違った方法」として扱うべきではない。binary log / PITR、レプリケーション、短周期 dump、snapshot、Time Travel は、それぞれ明確な目的を持つ。問題は、今回の WordPress 原稿保全では、それらを主たる方法にすると保全対象より仕組みの方が大きくなることである。本文 HTML 保存は、DB 全体の復旧能力を犠牲にする代わりに、失いたくない意味内容を直接守る。これはトレードオフであり、万能解ではない。
今回採用しなかった方法にも、将来的な使い所はある。WordPress のコメント、フォーム投稿、会員情報、EC、予約システム、決済、顧客情報を扱うようになれば、HTML 保存だけでは不十分になる。その場合は、日次 dump、短周期 dump、binary log / PITR、replication、remote backup、snapshot を組み合わせる価値が上がる。逆に、個人ブログの本文保全という現在のスコープでは、そこまでの仕組みを常時維持するより、日次バックアップを基準層として残し、日次以後の本文を HTML として保存する方が合理的である。
この章の結論は、採用しなかった方法を否定することではない。高度な仕組みには高度な仕組みの使い所があり、シンプルな方法にはシンプルな方法の使い所がある。重要なのは、目的、対象、規模、失敗時の影響、運用能力、将来の保守負荷を見たうえで、必要十分な層を選ぶことである。今回は、DB 全体を細かく復旧する問題ではなく、日次以後の本文変更を失わない問題である。したがって、システム側の正攻法を理解したうえで、本文 HTML の手元保存を採用する。
11. 採用したシンプルな WordPress 原稿保全ルール
採用するルールは単純である。日次 mysqldump は従来どおり維持する。そのうえで、日次バックアップ以後に WordPress 上で本文を作成または編集した場合は、次回の日次バックアップが正常取得されるまで、変更後の HTML 全体を手元に保存する。ファイル名は、投稿日または対象記事の日付に連番を付ける。形式は YYYYMMDD-N.html とする。
このルールの目的は、WordPress 全体を任意時点に復旧することではない。目的は、日次バックアップ以後に作成または編集した本文 HTML を失わないことである。したがって、保存対象は DB 全体ではなく、投稿本文または固定ページ本文の HTML である。投稿 ID、投稿状態、カテゴリー、タグ、予約日時、コメント、投稿メタ、画像ファイル本体、プラグイン設定は、このルールの直接の保存対象ではない。
| 項目 | 採用するルール | 理由 |
|---|---|---|
| 基準バックアップ | 日次 mysqldump は従来どおり維持する。 | WordPress 全体を直近の日次時点へ戻す基準点として必要である。 |
| 追加保全の発動条件 | 日次バックアップ以後に WordPress 上で本文を作成または編集した場合に実施する。 | 日次バックアップ後の本文変更は、次回 backup まで未保全状態になるためである。 |
| 保存対象 | 変更後の本文 HTML 全体を保存する。 | 本文、段落、見出し、表、参考文献リンク、MathJax、アンカー構造をまとめて保持するためである。 |
| 保存期間 | 次回の日次バックアップが正常取得されるまで保持する。 | 日次 backup に含まれた後は、最低限の未保全期間が解消されるためである。 |
| ファイル名 | YYYYMMDD-N.html とする。 | 投稿日または対象記事日付と連番だけで識別でき、運用が単純であるためである。 |
| メタデータ | HTML 内にメタデータコメントは書かない。 | 保存時の負荷を増やさず、運用を継続しやすくするためである。 |
保存対象となる操作は、新規投稿、予約投稿、下書き更新、過去記事編集、固定ページ編集である。いずれも、日次バックアップ以後に人間が本文を作成または変更したという点では同じである。公開済みか、未公開か、予約済みか、下書きかは本質ではない。重要なのは、その本文変更が次回の日次 dump にまだ含まれていないことである。
| 操作 | 保存対象 | 保存するタイミング |
|---|---|---|
| 新規投稿 | 投稿本文 HTML。 | WordPress 上に本文を作成し、日次 backup 前に失いたくない状態になった時点。 |
| 予約投稿 | 投稿本文 HTML。 | 予約投稿として保存した後、次回の日次 backup が取得される前。 |
| 下書き更新 | 更新後の本文 HTML。 | 下書き本文を大きく更新し、再生成が困難な状態になった時点。 |
| 過去記事編集 | 編集後の本文 HTML。 | 公開済み記事を編集し、日次 backup 前に差分を失いたくない時点。 |
| 固定ページ編集 | 編集後の本文 HTML。 | 固定ページ本文を更新し、日次 backup 前に失いたくない状態になった時点。 |
ファイル名は、投稿日または対象記事の日付に連番を付ける。明日投稿する原稿であれば、公開予定日を基準にする。たとえば 2026-05-05 に公開予定の 1 本目の原稿であれば 20260505-1.html とする。同じ日に 2 本目があるなら 20260505-2.html とする。過去記事を編集した場合は、編集対象記事の日付を基準にする。たとえば 2026-04-23 の記事を編集した場合は 20260423-1.html とする。
| 状況 | 保存ファイル名 | 判断理由 |
|---|---|---|
| 2026-05-05 に公開予定の原稿の第 1 版を保存する。 | 20260505-1.html | 公開予定日を基準にすると、人間の記憶と対応しやすい。 |
| 2026-05-05 に公開予定の原稿の第 2 版の原稿を保存する。 | 20260505-2.html | 同一日付内では連番で区別すればよい。 |
| 2026-04-23 の過去記事を編集した本文を保存する。 | 20260423-1.html | 編集対象記事の日付を基準にすると、後から対象を推測しやすい。 |
| 同じ 2026-04-23 の記事について、再度編集した版を追加で保存する。 | 20260423-2.html | 同じ対象日付内で複数版がある場合は連番で区別する。 |
HTML 内にメタデータコメントは書かない。タイトル、投稿状態、予約日時、カテゴリー、タグ、編集対象 URL、変更理由などを毎回 HTML 冒頭に書く案もある。しかし、それは保存時の負荷を増やす。負荷が増えると、運用されなくなる。運用されないルールは、どれほど整っていても保全策ではない。今回のルールでは、メタデータは人間側の記憶と日付ベースのファイル名で扱い、HTML ファイルには本文そのものだけを保存する。
この運用では、手元 HTML は恒久的な正本ではなく、日次バックアップまでの暫定的な復旧用正本である。日次バックアップが正常に取得され、その本文変更が mysqldump に含まれた後は、最低限の目的は達成される。ただし、長文記事や大きな編集差分については、後から参照したい場合に備えて、手元 HTML をそのまま残してもよい。重要なのは、削除するか残すかではなく、日次 backup 前の未保全期間を必ず HTML で埋めることである。
| 判断点 | ルール | 補足 |
|---|---|---|
| 日次 backup 前 | 本文 HTML を必ず手元保存する。 | この期間は WordPress DB だけに依存しない。 |
| 日次 backup 成功後 | 最低限の未保全状態は解消されたと判断する。 | mysqldump に本文変更が含まれたためである。 |
| HTML ファイルの削除 | 削除してもよいが、必要なら残してよい。 | 長文記事や大幅編集は、差分確認用に残す価値がある。 |
| 復旧時 | 日次 backup を戻した後、失われた本文を HTML から貼り直す。 | DB 全体を任意時点に戻すのではなく、本文だけを復元する。 |
最終ルールは一文で書ける。日次バックアップ以後に WordPress 上で本文を作成または編集した場合は、次回の日次バックアップが正常取得されるまで、変更後の HTML 全体を YYYYMMDD-N.html の形式で手元に保存する。この一文が運用の中心である。これ以上複雑にしない。本文を保存する。日付と連番で命名する。メタデータコメントは書かない。日次 backup までの空白を埋める。この程度まで単純化して初めて、平時にも障害時にも実行可能なルールになる。
12. このルールで守れるもの、守らないもの
このルールで守れるものは、日次バックアップ以後の本文である。新規投稿、予約投稿、下書き、公開済み記事の編集、固定ページの編集は守れる。HTML 構造として保存されるため、見出し、段落、表、参照リンク、MathJax、参考文献リストも保持できる。特に、長文記事の論理展開、段落構成、表、数式、参考文献番号、アンカー構造は、障害後に記憶だけで再生成することが難しい。これらを HTML として保存することには明確な価値がある。
一方で、このルールで守らないものも明示する必要がある。投稿 ID、カテゴリー、タグ、スラッグ、予約日時、コメント、カスタムフィールド、画像ファイル本体、プラグイン固有メタデータは主対象ではない。これらは日次 DB バックアップや uploads の別バックアップで守る対象であり、本文 HTML 保存に背負わせるべきではない。本文 HTML 保存にすべてを背負わせると、ルールが肥大化し、結局運用されなくなる。
| 対象 | このルールで守れるか | 理由 | 必要な補完策 |
|---|---|---|---|
| 新規投稿本文 | 守れる。 | 本文 HTML 全体を保存するため、日次 backup 前に投稿が消えても貼り直せる。 | 公開日時、カテゴリー、タグは必要に応じて手作業で再設定する。 |
| 予約投稿本文 | 守れる。 | 公開前で外部に存在しない本文を手元 HTML として保持できる。 | 予約日時や投稿状態は WordPress 側で再設定する。 |
| 下書き本文 | 守れる。 | 未完成でも、再生成困難な文章断片や構成を保存できる。 | 下書き状態そのものは WordPress で再作成する。 |
| 公開済み記事の編集本文 | 守れる。 | 記事自体は残っていても、日次以後の編集差分を HTML として復元できる。 | 編集対象を間違えないよう、日付ベースの命名で管理する。 |
| 固定ページ本文 | 守れる。 | 固定ページの本文 HTML を保存すれば、更新前へ巻き戻っても貼り直せる。 | 固定ページの slug や表示位置は別途確認する。 |
| カテゴリー、タグ、スラッグ | 主対象ではない。 | 本文 HTML には分類情報や URL 制御情報を含めないためである。 | 日次 DB backup、手作業再設定、必要に応じた管理画面確認で補う。 |
| 予約日時 | 主対象ではない。 | HTML 本文とは別の投稿状態情報であるためである。 | 人間側の予定管理または WordPress 管理画面で再設定する。 |
| 画像ファイル本体 | 守らない。 | HTML に画像参照は残っても、画像ファイル本体は保存されない。 | uploads backup、元画像の手元保存、別途ファイル backup で守る。 |
| コメント、投稿メタ、プラグイン固有データ | 守らない。 | 本文保全ルールの範囲外であり、DB 内部状態に属するためである。 | mysqldump、プラグイン export、DB backup、必要に応じた個別保全で扱う。 |
このルールの強みは、保全対象を本文に絞ることである。しかし、その強みは同時に限界でもある。本文 HTML が残っていれば記事の中核は復旧できるが、WordPress 上の投稿状態を完全に再現できるわけではない。復旧時には、日次バックアップを戻した後、失われた本文を HTML から貼り直し、必要に応じてカテゴリー、タグ、スラッグ、予約日時を再設定することになる。つまり、このルールは自動復旧の仕組みではなく、人間が理解可能な形で本文を復旧可能にする仕組みである。
さらに、この方法を採ることによるリスクもある。第一に、保存忘れのリスクである。システムによる自動バックアップではなく、人間が HTML を保存する運用であるため、保存しなければ守れない。第二に、版の取り違えのリスクである。同じ日付で複数の原稿や複数回の編集がある場合、どのファイルが最新かを間違える可能性がある。第三に、メタデータ欠落のリスクである。HTML 内にメタデータコメントを書かないため、タイトル、カテゴリー、タグ、予約日時、編集対象 URL は本文ファイルだけからは完全には分からない。第四に、手元保存先そのものの障害である。ローカルディスクが壊れれば、手元 HTML も失われる。
| リスク | 発生する理由 | 影響 | 抑制策 |
|---|---|---|---|
| 保存忘れ | 人間が保存する運用であり、自動化されていないためである。 | 日次 backup 前の本文変更が WordPress 内部に閉じたままになる。 | 投稿・編集完了時の作業手順に HTML 保存を組み込む。 |
| 版の取り違え | 同じ日付で複数ファイルや複数編集版が発生するためである。 | 古い本文を復旧してしまう可能性がある。 | YYYYMMDD-N.html の連番を単純に保ち、不要な枝分かれ命名を避ける。 |
| メタデータ欠落 | HTML 内にタイトル、カテゴリー、タグ、予約日時を書かないためである。 | 復旧時に分類や公開設定を再設定する手間が残る。 | このルールは本文保全専用と割り切り、メタデータは WordPress 側または人間の管理で補う。 |
| 画像ファイルの未保存 | HTML は画像参照を含めても、画像本体を含まないためである。 | 画像付き記事では本文だけ復旧しても表示が完全にならない。 | 画像元ファイルと uploads backup を別途維持する。 |
| 手元ディスク障害 | HTML ファイルをローカル物理マシンだけに置く場合、そのディスクが単一障害点になるためである。 | WordPress と手元 HTML の両方を失う可能性がある。 | 必要に応じて Git、外部ディスク、別ホスト、クラウドストレージへ二重化する。 |
| 機密情報の散在 | 本文 HTML を DB 外へコピーするため、保存場所が増える。 | 未公開原稿や内部情報が手元ファイルとして漏えいする可能性がある。 | 保存ディレクトリーの権限、端末暗号化、不要ファイル削除方針を確認する。 |
| 復旧手順の過信 | HTML があるだけで完全復旧できると誤解するためである。 | DB 状態、画像、メタデータ、設定まで戻ると錯覚する。 | このルールは本文 HTML の保全に限定されることを明記する。 |
このリスク整理から分かるのは、HTML 手元保存もまた一つのトレードオフだということである。DBMS の PITR やレプリケーションのような高度な仕組みを避けることで、運用負荷と製品依存は下がる。しかし、人間の保存忘れ、版管理、保存先管理という別の負荷が発生する。つまり、複雑性が消えるのではなく、DBMS 層の複雑性を、人間が扱いやすいファイル運用の複雑性へ移している。重要なのは、その複雑性が今回の目的に対して十分小さく、障害時にも理解可能であるという点である。
したがって、このルールを正しく運用するには、守れるものと守らないものを混同しないことが重要である。本文 HTML は守れる。WordPress 全体の完全な内部状態は守れない。画像本体は守れない。カテゴリーやタグや予約日時は主対象ではない。日次 backup までの本文差分を失わないことに特化する。このスコープ制御によって、ルールは単純になり、実行可能になる。
最終的に、このルールの価値は「完全性」ではなく「目的適合性」にある。本文を失いたくないなら本文を保存する。DB 全体を戻したいなら DB backup や PITR を使う。可用性を高めたいなら replica や managed failover を使う。画像を守りたいなら uploads と元画像を保存する。保全対象ごとに手段を分けることで、HTML 保存の限界は弱点ではなく、明確に設計された境界になる。
13. 背景にある考え方：完全なシステム復元と価値ある情報の保全は違う
この判断の背景には、完全なシステム復元と価値ある情報の保全は違うという考え方がある。WordPress 全体を完全に戻すことを目標にすれば、DB、ファイル、設定、プラグイン、テーマ、アップロードファイル、証明書、Web サーバー設定まで保全対象になる。これは重要な観点である。しかし、日次バックアップ以後に失いたくないものが本文であるなら、システム全体を細かく戻すことだけが正解ではない。
価値ある情報を、それが偶然保存されているシステムから切り離す。これが今回の判断の本質である。本文を HTML として保存すれば、WordPress DB に閉じ込められていた意味内容が、可搬なテキストファイルとして外部化される。DB が壊れても、WordPress が変わっても、最悪の場合には人間が読める。
ただし、この考え方は「システム復元を軽視してよい」という意味ではない。システム復元にはシステム復元の役割がある。DB 全体の整合性、ユーザー情報、コメント、設定、メディアファイル、プラグイン固有データ、アクセス制御、公開状態、URL 構造まで含めて戻したい場合、本文 HTML だけでは足りない。その場合は、DB backup、uploads backup、設定ファイル、サーバー構成、PITR、snapshot、replication、Infrastructure as Code を組み合わせる必要がある。したがって、判断の出発点は「どちらが優れているか」ではなく、「どの損失を防ぎたいのか」である。
リスクには種類がある。本番ホストが壊れるリスク、DB が壊れるリスク、誤削除するリスク、アプリケーションバグで本文が破壊されるリスク、日次 backup 以後の作業が消えるリスク、復旧時に古い版へ戻してしまうリスク、手元保存した HTML を失うリスク、未公開原稿が漏えいするリスクは、それぞれ影響範囲が異なる。影響範囲が異なる以上、同じ対策で全部を解決しようとするべきではない。
| リスク | 主な影響範囲 | 有効な対策 | HTML 手元保存で対応できるか |
|---|---|---|---|
| 本番ホスト喪失 | DB、ファイル、設定、Web サーバー、実行環境。 | リモート backup、別ホスト退避、snapshot、構成管理、復旧手順。 | 本文は守れるが、システム全体は戻せない。 |
| DB 破損 | 投稿、コメント、設定、投稿メタ、ユーザーデータ。 | mysqldump、物理 backup、PITR、復旧検証。 | 本文差分だけは補えるが、DB 全体の整合性は守れない。 |
| 日次 backup 以後の本文消失 | 新規投稿、予約投稿、下書き、公開済み記事の編集差分。 | 本文 HTML 保存、短周期 export、短周期 dump。 | 主目的として対応できる。 |
| 誤削除・誤更新 | 削除または変更された投稿、設定、メタデータ。 | PITR、世代 backup、リビジョン、遅延 replica、監査ログ。 | 保存済み本文は戻せるが、削除状態やメタデータまでは戻せない。 |
| 画像・添付ファイル消失 | uploads、画像本体、PDF、添付資料。 | uploads backup、元ファイル保存、オブジェクトストレージ退避。 | 画像参照は残るが、画像本体は守れない。 |
| 手元 HTML の喪失 | 日次 backup 前の本文復旧用正本。 | Git、外部ディスク、別ホスト、端末バックアップ。 | HTML 保存自体の補完策が必要である。 |
| 未公開原稿の漏えい | 公開前本文、内部メモ、下書き、構想段階の内容。 | 端末暗号化、保存ディレクトリー権限、不要ファイル削除、同期先制御。 | HTML 保存によりコピーが増えるため、別途リスク管理が必要である。 |
この表から分かるのは、HTML 手元保存は万能な保全策ではなく、特定のリスクに対して強い局所的な対策だということである。特に強いのは、日次 backup 以後に人間が作成または編集した本文の喪失である。一方で、本番環境全体の喪失、DB 全体の整合性、画像ファイル、投稿メタデータ、セキュリティ侵害、誤削除の全体復旧には、それぞれ別の対策が必要になる。この切り分けを明示することで、HTML 保存の限界は欠点ではなく、設計上の境界になる。
一般的な判断としては、まず保全対象を「システム状態」と「意味内容」に分けるべきである。システム状態とは、DB、設定、権限、投稿 ID、メタデータ、アプリケーション内部状態、実行環境などである。意味内容とは、本文、判断、合意、証跡、画像本体、設計理由、取引事実、文書本文などである。システム状態を戻したいなら、backup、snapshot、PITR、replication、構成管理が必要になる。意味内容を守りたいなら、HTML、Markdown、CSV、PDF、plain text、画像ファイル、証憑ファイルなど、可搬形式での保全が効く。
| 判断軸 | システム復元を優先すべき場合 | 意味内容の可搬保全を優先すべき場合 |
|---|---|---|
| 復旧対象 | DB、アプリケーション、設定、ユーザー、権限、関連ファイルをまとめて戻したい。 | 本文、文書、合意、証跡、写真、設計判断などを失いたくない。 |
| 整合性要件 | 複数テーブル、複数ファイル、外部連携を整合した状態で戻す必要がある。 | 単体の意味内容を人間が確認して戻せればよい。 |
| RTO | 短時間でサービス再開が必要である。 | 復旧は手作業でもよく、即時自動復旧までは不要である。 |
| RPO | DB 全体について細かい損失許容を定義する必要がある。 | 特定の本文や文書だけは失いたくない。 |
| 運用体制 | 監視、復旧訓練、権限管理、手順更新を継続できる。 | 少ない手順で個人または小規模運用として維持したい。 |
| 製品依存 | 製品固有の backup / recovery 機能を使う価値が高い。 | 製品変更や移行に備えて、標準的な形式で残したい。 |
判断境界を明示すると、次のようになる。DB 全体の整合性、複数ユーザーの更新、会計・注文・顧客・契約のような業務データ、法的証跡、短い RTO、厳しい RPO が必要な場合は、本文 HTML のような手元保全だけでは不十分であり、DBMS やクラウドの復旧機構を使うべきである。逆に、失いたくないものが人間の作成した本文や文書であり、手作業で復元でき、メタデータは再設定可能で、システム全体の即時復旧までは不要であれば、可搬形式での手元保存は合理的である。
| 条件 | 推奨される方向 | 理由 |
|---|---|---|
| DB 全体の整合性が必要である。 | DB backup、PITR、snapshot、復旧検証を優先する。 | 本文ファイルだけでは複数テーブルや内部状態を再現できないためである。 |
| 業務上、日次単位のデータ損失が許されない。 | binary log、WAL、redo log、transaction log backup、Time Travel などを検討する。 | 細かい時点へ戻す必要があるためである。 |
| 本番停止時間を短くしたい。 | replication、managed failover、standby、Multi-AZ を検討する。 | バックアップからの手作業復旧では RTO が長くなるためである。 |
| 失いたくないものが本文・文書・判断内容である。 | HTML、Markdown、CSV、PDF、plain text などの可搬形式で保存する。 | 意味内容をシステム内部状態から切り離して守れるためである。 |
| 復旧は手作業でよく、対象も限定されている。 | シンプルなファイル保存を優先する。 | 運用負荷と復旧時の認知負荷を下げられるためである。 |
| 未公開情報や機密情報を外部ファイル化する。 | 保存先の権限、暗号化、同期範囲、削除方針を確認する。 | 可搬性を高めると、漏えい面も増えるためである。 |
この判断境界は、WordPress に限らず一般化できる。GitHub issue、Slack、Teams、Google Docs、会計ソフト、写真管理アプリ、業務 DB、分析基盤でも同じである。システム全体を戻す必要があるのか。それとも、その中に含まれる意味内容だけを守ればよいのか。現在状態の継続が重要なのか。過去状態への復元が重要なのか。機密性を下げずに可搬性を高められるのか。この問いを立てずに技術方式だけを選ぶと、過剰な仕組みを抱えるか、逆に守るべきものを守れない。
したがって、今回の判断は、完全復元を捨てた判断ではない。完全復元は日次 mysqldump、リモート退避、uploads backup、サーバー構成管理の問題として別に扱う。そのうえで、日次 backup 以後の本文変更という狭く、価値が高く、再生成困難で、手作業復旧可能な対象については、HTML 手元保存を採用する。これにより、システム全体の backup と、意味内容の保全を分けて扱える。
この章の結論は、データ保全の判断は「より完全な方法」ではなく「より目的に合う方法」を選ぶべきだということである。完全なシステム復元が必要な場面では、完全なシステム復元を設計する。価値ある意味内容を守ればよい場面では、意味内容を可搬形式で守る。リスクと影響範囲を分解し、判断境界を明示すれば、シンプルな方法を採ることも、高度なシステム機構を採ることも、どちらも場当たり的ではなくなる。
14. データ保全とは何か
データ保全とは、単にデータをコピーすることではない。失われると再生成できない価値ある情報を特定し、それを将来の自分または組織が実際に復元できる形で、適切な世代、文脈、手順とともに保存することである。
この定義に入る前に、まずデータとは何かを分解する必要がある。データとは、単なるビット列ではない。もちろん、計算機上ではデータはファイル、DB レコード、オブジェクト、ログ、メタデータ、バイナリ、テキストとして保存される。しかし、人間や組織にとって価値を持つのは、ビット列そのものではなく、そのビット列が表している内容、判断、履歴、証跡、構造、再利用可能性である。WordPress の本文 HTML で言えば、保存されているのは文字列である。しかし価値を持つのは、文字列の背後にある論理展開、段落構造、表、参考文献、推論、公開可能な記事としてのまとまりである。
したがって、データには少なくとも 3 つの層がある。第一に、物理層または記録層としてのデータである。これはディスク上のファイル、DB ページ、オブジェクトストレージ、ログファイル、バックアップファイルなどである。第二に、構造層としてのデータである。これはテーブル、カラム、JSON、HTML、Markdown、CSV、画像メタデータ、ファイル名、ディレクトリー構造など、データを解釈するための形式である。第三に、意味層としてのデータである。これは本文、判断、合意、証憑、取引事実、設計理由、作業成果、記憶すべき文脈である。データ保全で本当に守りたいのは、多くの場合、この意味層である。
| データの層 | 具体例 | 役割 | 保全上の注意点 |
|---|---|---|---|
| 記録層 | ファイル、DB ページ、バックアップファイル、binary log、WAL、オブジェクトストレージ上の実体。 | データを物理的または論理的に保存する。 | 存在していても、読める形式や復旧手順がなければ価値を取り出せない。 |
| 構造層 | HTML、Markdown、CSV、SQL schema、JSON、テーブル定義、ファイル名、ディレクトリー構造。 | 記録された内容を解釈可能にする。 | 構造が失われると、データは残っていても意味を復元しにくくなる。 |
| 意味層 | 記事本文、設計判断、合意、証憑、取引事実、公開予定原稿、編集差分。 | 人間や組織にとって実際の価値を持つ。 | システム内部状態から切り離し、可搬形式で守る価値が高い。 |
次に、保全とは何かを考える必要がある。保全とは、現在あるものをただ保存することではない。保全とは、将来の喪失、破壊、誤操作、環境変化、製品変更、記憶の劣化に対して、価値ある情報を取り戻せる状態にしておくことである。つまり、保全は現在の作業ではなく、未来の復旧可能性を設計する行為である。バックアップファイルが存在するだけでは保全とは言えない。復旧できること、意味を解釈できること、どれを戻すべきか判断できること、必要な手順が残っていることまで含めて、初めて保全になる。
ここで、保存、同期、複製、バックアップ、保全を区別する必要がある。保存は、あるデータをどこかに置くことである。同期は、複数の場所の現在状態を揃えることである。複製は、同じまたは近い状態を別の場所に持つことである。バックアップは、ある時点の状態を後から戻せるように残すことである。保全は、これらを含み得るが、それだけではない。保全は、価値ある情報を将来復元できるように、形式、世代、隔離、手順、文脈、判断基準を整えることである。
| 概念 | 意味 | 弱点 | 保全との関係 |
|---|---|---|---|
| 保存 | データをどこかに置く。 | 上書き、破損、所在不明、形式不明に弱い。 | 保全の一要素だが、保存だけでは不十分である。 |
| 同期 | 複数環境の現在状態を揃える。 | 誤削除、破損、暗号化、改ざんも同期される。 | 可用性や利便性には有効だが、過去状態の保全とは別である。 |
| 複製 | 別の場所に同じ状態を持つ。 | 論理破壊や誤操作も複製され得る。 | 単一障害点対策には有効だが、世代と隔離がなければ保全として弱い。 |
| バックアップ | ある時点の状態を戻せるように残す。 | 復旧手順、検証、保持期間、対象範囲が不明だと使えない。 | 保全の中核的手段である。 |
| 保全 | 価値ある情報を将来復元可能な形で守る。 | 対象、形式、世代、手順、文脈を誤ると成立しない。 | 保存、同期、複製、バックアップを目的に応じて組み合わせる上位概念である。 |
データ保全で重要なのは、「データがあるか」ではなく、「必要なときに、必要な意味を、必要な粒度で取り戻せるか」である。たとえば、DB dump が存在しても、復元手順が分からなければ保全としては弱い。binary log が残っていても、どの位置まで適用すべきか判断できなければ危険である。Slack のメッセージが残っていても、どれが正式な合意か分からなければ業務判断には使いにくい[26][27]。写真ファイルが残っていても、撮影日時や整理文脈が失われれば、記録としての価値は下がる。保全とは、単に「残す」ことではなく、「後から意味を取り出せるように残す」ことである。
この観点では、データ保全には時間軸が含まれる。現在のデータを守るだけなら同期で足りる場合がある。しかし、誤削除や誤更新から戻すには過去状態が必要になる。障害直前へ戻すにはログが必要になる。数年後に読み返すには可搬形式が必要になる。監査や説明責任に耐えるには、誰が、いつ、なぜ、何を変更したかという文脈が必要になる。つまり、保全とは現在状態の固定ではなく、未来の復旧、検証、再利用、説明に備えて、時間的な厚みを持たせることである。
| 時間軸 | 必要になる保全 | 典型的な手段 | 目的 |
|---|---|---|---|
| 直近状態 | 現在のデータを別の場所にも持つ。 | 同期、レプリケーション、クラウド保存。 | 端末故障、本番ホスト障害、作業継続への備え。 |
| 過去状態 | 誤操作や破壊前の状態へ戻せる。 | 世代バックアップ、スナップショット、Time Travel、リビジョン。 | 論理破壊、誤削除、巻き戻しへの備え。 |
| 変更履歴 | どの変更が行われたかを追える。 | binary log、WAL、redo log、transaction log、Git。 | PITR、監査、差分確認への備え。 |
| 長期保存 | 将来も読める形式で残す。 | HTML、Markdown、PDF/A、CSV、plain text、標準的画像形式。 | 製品変更、環境喪失、将来の再利用への備え。 |
| 文脈保存 | なぜそのデータが重要か、どう戻すかを残す。 | README、運用ルール、復旧手順、チェックリスト、設計判断ログ。 | 未来の自分や組織が迷わず復旧するための備え。 |
NIST SP 800-34 Rev. 1 は、情報システムの contingency planning について、情報システムと業務を評価し、優先順位と要件を決め、復旧戦略を設計するための指針を提供している[28]。NIST Cybersecurity Framework 2.0 でも、RECOVER はサイバーセキュリティインシデントで影響を受けた資産と運用を復旧する機能として位置づけられている[29]。この観点では、保全は保存済みデータの存在ではなく、復旧可能な運用設計である。
15. システム状態と意味内容を分ける
この考え方をさらに一般化すると、データ保全は「価値」「形式」「場所」「時間」「手順」「権限」の設計である。価値とは、何を失うと困るかである。形式とは、それをどのような形で残せば将来読めるかである。場所とは、どこに置けば単一障害点を避けられるかである。時間とは、どの世代をどれくらい残すかである。手順とは、失ったときにどう戻すかである。権限とは、誰が読めて、誰が消せて、誰が復元できるかである。この 6 つが揃わない保全は、どこかで破綻しやすい。
| 設計要素 | 問うべきこと | 失敗例 |
|---|---|---|
| 価値 | 失われると再生成できないものは何か。 | DB 全体を守っているつもりで、重要な本文差分や判断文脈を守れていない。 |
| 形式 | 将来の環境でも読めるか。 | 特定アプリケーションがないと開けない形式だけに依存する。 |
| 場所 | 本番障害、端末故障、アカウント喪失に巻き込まれないか。 | 本番サーバー上に backup を置き、本番喪失時に backup も失う。 |
| 時間 | 現在状態だけでなく、過去状態へ戻れるか。 | 同期だけに頼り、誤削除後の状態で全環境が揃ってしまう。 |
| 手順 | 障害時にどう戻すかが分かるか。 | backup ファイルはあるが、復旧手順がなく、戻せるか検証されていない。 |
| 権限 | 必要な人が復元でき、不要な人が読めないか。 | 機密データを広く同期し、漏えい面を増やす。 |
保全においてもう一つ重要なのは、正本を決めることである。複数の場所にデータがある場合、どれを信じるのかを決めなければならない。WordPress の公開後本文は WordPress 側が正本かもしれない。しかし、日次バックアップ以後の未保全期間では、手元 HTML が復旧用正本になる。GitHub issue の議論は判断過程として重要だが、最終決定は設計文書に反映した時点で設計文書が正本になる場合がある。Slack の会話は合意の発生場所かもしれないが、永続的な正本としては議事録や運用ルールに落とすべき場合がある。正本を決めることは、復旧時に迷わないための判断基準を決めることである。
また、保全は完全性と実行可能性の均衡でもある。すべてを完全に保存し、常時同期し、複数拠点に複製し、暗号化し、世代管理し、復旧訓練まで行えば理想に近づく。しかし、そこには金銭、時間、認知負荷、設定管理、セキュリティ管理、手順更新、監視のコストが発生する。保全策が重すぎると、維持されない。維持されない保全策は、存在しないのと同じである。したがって、保全設計では、失われる価値と、守るためのコストを釣り合わせる必要がある。
| 保全設計の失敗 | 何が起きているか | 本質的な問題 |
|---|---|---|
| 保存しただけで安心する。 | ファイルはあるが、戻せるか分からない。 | 復元可能性を検証していない。 |
| 同期をバックアップだと思う。 | 誤削除や破損が全環境へ広がる。 | 現在状態の複製と過去状態の保全を混同している。 |
| システム状態と意味内容を混同する。 | DB は戻ったが、重要な本文差分や合意内容が消える。 | 守りたい価値を技術単位に分解できていない。 |
| 高度な仕組みを入れて放置する。 | PITR や replication はあるが、復旧手順も訓練もない。 | 仕組みの存在と運用可能性を混同している。 |
| 単純化しすぎる。 | 本文は残るが、必要なメタデータや画像が失われる。 | スコープを狭めた結果、必要な対象まで外している。 |
今回の WordPress 原稿保全に戻すと、データ保全の対象は WordPress DB 全体ではなく、日次バックアップ以後に生成された本文という意味内容である。記録層としては DB 内の投稿データであり、構造層としては HTML であり、意味層としては論考、構成、参考文献、表、数式、編集判断である。これを DB 内部状態に閉じ込めると、日次バックアップ前の障害に弱い。HTML として手元保存すれば、記録層を DB からファイルへ移し、構造層を HTML として保ち、意味層を人間が読める形で守れる。
したがって、この章の結論は、データ保全とは「データを多く持つこと」ではないということである。データ保全とは、価値ある情報を見極め、それを失われにくく、読める形式で、必要な世代と文脈を伴って、実際に復元できる状態にしておくことである。コピーの数ではなく、復元可能性が本質である。同期の速さではなく、過去へ戻れることが重要である。仕組みの高度さではなく、失いたくない価値に対して適切な粒度で守れていることが重要である。
16. 可搬形式で保存することの重要性
可搬形式で保存することは、データ保全の基本である。可搬形式とは、特定のアプリケーションや特定の SaaS の内部状態に強く依存せず、人間または標準的なツールで読み取れる形式である。HTML、Markdown、plain text、CSV、TSV、SQL dump、Git repository、PDF、画像の標準形式などが該当する。
可搬形式の重要性は、単に「別の環境でも開ける」という利便性にとどまらない。可搬形式は、データを特定システムの内部状態から切り離し、将来の復旧経路を増やす。WordPress の本文が DB の投稿テーブルにしか存在しない場合、復旧には WordPress、DB、文字コード、テーブル構造、管理画面または SQL 操作が必要になる。しかし、本文を HTML として保存しておけば、テキストエディターでも読める。ブラウザーでも確認できる。別の WordPress に貼れる。静的サイトにも転用できる。AI に渡して要約や検査もできる。これは単なる保存形式の違いではなく、復旧可能性の違いである。
NIST SP 800-209 は、ストレージインフラが複雑化すると設定ミスやセキュリティ脅威が増えることを前提に、ストレージ全体の保護、隔離、復旧保証、暗号化などを含む指針を整理している[30]。可搬形式の価値は、特定のストレージやアプリケーションに依存しすぎない点にある。ストレージやアプリケーションは、データを扱うための環境である。しかし、環境は変わる。サービスは終了する。プラグインは廃止される。DB バージョンは変わる。クラウドの仕様も変わる。可搬形式は、この環境変化に対して、意味内容をできるだけ独立させる。
| 保存対象 | システム内部に閉じた状態 | 可搬形式 | 可搬形式にする効果 |
|---|---|---|---|
| ブログ本文 | WordPress DB、ブロックエディター内部表現、投稿メタ。 | HTML、Markdown、plain text。 | CMS がなくても読め、別環境へ移しやすく、差分も確認しやすい。 |
| 表データ | 特定 SaaS の表、BI ツール、アプリケーション DB。 | CSV、TSV、SQLite、XLSX。 | 別ツールで読み込みやすく、集計や検査がしやすい。 |
| 設計判断 | GitHub issue、Slack、Teams の会話。 | Markdown、設計書、決定事項ログ。 | 会話ログから判断結果を分離し、後から参照しやすくなる。 |
| 写真 | 写真管理アプリ、クラウドアルバム、スマートフォン内ライブラリー。 | JPEG、PNG、RAW、XMP、EXIF 付き元ファイル。 | アプリ変更やアカウント障害に左右されにくくなる。 |
| 会計・取引 | 会計ソフト DB、クラウド会計サービス。 | CSV、PDF 帳票、証憑ファイル。 | 監査、確定申告、サービス移行、長期保管に耐えやすくなる。 |
| ソースコード | IDE 内部状態、ローカル作業ディレクトリーのみ。 | Git repository。 | 履歴、差分、分岐、復元点を明確に保持できる。 |
| メール | メールサービスの UI、独自形式のローカル DB。 | mbox、Maildir、eml。 | 別クライアントや検索ツールで扱いやすくなる。 |
可搬形式の強みは、長期保存、移行、検査、差分確認、部分復旧にある。DB dump は DB 全体の復旧には有効だが、本文差分を人間が確認するには扱いにくい。SaaS の履歴機能は便利だが、サービス側の保持期間や権限や仕様に依存する。クラウド同期は現在状態を複数端末へ届けるには有効だが、誤削除や破損が同期される危険がある。これに対して、HTML、Markdown、CSV、plain text のような形式は、将来の環境が変わっても読める可能性が高い。データ保全では、この「将来も読める」という性質が極めて重要である。
ただし、可搬形式にも限界はある。可搬形式にすれば、元システムの全状態が保存されるわけではない。HTML は本文構造を保存できるが、WordPress の投稿 ID、投稿状態、カテゴリー、タグ、予約日時、コメント、カスタムフィールド、画像本体までは保存しない。CSV は表データを保存できるが、アプリケーション側の入力制約、承認状態、権限、画面表示、ワークフローは保存しない。PDF は見た目の固定には強いが、構造化データとして再利用しにくい場合がある。可搬形式は「意味内容の保全」に強いが、「システム全体の完全復元」には別の仕組みが必要である。
| 可搬形式 | 強み | 弱み | 向いている用途 |
|---|---|---|---|
| plain text | 最も読める環境が広く、長期保存に強い。 | 構造や装飾を表現しにくい。 | メモ、設定、ルール、復旧手順、短い記録。 |
| Markdown | 人間が読みやすく、構造もある程度表現できる。 | 方言があり、複雑な表現には向かない場合がある。 | 文書、設計メモ、運用ルール、AI コンテキスト。 |
| HTML | 見出し、表、リンク、アンカー、MathJax などを保持しやすい。 | CMS 固有メタデータや画像本体は含まない。 | ブログ本文、Web 公開原稿、構造化された長文。 |
| CSV / TSV | 多くのツールで読み書きでき、表データの移行に強い。 | 型、制約、リレーション、書式、権限は保持しにくい。 | 取引一覧、ログ集計、表形式の export。 |
| SQL dump | DB の論理状態を SQL として再現しやすい。 | DBMS、バージョン、文字コード、スキーマ依存が残る。 | DB の基準バックアップ、移行、検証環境復元。 |
| PDF / PDF/A | 見た目の固定、配布、長期参照に強い。 | 再編集や構造化データとしての再利用は弱い。 | 契約書、帳票、提出文書、最終版の保管。 |
| Git repository | 履歴、差分、分岐、復元点を体系的に扱える。 | 巨大バイナリや DB 状態そのものには向かない。 | ソースコード、設定、Markdown、HTML、運用ルール。 |
したがって、可搬形式で保存するとは、すべてを一つの形式に変換することではない。対象に応じて、意味内容を最も失いにくい形式へ落とすことである。文章なら HTML や Markdown がよい。表なら CSV や TSV がよい。最終版文書なら PDF/A がよい。ソースコードや設定なら Git がよい。DB 全体なら SQL dump や物理バックアップがよい。写真なら JPEG、RAW、EXIF、XMP を考えるべきである。重要なのは、製品の内部形式をそのまま信じるのではなく、将来の復元、移行、検査、再利用に耐える形式を選ぶことである。
今回の WordPress 原稿では、本文を HTML として保存する判断がこの原則に合っている。ブログ本文は最終的に HTML として公開される。見出し、段落、表、参考文献リンク、アンカー、MathJax の構造をそのまま保持できる。DB の細かい内部状態までは守らないが、記事としての意味内容は守れる。可搬形式の目的は、完全なシステム復元ではなく、価値ある情報を特定システムから切り離して、将来も読める形にすることである。
17. 正本を決めることの重要性
データが複数箇所にあるとき、どれが正本かを決めなければならない。正本とは、復旧時に信じる基準である。バックアップが多いことは安全に見えるが、どれが正しいか分からなければ混乱する。復旧時には「どの状態へ戻すか」を短時間で決める必要がある。
正本を決めることは、単なる整理ではない。復旧時の判断基準を決めることである。同じ記事本文が WordPress、日次 dump、手元 HTML、ローカル編集ファイル、AI との会話ログ、ブラウザーの下書き画面に存在する場合、障害時にどれを信じるのかが曖昧だと復旧できない。新しいものが常に正しいとは限らない。壊れた更新が最新である場合もある。古い backup が安全で、最新の同期先が壊れている場合もある。したがって、正本は「どこにあるか」だけでなく、「どの条件で正本とみなすか」まで決める必要がある。
これは AI コンテキスト管理にも通じる。AI にすべてを記憶させるのではなく、人間側の Markdown を正本とし、AI には必要な要約を渡す。以前の記事でも、恒久ルール、準恒久方針、更新型コンテキスト、時点記録を分け、compiled は生成物として扱う設計を整理した[31]。AI の記憶は便利だが、利用者が直接 grep できず、diff を取りにくく、別の AI へ移植しにくい。したがって、恒久ルールや重要な文脈は、人間が管理する Markdown を正本にしたほうがよい。AI の記憶は補助キャッシュであり、正本ではない。
| 対象 | 正本になり得るもの | 補助的なコピー | 判断理由 |
|---|---|---|---|
| 公開済みブログ記事 | WordPress 上の公開本文。 | 日次 dump、HTML 保存、Web キャッシュ。 | 公開状態として読者が見る本文が正本になるためである。 |
| 日次 backup 後の未公開原稿 | 手元の YYYYMMDD-N.html。 | WordPress の future / draft 状態、AI 会話ログ。 | 次回 backup 前の復旧用本文として、手元 HTML を信じるためである。 |
| 過去記事の編集中差分 | 編集後に保存した HTML。 | WordPress 旧本文、日次 dump、編集メモ。 | 公開済み記事は存在していても、最新編集差分は手元 HTML にしかない場合があるためである。 |
| AI 利用ルール | 人間が管理する Markdown ファイル。 | AI の記憶、会話ログ、要約ファイル。 | 他環境へ移植でき、差分管理でき、人間が直接検査できるためである。 |
| 業務上の決定事項 | 設計書、議事録、決定事項ログ。 | Slack / Teams、GitHub issue、口頭メモ。 | 会話は判断過程であり、確定事項は永続文書へ反映すべきであるためである。 |
| 会計記録 | 会計ソフト上の確定データ、帳票、証憑。 | CSV export、作業メモ、銀行明細コピー。 | 監査や申告で信じる対象を明確にする必要があるためである。 |
正本を決めないと、バックアップが多いほど復旧は難しくなる。複数の dump、複数の HTML、複数の同期先、複数の SaaS export がある場合、復旧時には「どれが最新か」「どれが壊れていないか」「どれが正式か」を判断しなければならない。これは平時なら調査できるが、障害時には判断負荷になる。特に、論理破壊や誤更新が起きた場合、最新のコピーが正しいとは限らない。正本の定義がなければ、壊れた最新状態を正式な状態として復元してしまう危険がある。
| 正本が曖昧な場合の失敗 | 何が起きるか | 防ぐための考え方 |
|---|---|---|
| 古い版を復旧する。 | 本文や設定は存在するが、重要な差分が消えた状態で復旧してしまう。 | 日次 backup 後の変更については、手元 HTML を復旧用正本とする。 |
| 壊れた最新状態を信じる。 | 誤削除や破壊的更新後の状態を最新として採用してしまう。 | 最新性と正しさを分け、世代 backup や差分確認を使う。 |
| 会話ログを正式合意と誤認する。 | 途中の議論や未確定案を正式決定として扱ってしまう。 | 確定事項は設計書や議事録へ反映し、それを正本にする。 |
| AI の記憶を正本にする。 | 内容を直接検査できず、移植性や再現性が弱くなる。 | 人間側の Markdown を正本にし、AI には必要に応じて読み込ませる。 |
| 複数の保存先で矛盾する。 | ローカル、クラウド、DB、export の内容が一致せず、復旧判断に時間がかかる。 | 用途ごとに正本と補助コピーを明示する。 |
正本は、時間によって移る場合がある。たとえば、WordPress の日次バックアップ後に新しい記事を書いた直後は、手元 HTML が復旧用正本である。次回の日次 mysqldump が正常に取得され、その本文が backup に含まれれば、日次 backup も基準復旧点になる。記事が公開された後は、読者に見えている WordPress 上の本文が公開正本になる。さらに、後から大幅編集した場合は、編集後 HTML が一時的な復旧用正本になる。このように、正本は固定された場所ではなく、状態と時間によって役割が変わる。
| 状態 | この時点の正本 | 補助的な保全 | 理由 |
|---|---|---|---|
| 日次 backup 前に新規原稿を書いた直後。 | 手元 HTML。 | WordPress の future / draft 状態。 | 日次 dump にはまだ含まれておらず、WordPress 障害で消える可能性があるためである。 |
| 日次 backup が正常取得された後。 | WordPress DB と日次 dump。 | 手元 HTML。 | 本文変更が基準 backup に含まれ、最低限の未保全期間が解消されるためである。 |
| 記事公開後。 | WordPress 上の公開本文。 | 日次 dump、手元 HTML、Web キャッシュ。 | 読者に提供される公開状態が正本になるためである。 |
| 公開済み記事を日次 backup 後に編集した直後。 | 編集後の手元 HTML。 | WordPress 上の編集済み本文。 | 次回 backup 前に巻き戻ると、編集差分が失われるためである。 |
| 障害復旧時。 | 目的に応じて選ぶ。 | 日次 dump、HTML、uploads backup、設定 backup。 | システム全体を戻すのか、本文差分を戻すのかで信じる対象が異なるためである。 |
この考え方は、データ保全における「コピーを増やせばよい」という直感を修正する。コピーが増えるほど安全になる場合もあるが、同時に判断対象も増える。正本を決めずにコピーだけを増やすと、復旧時に矛盾が増える。どれが最新か。どれが正しいか。どれが破損前か。どれが公開済みか。どれが編集途中か。これを障害時に毎回考えるのは危険である。
したがって、データ保全では、保存場所を増やすことと同時に、正本規則を作る必要がある。正本規則とは、「通常時は何を信じるか」「日次 backup 前は何を信じるか」「障害時はどれを基準に戻すか」「AI や SaaS の記憶は正本か補助か」「一時ファイルはいつまで復旧用正本か」を明文化することである。この規則があれば、復旧時に迷いが減る。
今回の WordPress 原稿保全では、正本規則は単純である。日次 backup 前の新規投稿、予約投稿、下書き更新、過去記事編集、固定ページ編集については、手元に保存した YYYYMMDD-N.html を本文の復旧用正本とする。日次 backup が正常取得されれば、基準復旧点としての mysqldump が成立する。公開後の通常状態では、WordPress 上の公開本文を正本とする。このように正本を時間と状態で切り替えることで、複数の保存先があっても復旧判断が明確になる。
18. 同期、レプリケーション、バックアップの違い
同期、レプリケーション、バックアップ、アーカイブ、エクスポートは似ているが、目的が違う。ここを混同すると、バックアップを取っているつもりで、実際には現在状態を複製しているだけになる。データ保全で危険なのは、「どこかに同じものがある」ことを「戻せる」と誤解することである。同じものが別の場所にあっても、それが壊れた後の現在状態であれば、過去へは戻れない。
同期とは、複数環境の現在状態を揃えることである。Dropbox、Google Drive、iCloud、Syncthing、rsync などは、端末間で同じファイルを扱うには便利である。しかし、同期は基本的に「現在状態を伝播する」仕組みである。誤って削除したファイル、壊れたファイル、ランサムウェアによって暗号化されたファイルも、同期対象であれば他の環境へ広がる。世代管理や削除復元がなければ、同期は保全ではなく、破壊の伝播路にもなる。
レプリケーションとは、本番に近い状態を別環境へ継続的に複製することである。DB レプリケーション、ストレージレプリケーション、クラウドの Multi-AZ 構成、スタンバイ構成などが該当する。レプリケーションは、ホスト障害、ストレージ障害、読み取り負荷分散、本番継続性に強い。しかし、レプリケーションも現在状態の複製である。誤削除、誤更新、アプリケーションバグ、侵害による改ざんも複製される。したがって、レプリケーションは可用性の技術であって、過去状態へ戻るためのバックアップとは別である。
バックアップとは、ある時点の状態へ戻せるように保存することである。バックアップの本質は、現在状態からの時間的な隔離にある。最新状態をただ別の場所へ置くだけではなく、昨日、一週間前、一か月前、障害前、誤操作前へ戻れることが重要である。そのためには、世代管理、保持期間、削除保護、アクセス制御、復元手順、復元検証が必要になる。バックアップファイルが存在していても、復元できることを確認していなければ、保全策としては未完成である。
アーカイブとは、長期保存を目的として情報を残すことである。バックアップが障害復旧を主目的とするのに対し、アーカイブは証跡、法務、監査、履歴、研究、将来参照を主目的とする。即時復旧よりも、改ざんされないこと、長期間読めること、検索できること、文脈が残っていることが重要になる。たとえば、会計帳票、契約書、提出済み文書、過去の決定事項、公開済み記事の確定版などは、バックアップだけでなくアーカイブとして扱う価値がある。
エクスポートとは、特定システムの内部にある情報を、外部で扱える形式に取り出すことである。WordPress の HTML、Google Docs の PDF / Markdown、会計ソフトの CSV、SaaS の JSON export、メールの mbox などが該当する。エクスポートは、システム全体の完全復旧には弱い場合がある。しかし、ベンダーロックインを下げ、意味内容を可搬化し、別環境で読める状態にする点で強い。今回の WordPress 本文 HTML 保存は、このエクスポート的な保全に近い。
ランサムウェア対策では、この違いが特に重要である。CISA の #StopRansomware Guide は、重要データのオフラインかつ暗号化されたバックアップを維持し、災害復旧シナリオで可用性と完全性を定期的にテストすることを推奨している[32]。CISA の Stop Ransomware ページでも、データのオフライン暗号化バックアップと定期テストが示されている[33]。これは、同期やレプリケーションだけでは、暗号化された現在状態が広がる危険があるためである。ランサムウェア対策では、攻撃者やマルウェアから到達しにくい隔離された世代バックアップが必要になる。
| 方式 | 主目的 | 強い場面 | 弱い場面 |
|---|---|---|---|
| 同期 | 複数環境の現在状態を揃える。 | 端末間で最新ファイルを共有する。 | 誤削除や破損も同期される。 |
| レプリケーション | 本番に近い状態を別環境へ複製する。 | ホスト障害や読み取り負荷分散に対応する。 | 論理破壊や誤操作も複製される。 |
| バックアップ | 過去状態へ戻す。 | 誤操作、破壊、障害から復旧する。 | 復元手順と検証がなければ使えない。 |
| アーカイブ | 長期保存する。 | 証跡、法務、履歴保存に向く。 | 即時復旧には向かない。 |
| エクスポート | 特定システムから情報を取り出す。 | 可搬性とベンダー依存低減に向く。 | 完全なアプリケーション状態は再現しにくい。 |
これらの違いは、事故の種類ごとに見るとさらに明確になる。端末故障なら同期やレプリケーションが効く場合がある。本番ホスト喪失ならレプリケーションやリモートバックアップが効く。誤削除なら世代バックアップやリビジョンが必要になる。ランサムウェアなら、同期先や replica も汚染される可能性があるため、隔離されたバックアップが必要になる。ベンダー終了やサービス移行なら、エクスポートや可搬形式が重要になる。長期監査なら、アーカイブとしての保持が必要になる。
| 事故・目的 | 同期 | レプリケーション | バックアップ | アーカイブ | エクスポート |
|---|---|---|---|---|---|
| 端末故障 | 有効。 | 対象によって有効。 | 有効。 | 補助的。 | 補助的。 |
| 本番ホスト喪失 | 限定的。 | 有効。 | 有効。 | 限定的。 | 対象によって有効。 |
| 誤削除・誤更新 | 弱い。 | 弱い。 | 有効。 | 有効な場合がある。 | 保存時点によって有効。 |
| ランサムウェア | 危険になり得る。 | 危険になり得る。 | 隔離されていれば有効。 | 改ざん耐性があれば有効。 | 隔離保存されていれば有効。 |
| ベンダー終了・移行 | 弱い。 | 弱い。 | 形式による。 | 有効。 | 有効。 |
| 監査・証跡 | 弱い。 | 弱い。 | 保持設計による。 | 有効。 | 形式によって有効。 |
ここで重要なのは、これらを対立関係として扱わないことである。同期、レプリケーション、バックアップ、アーカイブ、エクスポートは、それぞれ守るリスクが違う。したがって、実務では組み合わせる。たとえば、日常作業の利便性には同期を使い、本番可用性にはレプリケーションを使い、誤操作やランサムウェア対策には隔離された世代バックアップを使い、長期証跡にはアーカイブを使い、ベンダー依存を下げるためにエクスポートを使う。どれか 1 つで全部を解決しようとすると、必ず盲点が残る。
| 組み合わせ | 役割分担 | 注意点 |
|---|---|---|
| 同期 + 世代バックアップ | 日常利用は同期で便利にし、誤削除や破損は世代バックアップで戻す。 | 同期先とバックアップ先を同じ権限・同じ削除経路にしない。 |
| レプリケーション + PITR | ホスト障害には replica、誤操作には PITR で対応する。 | replica はバックアップではないため、ログと世代を別に守る。 |
| DB backup + エクスポート | システム全体は DB backup、意味内容は HTML / CSV / Markdown で守る。 | 正本がどちらかを状況ごとに決める。 |
| バックアップ + アーカイブ | 障害復旧用と長期証跡用を分ける。 | 復旧頻度、保持期間、改ざん耐性、検索性の要件が異なる。 |
| マネージド機能 + 手元可搬形式 | クラウドの Time Travel や履歴機能を使いつつ、重要内容は可搬形式でも持つ。 | 保持期間、権限、サービス終了、export 仕様を確認する。 |
今回の WordPress 原稿保全に戻すと、日次 mysqldump はバックアップであり、手元 HTML 保存はエクスポートに近い意味内容の保全である。deferred-sync やリモート取得は、バックアップファイルの配置や退避経路を増やす。もし DB レプリケーションを導入すれば、本番ホスト障害には強くなるが、誤削除や本文破壊は replica にも伝播する。したがって、本文消失のリスクに対しては、レプリケーションではなく HTML 保存が直接効く。
この章の結論は、同期、レプリケーション、バックアップ、アーカイブ、エクスポートを目的別に使い分けるべきだということである。同期は便利さ、レプリケーションは可用性、バックアップは過去復元、アーカイブは長期証跡、エクスポートは可搬性を主に担う。これらを混同しないことが、データ保全の基本である。
19. 業務におけるバックアップ・リカバリー戦略
業務では、バックアップを取ること自体が目的ではない。業務を戻すことが目的である。バックアップはデータを退避する行為であり、リカバリーはデータを戻す行為であり、業務復旧はシステムと業務プロセスを再開できる状態にする行為である。この三つを混同すると、バックアップファイルは存在するが業務は再開できない、という典型的な失敗が起きる。
業務におけるバックアップ・リカバリー戦略は、技術方式から始めてはいけない。最初に決めるべきなのは、止まると困る業務、失うと困るデータ、許容できる停止時間、許容できるデータ損失、復旧時に最低限必要な業務水準である。DB の dump、PITR、レプリケーション、スナップショット、クラウドバックアップは手段であり、業務継続の目的から逆算して選ぶべきである。
AWS Backup の PITR は、連続バックアップとトランザクションログを使って特定時点まで戻す方式として説明されている[34]。Google Cloud Backup and DR Service は、災害復旧、業務継続、開発・テスト活動などにバックアップデータを活用する考え方を示している[35]。Cloud SQL for MySQL の PITR でも、特定時刻まで復元するために mysqlbinlog utility を使うと説明されている[36]。Cloud SQL for PostgreSQL でも、PITR によって指定時点へ復元できる[37]。Microsoft Azure Backup でも、バックアップはデータ保護と復元のためのサービスとして整理されている[38]。Azure Backup には soft delete や immutable vault といった、バックアップ削除や悪意ある破壊から保護するための仕組みも用意されている[39][40]。
これらのサービスに共通するのは、バックアップを「ファイルを置くこと」ではなく、「復旧可能性をサービスとして管理すること」として扱っている点である。ただし、クラウドサービスを使えば自動的に業務復旧が完成するわけではない。保護対象、保持期間、復旧先、権限、リージョン、暗号化、復旧手順、復旧テスト、監視、費用を設計しなければならない。マネージドサービスは運用負荷を下げるが、判断責任を消すわけではない。
| 段階 | 問い | 成果物 | 失敗すると起きること |
|---|---|---|---|
| 業務分析 | 止まると困る業務は何か。 | 重要業務一覧、優先順位、業務影響分析。 | 重要でないものを過剰に守り、重要なものを守れない。 |
| データ分類 | 失うと困るデータは何か。 | データ分類表、正本一覧、保全対象一覧。 | 一時データや再生成可能データまで重く扱い、設計が肥大化する。 |
| 復旧目標定義 | どこまで、どれくらいの時間で戻す必要があるか。 | RPO、RTO、RLO。 | 復旧時に「どの状態なら再開してよいか」を判断できない。 |
| 方式選定 | どの方式を組み合わせるか。 | バックアップ方式、PITR、レプリケーション、DR 構成。 | 方式だけが先行し、目的に対して過剰または不足になる。 |
| 運用設計 | 誰が、いつ、どう確認するか。 | 監視、アラート、復旧手順、権限、運用責任。 | バックアップは動いているつもりでも、失敗に気づけない。 |
| 復旧検証 | 実際に戻せるか。 | 復旧テスト記録、所要時間、問題点、改善記録。 | 障害時に初めて手順不備や権限不足に気づく。 |
実務では、「バックアップ済み」と「復旧可能」は別物として扱うべきである。バックアップジョブが成功していても、復元先環境がない、権限がない、暗号鍵がない、手順が古い、アプリケーションが起動しない、データ整合性が取れていない、業務担当者が確認できない、という理由で復旧できないことがある。したがって、バックアップ戦略は必ずリカバリー戦略と一体で設計する。
20. 業務データの分類
業務システムでは、保全対象を分類しなければならない。すべてのデータを同じ重みで扱うと、保全設計は過剰になり、復旧時の判断も遅くなる。逆に、すべてを同じように雑に扱うと、本当に失ってはいけないデータを守れない。分類とは、単なる棚卸しではない。復旧優先順位、保全粒度、保持期間、権限、監査要件、コストを決めるための実務判断である。
業務データを分類するときは、技術的な保存場所ではなく、業務上の意味で見る必要がある。同じ DB に入っていても、注文データ、顧客マスター、画面設定、監査ログ、キャッシュでは価値が違う。同じ S3 bucket に入っていても、契約書 PDF、サムネイル画像、一時 export、監査証跡では扱いが違う。データ分類をせずにバックアップ設計を行うと、対象ごとのリスク差を見落とす。
| 分類 | 例 | 失った場合の影響 | 基本方針 | 実務上の確認点 |
|---|---|---|---|---|
| トランザクションデータ | 注文、決済、契約、入出金、申込。 | 直接的な金銭損失、法務リスク、顧客影響が出る。 | RPO を短くし、PITR や整合性あるバックアップを検討する。 | 二重計上、欠落、重複、外部決済との突合、復旧後の整合確認を定義する。 |
| マスターデータ | 顧客、商品、料金、権限、組織、設定。 | 業務全体が誤った前提で動く。 | 変更履歴、承認、世代バックアップを重視する。 | 誰が変更できるか、変更承認があるか、誤変更を検出できるかを確認する。 |
| コンテンツ | 文書、画像、添付ファイル、記事本文。 | 人間が作った意味内容が失われる。 | 可搬形式、世代管理、原本ファイル保全を重視する。 | 本文・画像本体・メタデータ・公開状態を分けて保全する。 |
| システム設定 | 環境変数、IAM、証明書、DNS、ジョブ設定。 | データがあってもサービスを起動できなくなる。 | IaC、設定リポジトリ、秘密情報管理を組み合わせる。 | 秘密情報を Git に混入させず、復旧時に鍵・証明書・権限を再取得できるか確認する。 |
| 監査ログ | 操作ログ、アクセスログ、証跡。 | 事後調査、法務、監査、インシデント分析が困難になる。 | 改ざん耐性、保持期間、検索性を重視する。 | 通常ユーザーや侵害された管理者が削除できない保管経路を検討する。 |
| 一時データ | キャッシュ、セッション、再生成可能な中間成果物。 | 一時的な性能低下や再計算が発生する。 | 原則として除外し、必要なものだけ対象化する。 | 本当に再生成可能か、再生成に必要な元データが保全されているか確認する。 |
分類の次に必要なのは、正本と復旧単位の定義である。トランザクションデータの正本は DB かもしれない。契約書の正本は署名済み PDF かもしれない。設定の正本は IaC repository かもしれない。監査ログの正本は改ざん耐性のあるログ基盤かもしれない。復旧時に何を信じるかを決めておかなければ、バックアップが複数存在しても判断できない。
| 分類 | 正本の候補 | 復旧単位 | 復旧後に確認すべきこと |
|---|---|---|---|
| トランザクションデータ | 業務 DB、決済基盤、会計システム。 | DB、テーブル群、トランザクション時点。 | 件数、金額、外部システムとの突合、重複・欠落の有無。 |
| マスターデータ | 管理 DB、承認済み master export、設定リポジトリ。 | マスター単位、差分単位、承認済み版。 | 業務ルール、料金、権限、参照整合性。 |
| コンテンツ | CMS、HTML / Markdown、原本ファイル。 | 記事、文書、画像、添付ファイル単位。 | 本文、画像、リンク、公開状態、検索導線。 |
| システム設定 | IaC、設定 repository、secret manager。 | 環境単位、サービス単位、設定ファイル単位。 | 起動可否、接続可否、権限、証明書期限。 |
| 監査ログ | ログ基盤、WORM storage、SIEM。 | 期間単位、システム単位、イベント種別単位。 | 欠落期間、検索性、時刻同期、改ざん痕跡。 |
この分類は一度作って終わりではない。新しい機能、外部連携、SaaS、決済手段、ログ基盤、AI 利用、ファイル保存先が増えれば、保全対象も変わる。実務では、システム変更時に「バックアップ対象と復旧手順も変わったか」を確認する必要がある。データ分類表は設計書ではなく、運用中に更新されるべき管理台帳である。
21. RPO / RTO / RLO を定義する
業務のバックアップ・リカバリー戦略では、RPO と RTO を定義する必要がある。RPO は Recovery Point Objective、つまり許容できるデータ損失の時間幅である。RTO は Recovery Time Objective、つまり許容できる停止時間である。AWS Well-Architected Framework は、RTO と RPO をビジネスニーズに基づいて設定し、データの場所やワークロード機能を考慮して DR 戦略を設計するよう説明している[41]。
さらに実務では、RLO を考えるとよい。RLO はここでの実務上の整理として Recovery Level Objective、つまりどの水準まで戻れば業務再開とみなすかである。完全復旧だけをゴールにすると、途中段階の復旧判断ができない。参照だけできればよいのか、注文受付だけ再開できればよいのか、管理画面は後回しでよいのかを分ける必要がある。
AWS Well-Architected Framework では、backup and restore、pilot light、warm standby、multi-site active/active などの DR 戦略が RTO と RPO の要件に応じて選択される[42]。これは重要である。RPO / RTO が厳しくなるほど、必要な構成は重くなる。backup and restore は安価だが RTO は長くなりやすい。warm standby や multi-site active/active は RTO / RPO を短くしやすいが、平時のコスト、設計難度、運用負荷が大きくなる。
| 指標 | 意味 | 実務上の問い | 設計に与える影響 |
|---|---|---|---|
| RPO | どの時点まで戻せればよいか。 | 何分、何時間、何日前までの損失を許容するか。 | バックアップ頻度、PITR、レプリケーション、世代設計が決まる。 |
| RTO | どれくらいの時間で戻す必要があるか。 | 何分、何時間、何日以内に再開すべきか。 | DR 構成、復旧自動化、事前準備の水準が決まる。 |
| RLO | どの水準まで戻れば業務再開とみなすか。 | 参照だけでよいか、主要機能だけでよいか、完全復旧が必要か。 | 段階復旧、縮退運転、手作業代替の設計が決まる。 |
RPO / RTO / RLO はシステム全体で一律に決めるべきではない。ログイン機能、注文機能、決済機能、管理画面、集計レポート、検索機能、通知機能では要求が違う。すべてを最短 RTO に合わせると高コストになる。すべてを緩い RTO に合わせると重要業務を守れない。実務では、業務機能ごとに復旧目標を分ける必要がある。
| 業務機能 | RPO の例 | RTO の例 | RLO の例 | 設計方針 |
|---|---|---|---|---|
| 注文受付 | 数分以内。 | 短時間。 | 注文を受け付け、注文番号を発行できる。 | PITR、レプリケーション、縮退受付、外部決済との突合を検討する。 |
| 決済処理 | ほぼ欠損不可。 | 短時間。 | 決済状態を確認し、二重請求を防げる。 | 外部決済基盤との整合、冪等性、監査ログ、手動照合手順を重視する。 |
| 管理画面 | 数時間でも許容される場合がある。 | 中程度。 | 最低限の確認と手動処理ができる。 | 完全復旧より、代替手順と閲覧専用復旧を検討する。 |
| レポート・分析 | 数時間から 1 日。 | 緩めでもよい場合が多い。 | 過去実績を参照できる。 | 再生成可能性、DWH snapshot、元データ保全を重視する。 |
| CMS・文書 | 日次以後の変更は失いたくない。 | 手作業復旧でもよい場合がある。 | 本文を再掲できる。 | DB backup と可搬形式 export を組み合わせる。 |
RLO は特に実務上重要である。障害時に最初から完全復旧を目指すと、復旧が遅れることがある。たとえば、EC なら全機能復旧より注文受付再開が先かもしれない。社内システムなら更新は止めても参照だけ再開すれば業務が続くかもしれない。ブログなら WordPress 管理画面は後回しでも、本文 HTML が残っていれば再投稿できる。復旧水準を段階化すると、障害時の判断が明確になる。
| 復旧水準 | 状態 | 業務判断 | 必要な準備 |
|---|---|---|---|
| Level 0 | 停止中。 | 業務停止、顧客告知、影響範囲確認を行う。 | 連絡網、ステータスページ、初動手順。 |
| Level 1 | 参照のみ可能。 | 顧客対応、確認業務、手動処理の準備ができる。 | 読み取り専用復旧、参照用 backup、権限分離。 |
| Level 2 | 主要業務のみ再開。 | 注文受付、問い合わせ対応、最低限の更新を再開する。 | 縮退運転、優先機能、手動代替、後追い反映手順。 |
| Level 3 | 通常業務に近い状態。 | 大半の業務を再開するが、非重要機能は後回しにする。 | 復旧後検査、遅延ジョブ再実行、外部連携確認。 |
| Level 4 | 完全復旧。 | 通常運用へ戻す。 | 事後レビュー、恒久対策、再発防止。 |
RPO / RTO / RLO は、経営・業務・技術の合意事項である。技術者だけで決めると、業務影響を過小評価する危険がある。業務側だけで決めると、実現コストを過小評価する危険がある。したがって、実務では「この RPO / RTO / RLO を達成するために、いくらかかり、どの複雑性を受け入れるか」を明示して合意する必要がある。
22. 障害種別ごとに戦略を分ける
障害種別ごとに戦略を分けることも重要である。物理障害、論理障害、セキュリティ事故、災害、運用ミス、外部依存障害、データ不整合では、有効な対策が違う。単一の方式で全障害に対応しようとすると、どこかが不足する。たとえば、レプリケーションは物理障害には強いが、誤削除には弱い。バックアップは誤削除には強いが、復旧時間は長くなりやすい。WORM は改ざんには強いが、通常復旧の速度を上げるものではない。
実務では、障害種別ごとに「検知」「封じ込め」「復旧」「検証」「再発防止」を分けて考える必要がある。バックアップ・リカバリー戦略は、障害発生後にデータを戻すだけではない。どの時点で異常を検知するか、壊れた状態を広げないか、どの backup を信じるか、復旧後に正しさをどう確認するかまで含める必要がある。
| 障害種別 | 典型例 | 主な被害 | 有効な対策 | 注意点 |
|---|---|---|---|---|
| 物理障害 | ディスク故障、ホスト喪失、ストレージ障害。 | 本番環境が利用不能になる。 | レプリケーション、スナップショット、オフサイトバックアップ。 | 論理破壊には別対策が必要である。 |
| 論理障害 | 誤削除、誤更新、バグによる破壊。 | データが不正な状態になる。 | 世代バックアップ、PITR、遅延レプリカ。 | 直近レプリカだけでは壊れた状態も複製される。 |
| セキュリティ事故 | 侵害、改ざん、ランサムウェア。 | 本番とバックアップが同時に破壊される可能性がある。 | 隔離バックアップ、WORM、権限分離、復旧前のクリーン確認。 | 攻撃者がバックアップも削除できる構成は弱い。 |
| 災害 | リージョン障害、停電、広域ネットワーク障害。 | データセンターやリージョン単位で利用不能になる。 | 遠隔地バックアップ、DR サイト、代替運用。 | 同一リージョン内だけのバックアップでは不十分である。 |
| 外部依存障害 | SaaS 障害、外部 API 停止、決済基盤障害。 | 自社システムが正常でも業務が止まる。 | 定期エクスポート、代替フロー、縮退運転。 | 自社バックアップだけでは解決しない。 |
| 運用ミス | 誤ったリリース、誤った migration、誤った権限変更。 | データ不整合、機能停止、権限異常が起きる。 | 変更前 backup、rollback plan、承認、dry-run、変更凍結。 | 変更直前の復旧点を明確にする必要がある。 |
| データ不整合 | 外部連携の二重実行、片側だけ成功、非同期処理失敗。 | DB は動いていても業務上の正しさが崩れる。 | 突合、冪等性、補正ジョブ、監査ログ、業務確認。 | バックアップを戻すだけでは解決しない場合がある。 |
特に注意すべきなのは、データ不整合である。DB が壊れていなくても、業務上は壊れている場合がある。決済は成功したが注文 DB への反映に失敗した。メールは送信されたが履歴に残っていない。外部 API には登録されたが自社 DB は rollback された。このような障害では、単純に DB を戻すと、外部システムとの整合がさらに崩れる可能性がある。したがって、外部連携を持つ業務では、バックアップだけでなく突合と補正の手順が必要である。
| 障害種別 | 検知方法 | 復旧方針 | 復旧後検証 |
|---|---|---|---|
| 物理障害 | 死活監視、ストレージエラー、クラウド障害通知。 | standby / replica への切替、backup からの復元。 | アプリケーション起動、接続確認、主要業務の smoke test。 |
| 論理障害 | 件数異常、削除件数異常、業務担当者からの通報。 | PITR、世代 backup、部分復旧、手動補正。 | 対象件数、差分、関連テーブル、業務画面確認。 |
| セキュリティ事故 | EDR、SIEM、異常ログ、改ざん検知、身代金要求。 | 封じ込め、クリーン環境構築、隔離 backup から復元。 | 侵害経路除去、アカウント再発行、バックドア確認、ログ保全。 |
| 災害 | クラウド status、監視断、拠点障害情報。 | DR site、別リージョン、代替業務へ切替。 | 業務機能、DNS、外部連携、顧客通知の確認。 |
| 外部依存障害 | SaaS status、API error rate、timeout 増加。 | 縮退運転、キューイング、手動受付、後追い反映。 | 未処理件数、重複処理、外部側との突合。 |
障害種別ごとに戦略を分けることは、復旧時の混乱を減らす。障害時に最も危険なのは、何が起きているか分からないまま、闇雲に restore することである。物理障害なら切替で済むかもしれない。論理障害なら最新 replica へ切り替えると壊れた状態を採用してしまう。セキュリティ事故なら本番環境をそのまま復元しても攻撃者の侵入口を戻すだけかもしれない。外部依存障害なら自社 DB を戻しても解決しない。障害種別に応じて、復旧の入口を分けるべきである。
23. 技術方式の選択肢
技術方式は、対象と要件に応じて組み合わせる。単一方式ですべてを守る必要はない。DB には DB の保全方式があり、ファイルにはファイルの保全方式があり、設定には設定の保全方式がある。業務では、それぞれの方式の役割と限界を明示しなければならない。方式を選ぶ前に、対象、正本、復旧単位、RPO、RTO、RLO、脅威、運用体制を確認する必要がある。
実務上の方式選定では、「できるか」ではなく「維持できるか」を問うべきである。PITR は強力だが、log 退避と復旧訓練が必要である。レプリケーションは可用性を高めるが、lag 監視と昇格手順が必要である。Object Lock / WORM は改ざん耐性に強いが、保持期間と削除不能期間を誤ると運用制約になる[43]。Git は設定と文書に強いが、秘密情報を入れると逆にリスクになる。どの方式にも、強みと運用コストがある。
| 方式 | 向いている対象 | 強み | 弱み | 実務上の確認点 |
|---|---|---|---|---|
| ファイルコピー | 原稿、設定、添付ファイル。 | 単純で人間が理解しやすい。 | 世代管理と整合性確認が必要である。 | コピー対象、除外対象、保存先、削除規則を決める。 |
| Git | コード、設定、文書、運用ルール。 | 履歴、差分、レビュー、正本管理に強い。 | DB や大容量バイナリには向かない。 | 秘密情報を混入させない。 |
| DB dump | 小〜中規模 DB の基準バックアップ。 | 理解しやすく、移植性がある。 | dump 後の更新を含まない。 | 復元テスト、文字コード、バージョン、ロック方式を確認する。 |
| PITR | 高頻度更新 DB。 | 指定時点へ細かく戻せる。 | 運用と訓練が重い。 | 基準バックアップ、log 退避、停止位置、復元手順を検証する。 |
| レプリケーション | 可用性、ホスト障害対策。 | 直近状態を別環境に持てる。 | 論理破壊も複製される。 | 遅延、停止検知、昇格手順、バックアップとの併用を確認する。 |
| スナップショット | VM、volume、storage、構成変更前の退避。 | 短時間で環境単位の復旧点を作れる。 | アプリケーション整合性や長期保管には注意が必要である。 | crash-consistent か application-consistent か、保持期間、別拠点退避を確認する。 |
| Object Lock / WORM | 改ざん・削除耐性が必要なバックアップ。 | 侵害時にも削除されにくい。 | コストと運用制約がある。 | 保持期間、法務要件、削除不能期間を確認する。 |
| マネージドバックアップ | クラウド DB、VM、ファイル、SaaS。 | 自動化、監視、世代管理、復元 UI を利用できる。 | サービス仕様、保持期間、リージョン、権限に依存する。 | SLA、復旧先、暗号鍵、料金、export 可否を確認する。 |
| エクスポート | 文書、記事、表、SaaS データ。 | 可搬性とベンダー依存低減に強い。 | 完全なアプリケーション状態は再現しにくい。 | 形式、頻度、正本、再インポート可否を確認する。 |
方式選定では、複数方式の役割分担を明記する必要がある。たとえば、DB dump は基準バックアップ、PITR は日中更新の復旧、レプリケーションは可用性、Object Lock はランサムウェア対策、Git は設定と文書、エクスポートは可搬性、スナップショットは構成変更前の退避、というように役割を分ける。役割を決めずに方式を増やすと、復旧時にどれを使うべきか分からなくなる。
| 目的 | 主方式 | 補助方式 | 実務上の境界 |
|---|---|---|---|
| 日次の基準復旧点を作る。 | DB dump、file backup。 | remote copy、世代管理。 | 基準点として扱い、dump 後の更新は別方式で補う。 |
| 高頻度更新を細かく戻す。 | PITR。 | transaction log、binary log、WAL、復旧訓練。 | 停止位置を誤ると壊れた状態まで再現する。 |
| 本番障害時に早く切り替える。 | レプリケーション、standby、managed failover。 | DNS、proxy、connection endpoint、手順書。 | 誤削除対策にはならないため、backup と併用する。 |
| ランサムウェアや侵害に備える。 | 隔離バックアップ、Object Lock / WORM。 | 権限分離、暗号化、MFA、復旧演習。 | 攻撃者が削除できる backup は保護として弱い。 |
| 意味内容を守る。 | HTML、Markdown、CSV、PDF、原本ファイル。 | Git、定期 export、文書ルール。 | アプリケーション全体の完全復旧とは分ける。 |
| 設定を再構築する。 | IaC、設定 repository。 | secret manager、手順書、環境差分表。 | 秘密情報と証明書は repository とは別に管理する。 |
最後に、方式選定の結果は必ず運用へ落とす必要がある。バックアップ方式を決めただけでは足りない。ジョブが失敗したら誰に通知するか。保持期間を過ぎた backup はどう削除されるか。復旧テストはどの頻度で行うか。復旧時に必要な権限は誰が持つか。退職者の権限でしか復旧できない状態になっていないか。暗号鍵はどこにあるか。これらを決めていない方式は、実務上は未完成である。
24. 運用設計で決めるべき事項
バックアップ設計で決めるべきことは、技術方式だけではない。むしろ技術方式は最後に決まる。先に、対象、除外、頻度、保持期間、保存場所、暗号化、鍵管理、アクセス権、削除耐性、監視、復旧手順、検証、訓練、責任者、変更管理を決める必要がある。これらが決まっていないバックアップは、ファイルとしては存在していても、業務復旧の仕組みとしては未完成である。
本番業務では、バックアップは平時の処理ではなく、障害時の業務継続手段である。したがって、設計対象は「バックアップジョブ」ではなく、「復旧できる運用全体」である。どのデータを守るか。どのデータは除外するか。どの頻度で取得するか。どこに置くか。誰が読めるか。誰が削除できるか。暗号鍵はどこにあるか。復旧時に誰が判断するか。復旧後に何を確認するか。これらが欠けると、障害時に初めて判断が発生し、復旧が遅れる。
特に重要なのは、バックアップ対象と復旧対象が同じとは限らないことである。バックアップ対象は DB、ファイル、ログ、設定、証明書、IaC、手順書などの技術単位で整理される。一方、復旧対象は注文受付、顧客対応、記事公開、会計処理、社内承認、監査対応などの業務単位で判断される。運用設計では、この技術単位と業務単位を対応づける必要がある。
| 設計項目 | 決める内容 | 曖昧な場合に起きる問題 | 本番業務での確認観点 |
|---|---|---|---|
| 対象 | 何をバックアップするか。 | 重要データが漏れる。 | DB、ファイル、設定、ログ、証明書、鍵、手順書、外部 export を棚卸しする。 |
| 除外 | 何をバックアップしないか。 | 不要データが増え、復旧時のノイズになる。 | キャッシュ、一時ファイル、再生成可能データ、機密性が高すぎる不要コピーを明示する。 |
| 頻度 | 何分、何時間、何日ごとに取得するか。 | RPO と実態が合わない。 | 業務機能ごとの RPO と一致しているか確認する。 |
| 保持期間 | 何世代、何日、何年残すか。 | 必要な過去時点が消える、または容量が膨らむ。 | 誤操作検知までの遅延、監査要件、法定保存期間、コストを考慮する。 |
| 保存場所 | 同一ホスト、別ホスト、別リージョン、別アカウント、オフラインのどこに置くか。 | 本番障害や侵害で同時に失われる。 | 本番権限だけで全バックアップへ到達できない構成にする。 |
| 暗号化 | 保存時と転送時にどう暗号化するか。 | 漏えい時の被害が増える。 | 保存時暗号化、転送時暗号化、暗号化対象、復号可能性を確認する。 |
| 鍵管理 | 復号鍵を誰がどこで管理するか。 | バックアップがあっても復号できない。 | KMS、secret manager、緊急時アクセス、鍵ローテーション、権限分離を決める。 |
| アクセス権 | 誰が読めるか、誰が復元できるか、誰が削除できるか。 | 漏えい、誤削除、権限不足による復旧不能が起きる。 | 最小権限、break-glass account、退職者権限削除、MFA を確認する。 |
| 削除耐性 | 誤削除や攻撃による削除をどう防ぐか。 | 過去状態へ戻れない。 | WORM、Object Lock、別アカウント保管、削除承認、保持ロックを検討する。 |
| 監視 | 成功、失敗、遅延、容量、世代欠落をどう検知するか。 | 停止していても気づけない。 | 失敗通知だけでなく、一定期間成功していない状態も検知する。 |
| 復旧手順 | 誰がどの順序で戻すか。 | 障害時に作業できない。 | 本番直接復旧、隔離環境復旧、部分復旧、切り戻し条件を分ける。 |
| 検証 | 戻した結果を何で正常とみなすか。 | 壊れた状態を復旧完了と誤認する。 | 件数、金額、ログイン、主要画面、外部連携、業務担当者確認を定義する。 |
| 訓練 | どの頻度で復旧演習を行うか。 | 手順が古くなり、実障害で使えない。 | 年次、半期、リリース前、大規模変更前などの実施タイミングを決める。 |
| 責任者 | 設計責任、運用責任、復旧判断責任を誰が持つか。 | 障害時に判断者が不明になる。 | 技術責任者、業務責任者、承認者、連絡先を明記する。 |
| 変更管理 | システム変更時にバックアップ設計も更新するか。 | 新機能や新データが保全対象から漏れる。 | DB migration、外部連携追加、SaaS 追加、保存先変更時に見直す。 |
本番業務では、運用設計の粒度を「障害時に迷わない水準」まで落とす必要がある。たとえば「暗号化する」だけでは不十分である。何を暗号化するのか、鍵はどこにあるのか、誰が復号できるのか、鍵管理基盤が停止した場合にどうするのかまで決める必要がある。同様に、「監視する」だけでは不十分である。バックアップ失敗、容量不足、転送失敗、世代欠落、復旧テスト未実施、レプリケーション遅延のどれを監視するかを明確にする必要がある。
また、本番業務では「バックアップが存在すること」と「復旧権限があること」も分けて考えるべきである。バックアップを取得していても、復旧時に必要な管理者権限、クラウドアカウント、暗号鍵、DB ユーザー、DNS 更新権限、証明書更新権限がなければ業務は戻らない。したがって、バックアップ運用には、データ、手順、権限、鍵、判断者の保全も含まれる。
25. 実務における判断基準
実務では、方式名ではなく判断基準から入るべきである。次の基準を順番に確認すれば、かなりの迷いを減らせる。判断基準がない状態で方式を選ぶと、PITR、レプリケーション、スナップショット、SaaS バックアップ、Git、エクスポートのどれを採用するかが製品機能や担当者の好みに引っ張られる。
本番業務で重要なのは、技術的に可能な方式ではなく、障害時に業務を戻せる方式である。そのためには、再生成可能性、業務影響、正本、整合性、復旧粒度、復旧者、破壊耐性、復旧テストに加えて、外部連携、セキュリティ、コスト、変更頻度、監査要件、運用継続性を判断軸に入れる必要がある。特に、注文、決済、顧客情報、契約、会計、監査ログを扱う場合は、単純なファイル保存や dump だけでは判断が足りない。
| 順序 | 判断基準 | 問い | 判断の方向 |
|---|---|---|---|
| 1 | 再生成可能性 | 失っても再生成できるか。 | 再生成困難なものを最優先で守る。 |
| 2 | 業務影響 | 失うと売上、契約、顧客、法務、監査に影響するか。 | 影響範囲が広いほど RPO と復旧検証を厳しくする。 |
| 3 | 正本 | 復旧時にどれを信じるか。 | 正本と復旧用コピーを分ける。 |
| 4 | 整合性 | 単一ファイルとして戻せばよいか、DB 全体として整合して戻す必要があるか。 | 整合性が必要なら dump、snapshot、PITR、アプリケーション整合性 backup を検討する。 |
| 5 | 復旧粒度 | ファイル単位、記事単位、テーブル単位、DB 単位、システム単位のどれで戻すか。 | 人間の業務単位と技術単位を合わせる。 |
| 6 | 復旧者 | 誰が障害時に戻すか。 | 担当者不在でも戻せる手順にする。 |
| 7 | 破壊耐性 | 本番侵害時にバックアップも消されないか。 | 権限分離、隔離、WORM、別アカウントを検討する。 |
| 8 | 復旧テスト | 実際に戻したことがあるか。 | テストしていないものは期待であって保証ではない。 |
| 9 | 外部連携 | 外部決済、SaaS、API、メール、通知、DWH と整合するか。 | 復旧後の突合、再送、二重処理防止、補正手順を用意する。 |
| 10 | セキュリティ | バックアップが漏えいした場合の影響はどれほどか。 | 暗号化、アクセス制御、保存先分離、ログ監査を設計する。 |
| 11 | コスト | 平時の費用、復旧時の費用、運用者の負荷は許容できるか。 | 高可用性構成と保険としてのバックアップを分けて評価する。 |
| 12 | 変更頻度 | データ構造、保存先、外部連携はどれくらい変わるか。 | 変更管理にバックアップ設計の見直しを組み込む。 |
| 13 | 監査要件 | 誰が、いつ、何を変更したかを説明する必要があるか。 | 監査ログ、証跡、改ざん耐性、保持期間を設計する。 |
| 14 | 運用継続性 | 担当者交代後も維持できるか。 | 属人化を避け、手順書、訓練、引き継ぎ、権限棚卸しを行う。 |
判断基準は、優先順位を決めるために使う。すべての対象に最強の方式を使うと、費用と運用負荷が過大になる。逆に、すべてを単純な dump や同期だけにすると、重要業務の復旧要件を満たせない。実務では、データ分類ごとに判断基準を適用し、どの方式をどこまで採用するかを決める。
| 判断結果 | 採るべき方向 | 典型例 | 注意点 |
|---|---|---|---|
| 再生成不能で業務影響が大きい。 | 高頻度 backup、PITR、隔離保管、復旧テストを組み合わせる。 | 注文、決済、会計、契約、顧客情報。 | 外部システムとの突合手順を必ず用意する。 |
| 再生成不能だが手作業復旧でよい。 | 可搬形式保存、世代管理、手順書を重視する。 | 記事本文、設計文書、重要メモ、写真。 | 保存忘れと正本不明を防ぐ。 |
| 再生成可能だが復旧に時間がかかる。 | 中間成果物の保全または再生成手順を用意する。 | DWH 集計、検索 index、レポート cache。 | 再生成時間が RTO を超えないか確認する。 |
| 現在状態の継続が重要である。 | レプリケーション、standby、managed failover を検討する。 | 高可用性 DB、参照系 API、業務継続基盤。 | 誤削除対策として backup を別に持つ。 |
| 改ざん・削除への耐性が重要である。 | WORM、Object Lock、別アカウント、監査ログを使う。 | 監査証跡、ランサムウェア対策、証憑保管。 | 保持期間を誤ると削除できず運用制約になる。 |
本番業務の判断では、技術者が単独で「これで十分」と決めるべきではない。業務側は失われた場合の影響を知っている。技術側は実現コストと方式の限界を知っている。法務・監査・セキュリティは保持期間、権限、証跡、漏えい時の影響を知っている。実務上の判断基準は、これらの観点を揃えるための共通言語である。
26. 実務チェックリスト
ここでは実務でそのまま使える形のチェックリストを整理する。チェックリストは、設計時、実装時、日次運用、復旧時、定期レビューで分ける。単一の長いチェックリストにすると、いつ何を確認するかが曖昧になる。本番業務では、チェックリストは単なる確認表ではなく、運用漏れ、属人化、復旧不能、セキュリティ事故を防ぐための制御である。巨大システム運用では、個別要素が正しくても、責任分界、判断手順、訓練、連絡、例外時の判断が噛み合わなければ事故に至る。この観点は、タイタニック号事故を巨大システム運用として整理した考察とも接続する[44]。
チェックリストは、作って終わりではない。システム変更、DB migration、保存先追加、外部 API 追加、クラウドアカウント変更、権限変更、担当者交代、インシデント後には更新する必要がある。更新されないチェックリストは、障害時に誤った手順を実行させる危険がある。
26.1 設計時チェックリスト
| 項目 | 確認内容 | 目的 |
|---|---|---|
| 業務機能 | どの業務機能を復旧対象にするかを列挙した。 | DB は戻ったが業務が戻らないことを防ぐ。 |
| 保全対象 | DB、ファイル、設定、コード、ログ、手順、鍵、証明書を分けて列挙した。 | 重要な構成要素の漏れを防ぐ。 |
| 除外対象 | キャッシュ、一時ファイル、再生成可能な成果物などを除外対象として明示した。 | 不要なデータが増え、復旧時の判断が遅くなることを防ぐ。 |
| 正本 | 各データについて復旧時に信じる正本を定義した。 | 複数コピーのどれが正しいか判断できない状態を防ぐ。 |
| RPO / RTO / RLO | データ種別ごとに許容損失、復旧時間、最低復旧水準を定義した。 | バックアップ頻度と業務要件のずれを防ぐ。 |
| 障害種別 | 物理障害、論理障害、侵害、災害、外部依存障害ごとの方針を定義した。 | 障害種別に合わない復旧方式を選ぶことを防ぐ。 |
| 外部連携 | 決済、SaaS、メール、API、DWH、通知基盤との整合確認を定義した。 | 自システムだけ戻っても業務整合性が崩れることを防ぐ。 |
| セキュリティ | バックアップの機密性、完全性、可用性、削除耐性を定義した。 | バックアップ自体が漏えい・削除・改ざんされることを防ぐ。 |
| 責任分界 | 業務判断者、技術作業者、承認者、連絡責任者を決めた。 | 障害時に誰が決めるか不明になることを防ぐ。 |
26.2 実装時チェックリスト
| 項目 | 確認内容 | 目的 |
|---|---|---|
| 取得確認 | バックアップファイルまたは復旧ポイントが実際に生成されている。 | 設定だけ存在し、バックアップが取れていない状態を防ぐ。 |
| 整合性 | DB、ファイル、アプリケーションの整合性を考慮して取得している。 | 戻した後にアプリケーションが不整合になることを防ぐ。 |
| 遠隔退避 | 本番ホスト喪失時にも取得物を取り出せる場所に保存している。 | 本番障害と同時にバックアップも失うことを防ぐ。 |
| 暗号化と鍵管理 | 保存時と転送時の暗号化、復号鍵の保管場所、復旧時の利用手順を確認した。 | 漏えい時の被害と復号不能を防ぐ。 |
| 削除耐性 | 本番権限だけで全世代を削除できない構成にした。 | 侵害時にバックアップも消されることを防ぐ。 |
| 通知 | 成功だけでなく失敗、容量不足、遅延、世代欠落も通知される。 | 停止に気づかない状態を防ぐ。 |
| 復旧先 | 復旧テスト用の環境または手順を用意した。 | 本番障害時に初めて復旧先を作ることを防ぐ。 |
| 権限 | 復旧に必要なクラウド、DB、ストレージ、DNS、証明書、secret の権限を確認した。 | データはあるが権限不足で戻せない状態を防ぐ。 |
26.3 日次運用チェックリスト
| 項目 | 確認内容 | 目的 |
|---|---|---|
| ジョブ成功 | 直近のバックアップジョブが成功している。 | 取得失敗に早期に気づく。 |
| 取得時刻 | 想定時刻に取得されている。 | 遅延や停止を検出する。 |
| 保存容量 | 保存先容量が閾値を超えていない。 | 容量不足による取得失敗を防ぐ。 |
| 世代数 | 保持すべき世代が残っている。 | 削除設定ミスや保持不足を防ぐ。 |
| 転送結果 | 遠隔退避が成功している。 | 本番ホスト内だけにバックアップが残る状態を防ぐ。 |
| 異常増減 | バックアップサイズが急増または急減していない。 | 取得対象漏れ、データ破壊、大量生成を検知する。 |
| 未保全変更 | 日次バックアップ後の重要変更が別途保全されている。 | 日次取得間隔の空白を補う。 |
26.4 復旧時チェックリスト
| 項目 | 確認内容 | 目的 |
|---|---|---|
| 障害種別分類 | 物理障害、論理障害、侵害、外部依存障害を分類した。 | 復旧方針の誤選択を防ぐ。 |
| 現在状態保全 | 壊れた現在状態を可能な範囲で退避した。 | 調査と再復旧のための証跡を残す。 |
| 復旧対象時点 | どの世代、どの時刻、どの event position へ戻すかを決めた。 | 戻しすぎや戻し不足を防ぐ。 |
| 復旧対象範囲 | DB 全体、特定ファイル、記事本文、設定のどれを戻すかを決めた。 | 不要な巻き戻しを防ぐ。 |
| 復旧先 | 本番へ直接戻すか、隔離環境で検証するかを決めた。 | 壊れたデータや侵害状態を本番へ戻すことを防ぐ。 |
| 外部連携 | 決済、メール、API、DWH、通知の再送・重複・未反映を確認した。 | DB 復旧後の業務不整合を防ぐ。 |
| 正常性確認 | 復旧後に確認する画面、データ、ログ、外部連携を決めた。 | 戻しただけで完了にしない。 |
| 業務承認 | 業務側が再開可否を確認した。 | 技術的起動と業務再開を混同しない。 |
26.5 定期レビュー チェックリスト
| 項目 | 確認内容 | 目的 |
|---|---|---|
| 対象棚卸し | 新しい DB、bucket、SaaS、外部連携、ログ基盤が増えていないか確認した。 | 保全対象漏れを防ぐ。 |
| 復旧演習 | 実際にバックアップから復旧した。 | 復旧可能性を検証する。 |
| 権限棚卸し | 復旧権限、削除権限、鍵アクセス権を確認した。 | 退職者権限や過剰権限を防ぐ。 |
| 保持期間 | 業務要件、監査要件、法務要件と一致している。 | 短すぎる保持や不要な長期保持を防ぐ。 |
| コスト | 保存容量、転送量、マネージド backup、DR 環境の費用を確認した。 | 放置による費用膨張を防ぐ。 |
| 手順更新 | 復旧手順書が現在の構成と一致している。 | 古い手順による復旧失敗を防ぐ。 |
27. 設計テンプレート
バックアップ・リカバリー設計書は、読むだけで対象、責任、方式、復旧判断が分かる必要がある。テンプレートは長すぎても使われないが、短すぎると判断できない。本番業務では、設計書は単なる説明資料ではなく、障害時の判断基準、監査時の説明資料、担当者交代時の引き継ぎ資料でもある。
設計テンプレートで重要なのは、「何を取るか」だけでなく、「なぜそれでよいのか」「何を守らないのか」「どの障害には効かないのか」を書くことである。特に本番業務では、除外対象と限界を明示する必要がある。限界が書かれていない設計書は、障害時に過信される。
| 章 | 記載項目 | 記載例 | 本番業務での注意点 |
|---|---|---|---|
| 1. 対象システム | システム名、主要業務、利用者、管理責任者、技術責任者、関連システムを書く。 | WordPress blog、公開記事提供、管理者 1 名、Apache / MySQL / WordPress。 | 外部 DNS、証明書、メール、CDN、監視も関連システムとして含める。 |
| 2. 業務影響 | 停止時、データ喪失時、誤復旧時の業務影響を書く。 | 公開記事が見えない、予約投稿が失われる、編集差分が巻き戻る。 | 売上、顧客、法務、監査、信用、社内業務への影響を分ける。 |
| 3. 保全対象 | DB、ファイル、設定、コード、ログ、手順書、鍵、証明書を分類する。 | WordPress DB、uploads、Apache vhost、wp-config.php、原稿 HTML。 | データ本体だけでなく、復旧に必要な設定と権限も含める。 |
| 4. 除外対象 | バックアップしないものと理由を書く。 | キャッシュ、再生成可能な一時ファイル。 | 除外理由が変わった場合に見直せるようにする。 |
| 5. 正本定義 | 各データについて、復旧時に信じる正本を定義する。 | 公開済み本文は WordPress、日次以後の原稿は手元 HTML。 | 通常時、日次 backup 前、障害時で正本が変わる場合は明記する。 |
| 6. RPO / RTO / RLO | 業務機能ごとの許容損失、復旧時間、最低復旧水準を書く。 | 公開済み表示は日次時点、原稿本文はゼロ損失に近づける、完全復旧は手作業でよい。 | 経営・業務・技術の合意事項として扱う。 |
| 7. バックアップ方式 | 対象ごとの方式、頻度、保持期間、保存先、暗号化、削除耐性を書く。 | DB は日次 dump、原稿は YYYYMMDD-N.html、uploads は別途同期。 | 方式ごとに守れるリスクと守れないリスクを書く。 |
| 8. 監視と通知 | 成功、失敗、遅延、容量、世代欠落、レプリケーション lag の通知を書く。 | 失敗時はメールまたは監視基盤で通知する。 | 成功通知だけではなく、長期間成功していない状態を検出する。 |
| 9. 権限と鍵管理 | バックアップ閲覧、復元、削除、復号に必要な権限を書く。 | backup storage は本番ユーザーから削除不可にする。 | 本番侵害時に backup まで消されない権限設計にする。 |
| 10. 復旧手順 | 復旧順序、復旧先、作業者、判断者、停止条件を書く。 | DB 復元後、失われた原稿を HTML から貼り直す。 | 本番直接復旧と隔離環境復旧を分ける。 |
| 11. 正常性確認 | 復旧後に確認する画面、データ、ログ、外部連携を書く。 | トップページ、対象記事、管理画面、Apache error log。 | 技術確認と業務確認を分ける。 |
| 12. 復旧演習 | 演習頻度、演習対象、記録方法、改善反映方法を書く。 | 半期に一度、検証環境へ DB dump を復元する。 | 演習結果を設計書と手順書へ反映する。 |
| 13. 変更管理 | どの変更時にバックアップ設計を見直すかを書く。 | DB schema 変更、プラグイン追加、保存先変更時に見直す。 | リリースチェックリストに含める。 |
設計書には、方式の限界も明記する必要がある。たとえば、日次 dump は日次以後の更新を守らない。レプリケーションは誤削除を防がない。同期はランサムウェアを広げる可能性がある。HTML 保存は画像本体や投稿メタを守らない。PITR はログと基準バックアップの連続性がなければ機能しない。この限界を設計書に書くことで、復旧時の誤用を防げる。
また、設計書と復旧手順書は分けるべきである。設計書は、なぜその方式を採るのかを説明する文書である。復旧手順書は、障害時にそのまま実行する文書である。設計書に思想と判断基準を書き、復旧手順書に具体的なコマンド、画面操作、確認項目、連絡先を書く。この分離により、平時の設計理解と障害時の実行を両立できる。
28. 復旧手順テンプレート
復旧手順書は設計書とは別に作る。設計書はなぜそうするかを説明する文書であり、復旧手順書は障害時にそのまま実行する文書である。NIST SP 800-61 Rev. 3 も、インシデント対応を通じてリスクを低減し、データ損失や被害を最小化するために体系的な対応と復旧を重視している[45]。
本番業務の復旧手順書では、作業順序だけでなく、判断点を明確にする必要がある。障害種別が物理障害なのか、論理障害なのか、侵害なのかによって、使う backup、復旧先、確認項目、連絡先が変わる。特に侵害やランサムウェアの疑いがある場合は、本番環境へ直接 restore してはいけない。クリーンな隔離環境で復旧し、侵害経路、バックドア、アカウント、鍵、ログを確認してから復帰する必要がある。
| 段階 | 手順 | 判断ポイント | 記録すべき事項 |
|---|---|---|---|
| 1. 初動 | 障害を検知し、影響範囲、発生時刻、直近変更、現在の本番状態を記録する。 | 物理障害か、論理障害か、侵害の疑いがあるかを分類する。 | 検知時刻、通報者、症状、直近リリース、監視アラート。 |
| 2. 封じ込め | 必要に応じて対象サービス、ジョブ、同期、レプリケーション、外部連携を停止する。 | 壊れた状態や攻撃影響が広がっているかを判断する。 | 停止した処理、停止理由、再開条件、影響範囲。 |
| 3. 現在状態保全 | 壊れた現在状態を可能な範囲で退避する。 | 原因調査や差分復元に必要な証跡を残す。 | 退避した DB、ログ、ファイル、設定、スクリーンショット。 |
| 4. 復旧方針決定 | 復旧対象時点、復旧対象範囲、復旧先環境を決める。 | 本番へ直接戻すのか、隔離環境で検証してから戻すのかを決める。 | 採用する backup 世代、PITR 時刻、復旧対象範囲、判断者。 |
| 5. 復旧前準備 | 復旧先、権限、鍵、ネットワーク、DNS、証明書、外部接続の準備を確認する。 | データは戻せてもサービスが起動できない状態を避ける。 | 復旧先環境、使用した権限、鍵、設定差分。 |
| 6. データ復元 | DB、ファイル、設定、原稿 HTML などを必要な順序で戻す。 | DB とファイルの整合性、本文差分、設定漏れを確認する。 | 実行した restore、適用した dump、戻したファイル、エラー。 |
| 7. アプリケーション起動 | アプリケーション、Web サーバー、バッチ、キュー、外部連携を段階的に起動する。 | 一気に再開して不整合や再送を起こさないようにする。 | 起動順序、起動結果、保留したジョブ、再開条件。 |
| 8. 正常性確認 | ログイン、主要画面、主要データ、書き込み処理、ログ、バッチ、外部連携を確認する。 | 最低復旧水準を満たしたか、完全復旧まで進めるかを判断する。 | 確認した画面、件数、金額、外部突合、業務担当者確認。 |
| 9. 業務再開判断 | 技術確認と業務確認を分け、業務責任者が再開可否を判断する。 | システム起動と業務再開を混同しない。 | 再開判断者、再開時刻、制限事項、顧客告知。 |
| 10. 後追い処理 | 停止中の注文、通知、メール、外部 API、バッチ、ログ反映を処理する。 | 二重処理、未処理、重複通知を防ぐ。 | 再処理件数、失敗件数、補正内容、外部突合結果。 |
| 11. 監視強化 | 復旧後一定期間、エラー、遅延、件数異常、外部連携異常を重点監視する。 | 復旧直後の潜在不整合を早期に検出する。 | 監視期間、監視項目、発見した異常、対応内容。 |
| 12. 事後レビュー | 原因、検知、復旧時間、手順の問題、再発防止を記録する。 | 手順書とバックアップ設計を更新する。 | RPO 実績、RTO 実績、RLO 達成状況、改善タスク。 |
復旧手順書では、障害種別ごとの分岐も必要である。物理障害であれば standby への切替や backup からの復元が中心になる。論理障害であれば、壊れる前の時点を特定し、PITR や世代 backup から戻す。侵害であれば、復旧より先に封じ込めとクリーン確認が必要になる。外部依存障害であれば、自社システムを戻すより、縮退運転、キューイング、手動受付、後追い処理が中心になる場合がある。
| 障害種別 | 最初にやること | 避けるべきこと | 復旧の中心 |
|---|---|---|---|
| 物理障害 | 影響範囲と利用可能な replica / backup を確認する。 | 原因確認前に不要な書き込みを再開する。 | 切替、restore、環境再構築。 |
| 論理障害 | 壊れた時刻、変更内容、影響データを特定する。 | 最新 replica を正しい状態として採用する。 | PITR、部分復旧、差分補正。 |
| セキュリティ事故 | 封じ込め、証跡保全、侵害範囲確認を行う。 | 侵害された可能性のある環境へそのまま復元する。 | 隔離環境復旧、鍵・アカウント再発行、クリーン確認。 |
| 外部依存障害 | 外部サービスの状態、未処理キュー、影響業務を確認する。 | 自社 DB を不用意に巻き戻す。 | 縮退運転、手動処理、後追い反映、突合。 |
| データ不整合 | どのシステムを正本とするかを決める。 | 一方の DB だけを戻して整合したとみなす。 | 突合、補正ジョブ、手動修正、監査ログ確認。 |
最後に、復旧手順書には「実行してはいけないこと」も書くべきである。障害時には焦りがあり、権限を持つ担当者が直接本番 DB を触りたくなる。だが、本番業務では、現在状態の保全なしに restore する、侵害疑いのある環境をそのまま再利用する、外部連携を止めずに DB だけ巻き戻す、業務確認なしに復旧完了とする、という行為は危険である。禁止事項を明文化することも、復旧手順の一部である。
29. 数理モデル：保全戦略を価値、障害、復旧可能性、運用負荷で評価する
ここで、保全戦略を数理モデルとして整理する。数理モデルの目的は、厳密な数値計算ではない。重要なのは、保全戦略の判断構造を明示することである。ここまで見てきたように、データ保全は「バックアップを取るか取らないか」という単純な問題ではない。データ種別、障害種別、復旧粒度、正本、RPO、RTO、RLO、セキュリティ、運用負荷、復旧検証、外部連携を同時に考える必要がある。
したがって、保全戦略を単一の点数で評価するだけでは不十分である。単純に \(E(S)=W(S)-C(S)-R(S)\) と置くと、どのデータを守っているのか、どの障害に効くのか、復旧後に業務として使えるのか、複雑性が運用失敗を増やすのかが見えなくなる。より実務に近いモデルでは、保全戦略 \(S\) を単一の方式ではなく、複数の保全層の組み合わせとして扱う。
S = \{s_1, s_2, \ldots, s_k\}
\]
この式で、\(S\) は全体の保全戦略であり、\(s_j\) は個別の保全方式である。たとえば、日次 DB dump、binary log / PITR、レプリケーション、オフサイトバックアップ、Object Lock、HTML export、Git、IaC、復旧手順書、復旧演習は、それぞれ \(s_j\) として扱える。実務上の保全戦略は、単一方式ではなく、これらの組み合わせである。
| 記号 | 意味 | 実務上の読み方 |
|---|---|---|
| \(S\) | 保全戦略全体。 | 複数方式を組み合わせた運用設計全体である。 |
| \(s_j\) | 個別の保全方式。 | dump、PITR、replication、HTML 保存、Git、WORM、復旧演習などである。 |
| \(k\) | 採用している保全方式の数。 | 方式が増えるほど守備範囲は広がるが、運用複雑性も増える。 |
次に、保全対象をデータ種別 \(i\)、障害種別を \(h\)、業務機能を \(f\) として分ける。データ保全では、同じ戦略でも対象と障害によって有効性が変わる。HTML 保存は本文消失には強いが DB 全体の整合復旧には弱い。レプリケーションはホスト障害には強いが誤削除には弱い。PITR は論理障害には強いが、運用訓練がなければ復旧時に失敗する。
D = \{d_1, d_2, \ldots, d_n\}, \quad H = \{h_1, h_2, \ldots, h_m\}, \quad F = \{f_1, f_2, \ldots, f_l\}
\]
ここで、\(D\) は保全対象となるデータ集合、\(H\) は想定する障害集合、\(F\) は業務機能集合である。たとえば \(d_i\) は本文、注文、決済、契約、顧客情報、設定、監査ログ、画像、キャッシュであり、\(h\) は物理障害、論理障害、誤削除、侵害、ランサムウェア、災害、外部依存障害である。\(f\) は注文受付、決済確認、記事公開、顧客対応、管理画面、監査対応などである。
まず、データ種別 \(d_i\) の業務価値を \(V_i\) とする。ただし、価値は単なる重要度ではない。再生成困難性、業務影響、法務・監査影響、外部連携影響、信用影響を含む複合的な値である。
V_i = \alpha A_i + \beta B_i + \gamma L_i + \delta G_i + \epsilon T_i
\]
| 記号 | 意味 | 実務上の読み方 |
|---|---|---|
| \(A_i\) | 再生成困難性。 | 失ったときに人間が再作成できるか。長文本文、契約、証憑、取引履歴は高い。 |
| \(B_i\) | 業務影響。 | 失うと業務停止、売上損失、顧客対応負荷が出るか。 |
| \(L_i\) | 法務・監査影響。 | 説明責任、監査、契約、申告、証跡に影響するか。 |
| \(G_i\) | 外部連携影響。 | 決済、在庫、DWH、SaaS、API との整合に影響するか。 |
| \(T_i\) | 信用影響。 | 顧客、読者、社内利用者、監査人からの信頼に影響するか。 |
| \(\alpha,\beta,\gamma,\delta,\epsilon\) | 重み。 | 組織や用途に応じた評価重みである。 |
この式で重要なのは、データ価値を「重要そうだから高い」と雑に扱わないことである。個人ブログ本文は売上や法務影響は小さいかもしれないが、再生成困難性は高い。EC 注文 DB は再生成困難性、業務影響、外部連携影響がすべて高い。監査ログは通常業務の画面には出ないが、法務・監査影響が高い。価値を分解することで、保全方式の選択理由が明確になる。
次に、戦略 \(S\) が、データ \(d_i\) を、障害 \(h\) の発生時に、業務上使える形で復旧できる確率を \(P_{i,h}(S)\) と置く。これは単なるファイル存在確率ではない。取得できていること、破損していないこと、復号できること、復旧手順があること、復旧者が実行できること、復旧後に業務上整合していることを含む。
P_{i,h}(S) = P_{cap,i,h}(S) \cdot P_{int,i,h}(S) \cdot P_{dec,i,h}(S) \cdot P_{op,i,h}(S) \cdot P_{biz,i,h}(S)
\]
| 記号 | 意味 | 実務上の読み方 |
|---|---|---|
| \(P_{cap,i,h}(S)\) | 取得成功確率。 | 必要な backup、log、export、snapshot が実際に取れているか。 |
| \(P_{int,i,h}(S)\) | 完全性確率。 | 破損、欠落、改ざん、世代不足がないか。 |
| \(P_{dec,i,h}(S)\) | 復号・読取可能性。 | 暗号鍵、形式、バージョン、ツールが利用できるか。 |
| \(P_{op,i,h}(S)\) | 運用実行可能性。 | 復旧手順、権限、担当者、訓練が揃っているか。 |
| \(P_{biz,i,h}(S)\) | 業務利用可能性。 | 復旧後に業務上正しい状態として使えるか。外部連携や整合性も含む。 |
この分解が重要である。バックアップファイルが存在していても、暗号鍵がなければ \(P_{dec}\) は低い。PITR の log があっても、復旧手順を誰も試していなければ \(P_{op}\) は低い。DB は戻っても外部決済と突合できなければ \(P_{biz}\) は低い。つまり、実務上の復旧可能性は、複数の確率の積である。どれか一つがゼロに近いと、全体もゼロに近づく。
戦略 \(S\) が生む期待保全価値 \(W(S)\) は、データ価値 \(V_i\)、障害発生確率 \(\pi_h\)、障害時の復旧可能性 \(P_{i,h}(S)\)、復旧品質 \(Q_{i,h}(S)\) を用いて次のように表せる。
W(S) = \sum_i \sum_h V_i \cdot \pi_h \cdot P_{i,h}(S) \cdot Q_{i,h}(S)
\]
\(Q_{i,h}(S)\) は復旧品質である。復旧できたとしても、完全復旧か、部分復旧か、読み取り専用か、手作業補正が必要か、外部連携と突合が必要かで品質は違う。たとえば、WordPress 本文 HTML は本文の復旧品質は高いが、投稿メタや画像本体の復旧品質は低い。EC 注文 DB では、注文だけ戻っても決済、在庫、メール、外部 API と整合しなければ \(Q\) は低い。
次に、コストを考える。コストは金銭だけではない。構築、運用、監視、復旧訓練、セキュリティ管理、認知負荷、変更追随、障害時判断負荷が含まれる。
C(S) = C_{setup}(S) + C_{run}(S) + C_{monitor}(S) + C_{test}(S) + C_{security}(S) + C_{change}(S) + C_{cognitive}(S)
\]
| 項 | 意味 | 実務上の読み方 |
|---|---|---|
| \(C_{setup}\) | 初期構築コスト。 | 設定、構築、初期検証、導入作業である。 |
| \(C_{run}\) | 平時運用コスト。 | 保存容量、転送量、定期確認、保守作業である。 |
| \(C_{monitor}\) | 監視コスト。 | 失敗検知、容量監視、lag 監視、通知運用である。 |
| \(C_{test}\) | 復旧訓練コスト。 | 復旧演習、検証環境、手順更新である。 |
| \(C_{security}\) | セキュリティ管理コスト。 | 暗号化、鍵管理、権限分離、監査ログ、WORM 管理である。 |
| \(C_{change}\) | 変更追随コスト。 | DB schema 変更、保存先追加、外部連携追加時の見直しである。 |
| \(C_{cognitive}\) | 認知負荷。 | 担当者が仕組みを理解し、障害時に迷わず扱えるかである。 |
ここで重要なのは、複雑な方式は \(W(S)\) を増やす一方で、\(C(S)\) も増やすことである。さらに、複雑性は単なるコストではなく、運用失敗確率にも影響する。方式が増え、設定が増え、権限が増え、復旧手順が増えるほど、人間は誤る。したがって、複雑性を独立した項として扱う。
K(S) = k_1 N_{tools}(S) + k_2 N_{steps}(S) + k_3 N_{roles}(S) + k_4 N_{secrets}(S) + k_5 N_{branches}(S)
\]
\(K(S)\) は複雑性である。ツール数、復旧手順数、関与するロール数、秘密情報数、障害時の分岐数が増えるほど、複雑性は増える。複雑性は、直接的な運用コストだけでなく、誤復旧、設定漏れ、監視漏れ、権限不足、手順陳腐化の原因になる。
この複雑性を、運用失敗リスクへ反映する。たとえば、運用失敗確率 \(M(S)\) を次のように置ける。
M(S) = 1 – e^{-\eta K(S)}
\]
この式は、複雑性 \(K(S)\) が増えるほど運用失敗確率 \(M(S)\) が増えることを表す。最初は小さく見える複雑性でも、方式が積み重なると障害時の判断負荷は急に上がる。これは実務上重要である。高度な方式を追加することは、単に保護を増やすだけではない。失敗経路も増やす。
次に、残存リスクを整理する。残存リスク \(R(S)\) は、障害発生確率、影響額または影響度、復旧不能確率、検知遅延、復旧遅延、セキュリティ侵害時の被害拡大を含めて見る。
R(S) = \sum_i \sum_h V_i \cdot \pi_h \cdot \left(1 – P_{i,h}(S)Q_{i,h}(S)\right) \cdot L_{i,h}(S)
\]
ここで、\(L_{i,h}(S)\) は障害 \(h\) がデータ \(d_i\) に及ぼす追加損失係数である。たとえば、検知が遅い、復旧に時間がかかる、外部連携と不整合が起きる、顧客影響が広がる、監査証跡が失われる場合、\(L_{i,h}(S)\) は大きくなる。
RPO、RTO、RLO は、単なる評価項目ではなく制約条件である。ある戦略がいくら総合評価で高く見えても、業務が要求する RPO、RTO、RLO を満たさないなら採用できない。
RPO_i(S) \leq RPO_i^{req}
\]
RTO_f(S) \leq RTO_f^{req}
\]
RLO_f(S) \geq RLO_f^{req}
\]
| 制約 | 意味 | 実務上の読み方 |
|---|---|---|
| \(RPO_i(S) \leq RPO_i^{req}\) | データ \(i\) の損失時間が要求以内である。 | 注文 DB が 5 分以内の損失しか許されないなら、日次 dump だけでは不適合である。 |
| \(RTO_f(S) \leq RTO_f^{req}\) | 業務機能 \(f\) の復旧時間が要求以内である。 | 短時間再開が必要なら、backup restore だけでなく standby や縮退運転が必要になる。 |
| \(RLO_f(S) \geq RLO_f^{req}\) | 業務機能 \(f\) が最低復旧水準を満たす。 | 完全復旧でなくても、注文受付だけ再開できればよい場合がある。 |
以上を踏まえると、保全戦略の評価は次のように表せる。
E(S) = W(S) – C(S) – R(S) – \rho K(S)
\]
ただし、この \(E(S)\) は制約条件を満たす戦略同士を比較するための評価である。RPO、RTO、RLO、法務要件、セキュリティ要件を満たさない戦略は、点数が高く見えても候補から外す。つまり、実務では次の constrained optimization として考える方が正確である。
S^* = \arg\max_{S \in \mathcal{S}} E(S)
\]
\text{subject to } RPO_i(S) \leq RPO_i^{req}, \quad RTO_f(S) \leq RTO_f^{req}, \quad RLO_f(S) \geq RLO_f^{req}
\]
Sec(S) \geq Sec^{req}, \quad Audit(S) \geq Audit^{req}, \quad Operable(S) = 1
\]
ここで \(S^*\) は採用すべき戦略である。\(Sec(S)\) はセキュリティ要件の充足度、\(Audit(S)\) は監査要件の充足度、\(Operable(S)\) は実際に運用可能かどうかを表す。どれほど高度な戦略でも、運用できないなら \(Operable(S)=0\) であり、候補から外すべきである。
このモデルの結論は、「高度な方式ほどよい」でも「シンプルな方式ほどよい」でもない。データ価値、障害種別、復旧品質、制約条件、複雑性、運用可能性を同時に見たとき、対象ごとに最適な方式は変わる。DB 全体の整合性が価値なら PITR や整合 snapshot が必要になる。意味内容だけを守ればよいなら HTML や Markdown が合理的になる。可用性が重要なら replication や standby が必要になる。侵害耐性が重要なら隔離 backup や WORM が必要になる。
30. WordPress 原稿保全ルールをモデルに当てはめる
このモデルを WordPress 原稿保全に当てはめる。今回の主要価値は WordPress DB 全体ではなく、日次バックアップ以後に作成または編集した本文 HTML である。したがって、評価対象のデータ集合 \(D\) を分ける必要がある。
D = \{d_{text}, d_{meta}, d_{media}, d_{db}, d_{config}\}
\]
| データ | 内容 | 今回の価値 | 再生成可能性 |
|---|---|---|---|
| \(d_{text}\) | 投稿本文、固定ページ本文、HTML 構造、表、参考文献、MathJax。 | 高い。 | 長文記事では低い。つまり再生成困難である。 |
| \(d_{meta}\) | 投稿 ID、カテゴリー、タグ、スラッグ、予約日時、投稿状態。 | 中程度。 | 多くは手作業で再設定可能である。 |
| \(d_{media}\) | 画像、添付ファイル、uploads。 | 記事によって変わる。 | 元ファイルがあれば再投入可能である。 |
| \(d_{db}\) | WordPress DB 全体。 | サイト復旧には高い。 | dump があれば復旧可能である。 |
| \(d_{config}\) | WordPress 設定、Web サーバー設定、証明書、テーマ、プラグイン。 | 環境復旧には重要である。 | 手順化されていれば再構築可能である。 |
次に、想定する障害集合を置く。
H = \{h_{host}, h_{db}, h_{dailygap}, h_{delete}, h_{compromise}, h_{local}\}
\]
| 障害 | 内容 | 今回の焦点との関係 |
|---|---|---|
| \(h_{host}\) | 本番ホスト喪失。 | リモート退避された日次 backup が効く。 |
| \(h_{db}\) | DB 破損。 | 日次 dump が基準復旧点になる。 |
| \(h_{dailygap}\) | 日次 backup 以後の本文変更消失。 | 今回の中心問題である。 |
| \(h_{delete}\) | 誤削除、誤編集。 | HTML 保存済み本文には効くが、DB 全体には限定的である。 |
| \(h_{compromise}\) | 侵害、改ざん、ランサムウェア。 | HTML 保存先の保護と backup 隔離が必要になる。 |
| \(h_{local}\) | 手元物理マシン障害。 | HTML 保存自体の単一障害点になる。 |
比較する戦略を次のように置く。
S_{daily} = \{\text{daily dump}, \text{remote copy}\}
\]
S_{pitr} = \{\text{daily dump}, \text{binary log}, \text{PITR procedure}, \text{restore test}\}
\]
S_{rep} = \{\text{replication}, \text{monitoring}, \text{failover procedure}\}
\]
S_{html} = \{\text{daily dump}, \text{remote copy}, \text{YYYYMMDD-N.html}\}
\]
\(S_{daily}\) は既存の日次 dump とリモート退避である。これは本番ホスト喪失や DB 破損には一定の効果があるが、日次 backup 以後の本文変更には弱い。\(S_{pitr}\) は DB 全体の任意時点復旧に近づくが、binary log の保全、位置管理、復旧訓練、停止位置判断が必要になる。\(S_{rep}\) は可用性には効くが、誤削除や論理破壊も複製する。\(S_{html}\) は DB 全体を細かく戻す方式ではないが、今回の中心問題である \(h_{dailygap}\) に対して \(d_{text}\) を直接守る。
本文保全に限定したとき、\(S_{html}\) の特徴は次のように表せる。
P_{text,dailygap}(S_{html}) \approx P_{save} \cdot P_{read} \cdot P_{restore}
\]
| 項 | 意味 | 実務上の解釈 |
|---|---|---|
| \(P_{save}\) | 保存実行確率。 | 人間が忘れずに HTML を保存する確率である。 |
| \(P_{read}\) | 読取可能性。 | HTML が壊れておらず、手元で読める確率である。 |
| \(P_{restore}\) | 貼り戻し可能性。 | 障害後に WordPress へ本文を貼り直せる確率である。 |
この式から分かるように、HTML 保存の弱点は DB 技術ではなく、人間の保存忘れと手元保存先の管理である。つまり、\(S_{html}\) の改善策は binary log を追加することではなく、保存手順を単純化し、ファイル名を固定し、保存先を分かりやすくし、必要なら Git や端末 backup で手元ファイルを二重化することである。
一方、DB 全体の復旧可能性で見ると、\(S_{html}\) は高くない。
P_{db,h}(S_{html}) \approx P_{db,h}(S_{daily})
\]
つまり、HTML 保存は DB 全体の復旧能力を増やさない。これは欠点ではなく、設計上の境界である。DB 全体の復旧は日次 dump とリモート退避で守り、日次 backup 以後の本文差分は HTML で守る。複数の保全方式が役割分担している。
| 戦略 | \(d_{text}, h_{dailygap}\) | \(d_{db}, h_{db}\) | \(h_{delete}\) | \(h_{host}\) | \(K(S)\) | 今回の判断 |
|---|---|---|---|---|---|---|
| \(S_{daily}\) | 弱い。 | 中程度。 | 世代次第。 | リモート退避があれば中程度。 | 低い。 | 基準バックアップとして維持する。 |
| \(S_{pitr}\) | 強い。 | 強い。 | 強い。 | 退避設計次第。 | 高い。 | 正攻法だが、今回の本文保全には重い。 |
| \(S_{rep}\) | 現在状態には強い。 | 物理障害には強い。 | 弱い。 | 強い。 | 高い。 | 可用性対策であり、本文差分保全とは目的が違う。 |
| \(S_{html}\) | 強い。 | \(S_{daily}\) と同程度。 | 保存済み本文には強い。 | 本文は守れるが環境は戻せない。 | 低い。 | 本文保全という目的に最も適合する。 |
この比較から分かるのは、\(S_{html}\) が全体最強なのではなく、対象と障害を限定したときに最適であるということである。評価軸を \(d_{db}\) や \(h_{host}\) に置けば、PITR やレプリケーションの価値が上がる。評価軸を \(d_{text}\) と \(h_{dailygap}\) に置けば、HTML 保存の価値が上がる。したがって、今回の結論は「単純な方式が常に勝つ」ではない。「対象価値と障害種別を正しく切ると、本文には HTML 保存が勝つ」である。
また、\(S_{html}\) には残存リスクがある。保存忘れ、ローカル障害、版の取り違え、メタデータ欠落、画像未保存、未公開原稿の漏えいである。したがって、運用上は次のような補助制御を置くとよい。
| 残存リスク | モデル上の影響 | 抑制策 |
|---|---|---|
| 保存忘れ。 | \(P_{save}\) を下げる。 | 投稿・編集完了時の手順に HTML 保存を組み込む。 |
| ローカル障害。 | \(P_{read}\) を下げる。 | Git、端末 backup、外部ディスク、別ホストで補完する。 |
| 版の取り違え。 | \(P_{restore}\) と \(Q\) を下げる。 | YYYYMMDD-N.html の単純命名を守り、余計な枝分かれ命名を避ける。 |
| メタデータ欠落。 | 本文以外の \(Q\) を下げる。 | 本文専用と割り切り、カテゴリーやタグは再設定する。 |
| 画像未保存。 | \(d_{media}\) の \(P\) を上げない。 | uploads backup と元画像保存で別途守る。 |
| 未公開原稿の漏えい。 | \(R_{compromise}\) を上げる。 | 保存先権限、端末暗号化、同期範囲、削除方針を確認する。 |
したがって、WordPress 原稿保全ルールの数理的な位置づけは明確である。既存の日次 backup は \(d_{db}\) と \(h_{host}\)、\(h_{db}\) に対する基準層である。HTML 保存は \(d_{text}\) と \(h_{dailygap}\) に対する補完層である。両者を組み合わせることで、DB 全体の基準復旧点と、日次以後の本文差分保全を分離できる。これは完全復旧を捨てる判断ではなく、保全対象ごとに最適な層を分ける判断である。
31. 業務システムにモデルを適用する際の注意
業務システムにこのモデルを適用するときは、WordPress 原稿と同じ結論にはならない場合が多い。注文、決済、契約、顧客情報、入出金、監査証跡は、意味内容だけを HTML のように外部化すれば十分という性質ではない。トランザクション整合性、監査可能性、重複防止、法務要件、権限、履歴、外部連携との突合が価値の一部になる。
業務システムでは、データの価値 \(V_i\) のうち、業務影響 \(B_i\)、法務・監査影響 \(L_i\)、外部連携影響 \(G_i\) が大きくなる。さらに、復旧品質 \(Q_{i,h}(S)\) が非常に重要になる。DB が起動しただけでは業務復旧ではない。注文と決済が一致しているか、在庫が正しいか、メールや通知が二重送信されていないか、DWH や会計システムと差分がないかを確認しなければならない。
たとえば EC 注文 DB では、注文データだけを戻しても不十分である。外部決済では決済済みだが自社 DB では未決済になっている、在庫は減っているが注文は消えている、メールは送られたが履歴がない、DWH には古い状態が流れている、という不整合が起こり得る。この場合、復旧戦略の評価には外部整合性を入れなければならない。
Q_{i,h}(S) = Q_{data,i,h}(S) \cdot Q_{rel,i,h}(S) \cdot Q_{external,i,h}(S) \cdot Q_{audit,i,h}(S)
\]
| 記号 | 意味 | 業務上の読み方 |
|---|---|---|
| \(Q_{data}\) | データ単体の復旧品質。 | 対象データが欠落・破損なく戻っているか。 |
| \(Q_{rel}\) | 内部整合性。 | 複数テーブル、ファイル、ジョブ状態が整合しているか。 |
| \(Q_{external}\) | 外部連携整合性。 | 決済、在庫、SaaS、API、メール、DWH と整合しているか。 |
| \(Q_{audit}\) | 監査可能性。 | 誰が、いつ、何を復旧し、どの差分があったか説明できるか。 |
この式で分かるように、業務システムの復旧品質は積で効く。データ本体が戻っても、外部連携が不整合なら \(Q_{external}\) が低くなり、全体の \(Q\) が下がる。監査証跡が失われれば \(Q_{audit}\) が下がる。したがって、業務システムでは「戻ったか」ではなく「業務上正しい状態として戻ったか」を評価しなければならない。
また、業務システムでは RPO / RTO / RLO が制約条件として強く働く。注文 DB の RPO が数分であれば、日次 dump は候補にならない。決済処理の RLO が「二重請求を防げる状態」であれば、DB restore だけでは足りず、外部決済との突合手順が必要になる。監査ログの要件が厳しければ、通常 backup だけでなく改ざん耐性のある保管が必要になる。
| 対象 | 主要価値 | 制約条件 | 適した方式 | 理由 |
|---|---|---|---|---|
| 個人ブログ本文 | 意味内容、HTML 構造、参考文献、思考の再生成困難性。 | 低 RPO だが RTO は緩い。手作業復旧でよい。 | HTML 手元保存 + 日次 DB dump。 | 本文が主価値であり、手作業再投入が可能である。 |
| EC 注文 DB | 注文、決済、在庫、顧客、配送状態の整合性。 | RPO と RTO が厳しい。外部決済との整合が必要である。 | PITR + 整合性ある backup + replica + 復旧訓練 + 突合手順。 | トランザクション整合性と外部連携整合性が価値の一部だからである。 |
| 会計・契約データ | 証憑、監査可能性、法務説明責任。 | 長期保持、改ざん耐性、アクセス制御が必要である。 | DB backup + 帳票 export + 証憑保管 + WORM / Object Lock。 | 復旧だけでなく、証明可能性と改ざん耐性が必要だからである。 |
| 社内文書 | 文書本文、版履歴、権限、合意内容。 | 閲覧権限、版管理、退職者アクセス、SaaS 依存が問題になる。 | SaaS 履歴 + 定期 export + Markdown / PDF + 権限監査。 | 本文と共有状態の両方を守る必要がある。 |
| サーバー設定 | 再構築可能性、変更履歴、差分確認。 | 秘密情報を漏らさず、環境を再現できる必要がある。 | Git + IaC + secret manager + 復旧手順。 | 設定は履歴化し、秘密情報は別管理する必要がある。 |
| 監査ログ | 事後調査、証跡、改ざん検知。 | 削除耐性、改ざん耐性、長期保持、検索性が必要である。 | append-only storage + WORM + SIEM + 長期保持。 | 攻撃者や管理者が消せない形で残す必要がある。 |
業務システムにモデルを適用する際の最大の注意点は、モデルの数値を過信しないことである。\(V_i\)、\(\pi_h\)、\(P_{i,h}\)、\(Q_{i,h}\)、\(C(S)\)、\(R(S)\) は厳密に測定できるとは限らない。むしろ、このモデルの価値は、数値を正確に入れることではなく、議論すべき変数を漏らさないことにある。再生成困難性、外部連携、監査、復旧品質、複雑性、運用可能性を明示すれば、方式選定が担当者の好みではなく構造的判断になる。
また、業務システムでは、単純な期待値最大化だけでは不十分である。発生確率は低いが破滅的影響を持つリスクがある。たとえば、全 backup 削除、暗号鍵喪失、監査ログ改ざん、決済不整合、大規模個人情報漏えいは、期待値だけで見ると軽視される可能性がある。しかし、実務では上限損失、規制、信用、説明責任を考える必要がある。そのため、最大許容損失を制約として置く。
MaxLoss(S) \leq L^{max}
\]
\(MaxLoss(S)\) は想定される最大損失であり、\(L^{max}\) は組織として許容できる最大損失である。たとえ通常時の期待評価 \(E(S)\) が高くても、ランサムウェアで全世代が削除される、暗号鍵が失われる、監査証跡が消えるといった破滅的リスクが残るなら、その戦略は本番業務では不適切である。
さらに、業務システムでは復旧演習によって \(P_{op}\) と \(P_{biz}\) を上げる必要がある。バックアップ方式を導入するだけでは、復旧可能性は上がりきらない。演習によって手順を確認し、復旧時間を測定し、権限不足を発見し、外部連携の突合方法を確認し、手順書を更新する。この運用を通じて初めて、モデル上の \(P_{op}\) と \(P_{biz}\) が現実的に上がる。
P_{op,i,h}(S,t+1) = P_{op,i,h}(S,t) + \Delta P_{test} – \Delta P_{drift}
\]
この式は、運用実行可能性が時間とともに変化することを表す。復旧演習を行えば \(\Delta P_{test}\) によって実行可能性は上がる。一方、システム変更、担当者交代、手順書の陳腐化、権限変更、クラウド仕様変更によって \(\Delta P_{drift}\) が発生し、実行可能性は下がる。したがって、復旧可能性は一度設計すれば固定されるものではない。継続的に維持する必要がある。
この観点から見ると、バックアップ・リカバリー戦略は静的な設計ではなく、時間とともに劣化する運用資産である。取得方式は動いていても、復旧手順は古くなる。担当者は変わる。権限は変わる。DB schema は変わる。外部 API は変わる。したがって、保全戦略の評価は一度きりではなく、定期レビューによって更新しなければならない。
この章の結論は、数理モデルは「最適な方式を一発で計算する道具」ではないということである。数理モデルは、保全戦略の判断構造を可視化する道具である。WordPress 原稿保全では、本文という意味内容に価値を集中させ、日次 backup 以後の空白を HTML 保存で埋める判断が合理的である。一方、本番業務システムでは、整合性、外部連携、監査、RPO、RTO、RLO、最大損失、復旧演習まで含めて、より重い戦略を採る必要がある。対象が違えば、最適解は変わる。数理モデルの価値は、その違いを説明可能にする点にある。
32. 結論：バックアップとは保存ではなく、未来の復元可能性を設計することである
バックアップとは、データを保存することではない。保存は必要条件であって、十分条件ではない。重要なのは、保存されたデータが、必要な時点に、必要な粒度で、必要な権限を持つ人によって、実際に取り戻せることである。さらに、取り戻したものが業務上、文章上、監査上、運用上の意味を持つ状態でなければならない。したがって、バックアップの本質は保存ファイルの存在ではなく、未来の復元可能性を設計することにある。
この復元可能性には、複数の層がある。第一に、データそのものが残っている必要がある。第二に、そのデータを読める形式、復号できる鍵、開ける環境が必要である。第三に、それがどの時点の、どの対象の、どの正本なのかが分からなければならない。第四に、復旧手順、判断者、権限、検証方法が残っていなければならない。第五に、復旧後に業務や記事として利用できる整合状態でなければならない。つまり、データ保全とは、単なる保存ではなく、記録層、構造層、意味層、手順層、業務層をまとめて維持する設計である。
この観点から見ると、WordPress の原稿保全問題は小さな個人運用の話に見えて、データ保全の本質をよく表している。WordPress DB は日次 mysqldump によって保存されている。リモートホストからも取得しているため、本番ホスト喪失時にも直近の日次バックアップへ戻す経路はある。しかし、日次バックアップには時間的な空白がある。その空白の間に書いた予約投稿、下書き、公開済み記事の編集、固定ページの変更は、次回バックアップ前に本番 DB が壊れれば失われる。このとき守りたいものは、DB 全体ではなく、日次バックアップ以後に人間が作った本文の意味内容である。
そこで採用したルールは、日次バックアップ以後に WordPress 上で本文を作成または編集した場合、次回の日次バックアップが正常取得されるまで、変更後の HTML 全体を手元に保存するというものである。ファイル名は YYYYMMDD-N.html とする。明日投稿する原稿なら 20260505-1.html、20260505-2.html のようにし、過去記事を編集した場合は対象記事の日付を使って 20260423-1.html のようにする。HTML 内にメタデータコメントは書かない。これは、単純化のためではあるが、雑にするためではない。運用負荷を下げ、保存を継続可能にし、復旧時に本文を迷わず取り出せるようにするためである。
このルールは、完全な WordPress 復旧を目的としていない。投稿 ID、カテゴリー、タグ、予約日時、コメント、カスタムフィールド、画像ファイル本体、プラグイン固有メタデータは、本文 HTML 保存だけでは守れない。そこは日次 DB バックアップ、uploads の保全、設定ファイルの保全、必要に応じた別の手段で扱うべき領域である。重要なのは、HTML 保存が万能であることではない。本文という価値ある意味内容を、WordPress DB というシステム内部状態から切り離し、可搬な形式として保存する点に価値がある。
この考え方は、WordPress に限らない。多くのデータ保全設計が複雑になる理由は、システム状態と意味内容を混同するからである。WordPress DB と記事本文 HTML は違う。GitHub issue と設計判断は違う。Slack や Teams の会話と正式な合意事項は違う[46]。Google Docs の内部状態と文書本文は違う[47]。会計ソフト DB と取引事実・帳票・証憑は違う。システムは意味内容を扱う環境であり、意味内容そのものではない。失ってはいけない価値がどこにあるのかを見極め、それを必要に応じて可搬形式へ外部化することが、データ保全の中心にある。
一方で、すべてを単純なファイル保存に置き換えればよいわけではない。業務システムでは、トランザクション整合性、外部連携、監査証跡、権限、承認履歴、法務要件、セキュリティ要件が価値の一部になる。EC 注文 DB であれば、注文、決済、在庫、配送、メール、会計、DWH が整合していなければ業務復旧とは言えない。会計データであれば、帳票や証憑だけでなく、監査可能性と改ざん耐性が重要になる。監査ログであれば、読めることだけでなく、消されていないこと、改ざんされていないこと、時系列で追えることが価値になる。この領域では、PITR、WAL、binary log、レプリケーション、スナップショット、WORM、Object Lock、マネージドバックアップ、復旧演習が必要になる。
したがって、この記事の結論は「シンプルな方法を選べ」ではない。正確には、「守る対象を分解し、価値の所在を見極め、対象と障害に対して必要十分な複雑性を採用せよ」である。高度な仕組みは悪ではない。MySQL の binary log / PITR、PostgreSQL の WAL / PITR、Oracle の redo log / archive log / RMAN、Snowflake の Time Travel や Fail-safe、クラウドのマネージドバックアップは、それぞれ強力な解決策である。しかし、それらは DB 全体、トランザクション履歴、整合性、業務継続、監査、災害復旧を守るための仕組みである。本文という意味内容を日次バックアップの空白から守るだけなら、HTML 保存のほうが目的に直接合う場合がある。
同期、レプリケーション、バックアップ、アーカイブ、エクスポートの違いも、最終的にはこの判断に接続する。同期は現在状態を揃える。レプリケーションは可用性を高める。バックアップは過去状態へ戻す。アーカイブは長期証跡を残す。エクスポートは意味内容を可搬化する。これらは似ているが、目的が違う。同期をバックアップだと誤解すれば、誤削除やランサムウェアを全環境へ広げる可能性がある。レプリケーションをバックアップだと誤解すれば、壊れた状態を高速に複製する仕組みになる。方式の名前ではなく、どのリスクに効き、どのリスクに効かないかを見る必要がある。
本番業務では、この判断をさらに厳密に行う必要がある。まず業務データを分類する。トランザクションデータ、マスターデータ、コンテンツ、システム設定、監査ログ、一時データでは守り方が違う。次に正本を決める。復旧時に何を信じるのかが曖昧であれば、バックアップが多いほど混乱する。さらに RPO、RTO、RLO を定義する。どこまでのデータ損失を許すのか、どれくらいの時間で戻すのか、どの水準まで戻れば業務再開とみなすのかを決める。これらは技術者だけで決めるものではなく、業務、技術、セキュリティ、法務、監査の合意事項である。
また、障害種別ごとに戦略を分ける必要がある。物理障害にはレプリケーションや遠隔バックアップが効く。論理障害には世代バックアップや PITR が効く。セキュリティ事故には隔離バックアップ、権限分離、WORM、クリーン環境復旧が必要になる。外部依存障害には、自社 DB の復元ではなく縮退運転、キューイング、手動受付、後追い反映、突合が必要になる。データ不整合では、単純な restore ではなく、どのシステムを正本とするかの判断が必要になる。障害種別を見誤ると、復旧手段そのものが被害を広げる。
運用設計では、対象、除外、頻度、保持期間、保存場所、暗号化、鍵管理、アクセス権、削除耐性、監視、復旧手順、検証、訓練、責任者、変更管理を決める必要がある。バックアップジョブが成功していても、暗号鍵がなければ復号できない。復旧権限がなければ戻せない。DNS や証明書や secret が戻らなければサービスは再開できない。復旧手順が古ければ障害時に使えない。復旧演習をしていなければ、バックアップは期待であって保証ではない。
数理モデルで見ても、保全戦略は単純な \(E(S)=W(S)-C(S)-R(S)\) では足りない。戦略 \(S\) は複数の保全層の組み合わせであり、データ種別 \(d_i\)、障害種別 \(h\)、業務機能 \(f\) ごとに評価すべきである。復旧可能性は、取得成功、完全性、復号可能性、運用実行可能性、業務利用可能性の積として見る必要がある。復旧品質は、データ単体の復旧だけでなく、内部整合性、外部連携整合性、監査可能性を含む。さらに、RPO、RTO、RLO、セキュリティ要件、監査要件、最大許容損失は制約条件である。点数が高く見えても、これらを満たさない戦略は本番業務では採用できない。
このモデルから分かるのは、単純さと高度さの関係である。単純な方式は常に正しいわけではない。高度な方式も常に正しいわけではない。単純な方式は、対象が明確で、復旧粒度が小さく、手作業復旧が許容され、意味内容の保全が主目的である場合に強い。高度な方式は、トランザクション整合性、短い RPO / RTO、外部連携、監査証跡、セキュリティ耐性、災害復旧が必要な場合に強い。正しい判断とは、技術の高度さを競うことではなく、対象に対して必要な複雑性を見極めることである。
今回の WordPress ルールは、この大きな原則の小さな実装である。日次 mysqldump はサイト全体の基準復旧点を守る。リモート退避は本番ホスト喪失に備える。HTML 保存は、日次バックアップ以後に人間が作った本文差分を守る。つまり、DB 全体の復旧と、意味内容の保全を分離している。これは簡易策ではなく、対象と価値を分解したうえで、最も低コストで復旧可能性を上げる設計である。
最終的な命題は、次のように整理できる。データ保全とは、失われると再生成できない価値ある情報を特定し、それを将来の自分または組織が、迷わず、読める形で、必要な時点に、必要な粒度で、検証可能に復元できるようにする設計である。そこには、保存形式、正本、世代、隔離、権限、鍵、手順、検証、訓練、業務判断が含まれる。バックアップとは、ファイルを残すことではない。未来の復元可能性を、現在のうちに構造化しておくことである[48]。
この順序を守れば、個人ブログの原稿保全でも、本番業務システムの災害復旧でも、判断の軸はぶれない。最初に問うべきなのは、どの製品を使うかではない。何を失ってはいけないのか。なぜそれが価値を持つのか。どの障害で失われるのか。どの時点へ戻す必要があるのか。戻したものを何で正しいと判断するのか。誰が復旧できるのか。復旧手順は検証されているのか。これらに答えられる設計だけが、実際に使えるバックアップ・リカバリー戦略である。
参考文献
- deferred-sync — Plugin-extensible synchronization software with versioning support for remote systems. https://github.com/id774/deferred-sync
- WordPress.org Documentation, Post Status. https://wordpress.org/documentation/article/post-status/
- WordPress Developer Resources, Posts – REST API Handbook. https://developer.wordpress.org/rest-api/reference/posts/
- WordPress Developer Resources, wp db export – WP-CLI Command. https://developer.wordpress.org/cli/commands/db/export/
- MySQL 8.4 Reference Manual, mysqldump — A Database Backup Program. https://dev.mysql.com/doc/refman/8.4/en/mysqldump.html
- MySQL 8.4 Reference Manual, The Binary Log. https://dev.mysql.com/doc/refman/8.4/en/binary-log.html
- MySQL 8.4 Reference Manual, Point-in-Time Recovery Using Binary Log. https://dev.mysql.com/doc/refman/8.4/en/point-in-time-recovery-binlog.html
- MySQL 8.4 Reference Manual, mysqlbinlog — Utility for Processing Binary Log Files. https://dev.mysql.com/doc/refman/8.4/en/mysqlbinlog.html
- MySQL 8.4 Reference Manual, Point-in-Time Recovery Using Event Positions. https://dev.mysql.com/doc/refman/8.4/en/point-in-time-recovery-positions.html
- MariaDB Documentation, Binary Log. https://mariadb.com/docs/server/server-management/server-monitoring-logs/binary-log
- MariaDB Documentation, Point-In-Time Recovery (PITR, mariadb-backup). https://mariadb.com/docs/server/server-usage/backup-and-restore/mariadb-backup/point-in-time-recovery-pitr-mariadb-backup
- PostgreSQL Documentation, Continuous Archiving and Point-in-Time Recovery (PITR). https://www.postgresql.org/docs/current/continuous-archiving.html
- Oracle Database 19c Backup and Recovery User’s Guide, Performing Flashback and Database Point-in-Time Recovery. https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/rman-performing-flashback-dbpitr.html
- Oracle Database 23ai Backup and Recovery User’s Guide, Performing Complete Database Recovery. https://docs.oracle.com/en/database/oracle/oracle-database/23/bradv/rman-complete-database-recovery.html
- Microsoft Learn, Restore a SQL Server Database to a Point in Time. https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/restore-a-sql-server-database-to-a-point-in-time-full-recovery-model?view=sql-server-ver17
- Microsoft Learn, Transaction log backups (SQL Server). https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/transaction-log-backups-sql-server?view=sql-server-ver17
- Snowflake Documentation, Time Travel and Fail-safe. https://docs.snowflake.com/en/user-guide/data-availability
- Snowflake Documentation, Understanding and viewing Fail-safe. https://docs.snowflake.com/en/user-guide/data-failsafe
- MySQL 8.4 Reference Manual, Replication with Global Transaction Identifiers. https://dev.mysql.com/doc/refman/8.4/en/replication-gtids.html
- MySQL Reference Manual, Replication. https://dev.mysql.com/doc/en/replication.html
- MySQL Reference Manual, Semisynchronous Replication. https://dev.mysql.com/doc/refman/en/replication-semisync.html
- PostgreSQL Documentation, High Availability, Load Balancing, and Replication. https://www.postgresql.org/docs/current/high-availability.html
- PostgreSQL Documentation, Comparison of Different Solutions for High Availability, Load Balancing, and Replication. https://www.postgresql.org/docs/current/different-replication-solutions.html
- Oracle Database 19c Data Guard Concepts and Administration, Introduction to Oracle Data Guard. https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/introduction-to-oracle-data-guard-concepts.html
- Microsoft Learn, What is an Always On availability group? https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server-ver17
- Slack Help Center, Export your workspace data. https://slack.com/help/articles/201658943-Export-your-workspace-data
- Slack Help Center, How to read Slack data exports. https://slack.com/help/articles/220556107-How-to-read-Slack-data-exports
- NIST, SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems. https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final
- NIST, The Cybersecurity Framework (CSF) 2.0. https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
- NIST, SP 800-209: Security Guidelines for Storage Infrastructure. https://csrc.nist.gov/pubs/sp/800/209/final
- id774, AI に自身の文脈を持ち運ぶ（2026-05-04）. https://blog.id774.net/entry/2026/05/04/4675/
- CISA, #StopRansomware Guide. https://media.defense.gov/2023/May/23/2003227891/-1/-1/1/CSI-StopRansomware-Guide.PDF
- CISA, Stop Ransomware. https://www.cisa.gov/stopransomware
- AWS Backup Developer Guide, Continuous backups and point-in-time recovery (PITR). https://docs.aws.amazon.com/aws-backup/latest/devguide/point-in-time-recovery.html
- Google Cloud, Backup and DR Service documentation. https://docs.cloud.google.com/backup-disaster-recovery/docs
- Google Cloud, Perform point-in-time recovery (PITR) for Cloud SQL for MySQL. https://docs.cloud.google.com/sql/docs/mysql/backup-recovery/pitr
- Google Cloud, Perform point-in-time recovery (PITR) for Cloud SQL. https://docs.cloud.google.com/sql/docs/postgres/backup-recovery/pitr
- Microsoft Learn, Azure Backup documentation. https://learn.microsoft.com/ja-jp/azure/backup/backup-overview
- Microsoft Learn, Configure and manage soft delete in Azure Backup. https://learn.microsoft.com/en-us/azure/backup/backup-azure-enhanced-soft-delete-configure-manage
- Microsoft Learn, Concept of Immutable Vault for Azure Backup. https://learn.microsoft.com/en-us/azure/backup/backup-azure-immutable-vault-concept
- AWS Well-Architected Framework, Plan for Disaster Recovery (DR). https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html
- AWS Well-Architected Framework, Use defined recovery strategies to meet the recovery objectives. https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html
- Amazon S3 User Guide, Locking objects with Object Lock. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
- id774, タイタニック号事故から読み解く巨大システム運用の本質（2026-05-02）. https://blog.id774.net/entry/2026/05/02/4656/
- NIST, SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf
- Microsoft Learn, Finding content in Microsoft Teams in eDiscovery. https://learn.microsoft.com/en-us/purview/edisc-search-teams
- Google Account Help, How to download your Google data. https://support.google.com/accounts/answer/3024190
- id774, CVE-2026-31431 について徹底的に考える（2026-05-06）. https://blog.id774.net/entry/2026/05/06/4730/