バックアップと復旧設計の実務｜RPO/RTOと誤操作復旧で運用事故を最小化する

「データが消えた」ときに、復旧できるかどうかで業務システムの信頼性は決まります。
多くの事故は、サーバ障害よりも誤操作（誤削除・誤更新）です。担当者が良かれと思って直した結果、履歴が壊れて戻せない――これが最も痛いパターンです。
本記事では、RPO/RTOの考え方から、誤操作復旧を前提にしたデータ設計（ソフトデリート、履歴、監査ログ）まで、実務で壊れない復旧設計を整理します。

1. まず決める：RPO/RTOは“業務の痛み”で決める

RPO/RTOはIT用語として決めると形骸化します。業務側の痛みで決める方が正確です。

• RPO：最大でどこまでのデータ損失を許容できるか（例：15分、1時間、1日）
• RTO：復旧までに許容できる停止時間（例：2時間、当日中、翌営業日）

例えば、納品予約や入出庫のように現場が止まる領域（物流向け）はRTOが短くなりがちです。
一方、問い合わせ管理でも「今日の対応」が止まると損失が出るので、最低限“当日復旧”を目標にしておくと現実的です。

2. 誤操作復旧が本番：ソフトデリートと履歴が要る

誤削除を“バックアップから戻す”運用は、現場ではほぼ回りません。復旧範囲が大きく、他の更新が巻き戻るからです。
そこで、実務では次の型が基本です。

この考え方は、権限設計（削除権限を分離する）と監査ログ（追記ログで説明責任に耐える）の両方と整合させると、運用事故が減ります。

3. “復旧しやすいデータ”にする：IDと参照整合を壊さない

復旧で詰まるのは、参照関係が壊れているときです。
例えば、問い合わせ本体を復元できても、添付ファイルや担当割当が参照切れになっていると、現場は復旧した扱いにできません。

• 主キー（ID）を変更しない（復旧で別IDになると紐づきが壊れる）
• 関連データ（タグ、担当、ステータス履歴、添付）を同時に復旧できる
• “削除済み一覧”が見える（復元対象が探せる）

問い合わせ管理なら、保存ビューやフィルタ（運用向けフィルタ設計）と同様に「復旧ビュー」を持つと、運用の属人化が減ります。

4. バックアップの粒度：フル/差分だけでなく“論理バックアップ”も用意する

インフラ側のバックアップ（フル/差分）だけだと、誤更新の一点復旧が難しいことがあります。
そこで、業務システム側で「論理バックアップ」（CSV出力やスナップショット）を用意すると復旧が早くなります。

• 重要マスタ（料金、商品、拠点、担当）の定期スナップショット
• 当日分の取引データ（問い合わせ、予約、見積）の差分エクスポート

マスタ運用が絡む場合は、マスタ運用の責任分界とセットで「どれをバックアップ対象にするか」を決めると、無駄が減ります。

5. 復旧手順：誰が判断して、誰が実行するかを決める

復旧は、技術よりも意思決定が詰まりがちです。
「巻き戻す？」「どの時点？」「顧客に連絡は？」が決まらないと復旧できません。最低限、次を決めてください。

• 判断者：巻き戻し判断を誰がするか（責任者）
• 実行者：復旧操作の実行権限（むやみに配らない）
• 連絡：顧客影響がある場合の連絡テンプレ（一次連絡だけでも）

ここはエスカレーション設計（SLA・期限・通知）と同じで、事前に決めていないと事故時に止まります。

業種別に“復旧設計が刺さる”場面（例）

自動車販売・整備・タイヤショップ

予約枠や入庫予定を誤って消すと、当日現場が崩れます。工程が長い業務は、履歴と復元が必須です。業務像は 自動車販売・整備・タイヤショップ向け を前提に、ソフトデリート＋復元ビューを先に用意すると運用が安定します。

ホテル（団体・宴会）

仮押さえや日程調整の履歴が重要で、巻き戻しより“差分復旧”が求められます。問い合わせ/見積の運用像は ホテル向け を前提にすると、履歴の粒度を決めやすいです。

まとめ

バックアップは「ある」だけでは足りず、「誤操作から早く戻せる」形にして初めて実務で効きます。
RPO/RTOを業務の痛みで決め、削除はソフトデリート、重要更新は履歴、操作は監査ログで追えるようにする。復旧ビューと復旧手順まで決めておけば、事故は小さく収束します。インテンスでも、運用開始後の手戻りを減らすために、この設計を最初から組み込む方が結果的に安くなります。