毎月届く保守報告に「バックアップ 正常完了」と書かれている。監視も入っていて、失敗すれば通知が飛ぶ設定になっている。ここまでは多くの会社でできています。
では、そのバックアップから実際に戻せると誰が確認しましたか。 この質問に日付で答えられる会社は多くありません。答えられない状態が続いていること自体は珍しくないのですが、問題はそこが確認されていないことを、経営側が知らないまま「対策済み」に数えていることにあります。
成功通知が示していること
バックアップ処理が正常終了したとき、そこで分かるのは処理が最後まで走ったことだけです。書き出されたものが復元に足りているかどうかは、終了コードには含まれていません。
実際に起きる事故はこの隙間で起きます。
- 対象のディレクトリ指定が古く、半年前に移動したデータが入っていない
- データベースのダンプは取れているが、アプリが参照する添付ファイルは対象外だった
- 暗号化して保存していたが、復号に必要な鍵が同じサーバーの上にしか無かった
- 保存先の容量が尽きて、古い世代から静かに消えていた
いずれも処理としては成功します。失敗していないので、通知も飛びません。
「戻せる」を5段階で測る
復旧できるかどうかは、あるか無いかの二択ではありません。どこまで確かめたかの段階として測るほうが実務に合います。エンジニアのunchox 氏が公開している整理が分かりやすかったので、それを土台に、発注側と委託先の会話で使える形に置き直したものが次の5段階です。
| 段階 | 確かめていること | 手間 |
|---|---|---|
| 1 | 処理が最後まで走った | 自動 |
| 2 | 出力物が存在し、世代とサイズが想定どおり | 自動 |
| 3 | 中身が壊れていない（展開できる・ダンプとして読める） | ほぼ自動 |
| 4 | 別の場所に復元して、システムが起動する | 人が要る |
| 5 | 復元したもので、担当者が業務を回せる | 人と時間が要る |
上に行くほど、確認に人の手が要ります。そして埋まる順番は、この番号の順とは違います。
多くの会社では1と2だけが埋まり、そこで止まります。3以降は「やったほうがいいのは分かっているが、いつやるか決まっていない」まま何年も過ぎます。止まる理由は技術ではなく、誰の仕事か決まっていないことです。
段階4と5の差も見落とされがちです。システムが起動しても、担当者が「これで業務を続けられる」と言えるとは限りません。直近の入力が入っていない、帳票が出せない、外部サービスとの連携が切れている。これらは4では見つからず、5でしか見つかりません。
SaaSに預けたデータは、契約の都合で消える
自社サーバーの話だけではありません。クラウドに置いてあるから安全、という前提は成立しません。
2026年6月、Microsoft が非営利団体向けに提供していた無償ライセンスの制度変更をきっかけに、およそ17万1千の小規模団体が OneDrive のデータを失ったと報じられました。米国の小規模団体 Canopy の担当者は、2025年10月に年間ライセンスを更新し、2026年10月4日まで利用できるという案内をメールで受け取っていたにもかかわらず、2026年6月11日に全データが消えていることに気づいたと伝えられています。
この件の責任の所在は係争中で、ここで断じることはしません。ただ、利用者側の教訓ははっきりしています。
- 無償・割引の枠組みは、事業者の都合で終わる。 終わるときに、データがどう扱われるかは契約に書かれている条件がすべてです。
- 「あと1年使える」という案内は、保存の保証ではない。 案内と実際の処理がずれることは起こり得ます。
- SaaS上のデータは、手元に無い。 自社の管理下にコピーが無ければ、事業者の判断ひとつで到達できなくなります。
Google Workspace や Microsoft 365 に置いたファイルをどう守るかはGoogle Workspaceのデータ保護とバックアップに整理しています。サービス側が終了する前提を契約時にどう織り込むかはサービス終了を前提にした設計にまとめました。退職者アカウントのデータが消える経路についてはアーカイブユーザーとライセンスを参照してください。
委託先に投げる3つの質問
保守を外部に委託している場合、技術の中身を理解しなくても状態を測れる質問があります。次の3つです。
- 「最後に復元を試したのはいつですか。何を復元しましたか。」 日付とファイル名・システム名が返ってくるかを見ます。「定期的に行っています」という答えは、行っていないことのほうが多いと考えて差し支えありません。
- 「いま全部消えたとして、どのくらいで元に戻せますか。その間、失われるデータはどの範囲ですか。」 復旧までの時間と、失う範囲。この2つが数字で返らないなら、設計としてそこが決まっていません。
- 「復元に必要な鍵やパスワードは、復元したい環境とは別の場所にありますか。」 ここが同じ場所にあるケースは、実際にあります。サーバーごと失う事故で初めて発覚します。
この3つに答えが返ってくれば、上の5段階のどこまで埋まっているかがだいたい分かります。答えられないこと自体を責める必要はありません。 多くの場合、契約に含まれていないだけです。含まれていないと分かれば、追加するかどうかを決められます。
段階5まで一度で行こうとしない
「では明日から復旧訓練を」と全社規模で計画すると、たいてい実施されません。人も時間も確保できないためです。
始めるなら、業務データを1つ選んで、それだけを別の場所に戻すところからです。 経理が使っている共有フォルダの1階層でも、業務システムの1テーブルでもかまいません。1回やると、手順書に書かれていない前提が必ず出てきます。鍵がどこにあるか、誰の権限が要るか、どのくらい時間がかかるか。この「出てくること」自体が成果です。
そして、やったことを日付と対象で記録に残してください。 記録が無いと、次に同じ質問をされたときにまた「たぶん大丈夫です」に戻ります。データベースの復旧構成そのものを見直す段階に来ているならDB冗長化と復旧設計が参考になります。
次にやること
まず、直近の保守報告書を開いて、バックアップの項目に「復元を確認した日付」があるかを見てください。 無ければ、それが現在地です。処理の成功だけが報告されている状態は、上の5段階でいう1と2です。
そのうえで、次の定例で「どのデータを、いつ、誰が復元して確かめるか」を1つだけ決めてください。 網羅的な計画より、1件の実施のほうが状態を進めます。
バックアップと復旧の設計、業務システムの保守体制の見直し、クラウド上のデータ保護については、グリームハブの開発・AI・自動化のご相談で承っています。システム構成と扱うデータの性質によって進め方が変わるため、個別にご相談ください。お問い合わせからどうぞ。
