バックアップは取っているのに戻せない、中小企業が年に一度やっておく復元テスト
はじめに
バックアップの運用で確かめるべきは、取れているかどうかよりも、戻せるかどうかである。
取得の成否は管理画面の表示で確認できるが、戻せることは、実際に戻してみなければ分からない。
本稿は、筆者がシステム開発とDX助言の仕事で考えている実務上の整理であり、統計や調査結果にもとづく主張ではない。
専任のIT担当がいない会社でも、年に一度の復元テストなら始められる。
バックアップが役に立たなくなる四つの場面
バックアップが使えなくなる場面は、大きく四つに分けられる。
一つ目は、取得そのものが止まっている場合である。
ディスクの容量不足や認証情報の期限切れで処理が失敗していても、誰も通知を見ていなければ、失敗は何か月も続きうる。
二つ目は、元のデータと同じ場所に保存している場合である。
同じ機器や同じ事務所内の同じネットワークに置いたコピーは、機器の故障、火災、盗難、ウイルス感染が起きたときに、元のデータと一緒に失われることが多い。
三つ目は、戻すために必要な情報が失われている場合である。
暗号化したバックアップのパスワードを知る担当者が退職していれば、コピーが残っていても中身を取り出せない。
四つ目は、戻す手順が特定の人の頭にしかない場合である。
データが残っていても、どの順番で、どこへ戻すのかを知る人が不在なら、復旧は止まる。
何を、どれだけ早く戻すかを先に決める
復元テストの前に、経営者が決めておくことが二つある。
戻したいデータの範囲と、戻すまでに許せる時間である。
すべてのデータを同じ重さで扱うと、費用も手間も膨らむ。
受注表や顧客名簿のように、止まれば翌日の業務が成り立たないものと、過去の資料のように、数日遅れても困らないものを分けるとよい。
この線引きは技術者でなくても決められる。
業者に任せられるのは戻す作業であり、どのデータが止まると困るのかを判断できるのは、業務を知る自社だけである。
年に一度の復元テストのやり方
手順は小さく始めてかまわない。
まず、重要なデータの中から一つのフォルダか一つのファイルを選ぶ。
次に、バックアップから別の場所(本番とは別のフォルダ)へ戻し、元のデータと内容が一致するかを見る。
このとき、戻すまでにかかった時間を記録する。
最後に、実際にやった手順を文書にまとめ、誰が読んでも同じ操作ができる状態にする。
テストで見つかる問題の多くは、技術的な欠陥ではなく、パスワードの所在や担当者の不在といった運用上の穴である。
見つかった穴は、その場で埋めておく。
本番のデータに上書きして戻すテストは、手順を確認する前にやると新たな事故を招くため、別の場所へ戻す形に限りたい。
バックアップの保管場所をどう分けるか
保管場所は、元のデータと同時に壊れない場所を選ぶ。
具体的には、事務所の外にあるクラウドの保管領域、または別の拠点に置いた外付けの媒体である。
常にネットワークにつながったままの共有フォルダは、元のデータがウイルスに感染したとき、同時に書き換えられる可能性がある。
この理由から、少なくとも一世代は、普段は接続していない場所に置く構成が望ましい。
どの構成が自社に合うかは、データの量と許せる停止時間によって変わる。
クラウドサービスを使っていても確認すること
業務でクラウドのサービスを使っていると、バックアップは提供元が取っているはずだと考えがちである。
しかし、提供元がどこまでのデータを、どれだけの期間、どんな条件で戻してくれるかは、サービスと契約ごとに異なる。
誤って消したデータを利用者の側から戻せる期間が短い場合もある。
自社が使うサービスについて、利用規約や管理画面の説明で、保持期間と復元の可否を一度確認しておきたい。
確認した結果は、社内の文書に記録しておく。
システム開発を発注するときに確かめること
業者にシステムの開発や保守を頼む場合は、バックアップの範囲を契約の段階で書面にしておく。
確かめる点は三つある。
どのデータをどの頻度で取るか、保存先の名義はどちらか、復元の作業は誰が、どのくらいの時間で行うのか、である。
とくに保存先の名義は、取引を終えるときにデータを引き継げるかどうかを左右する。
おわりに
バックアップの価値は、障害が起きた日に戻せるかどうかで決まる。
今年中に、重要なフォルダを一つ選び、別の場所へ戻して、かかった時間を測ってみる。
その記録が、次の年の手順書の最初の一行になる。
この記事はAZALLYが執筆しました。