バックアップは「戻せる別のコピー」

バックアップとは、元のデータが壊れたり消えたりしたときに、元へ戻すためのコピーです。元データと別系統で保管してこそ、バックアップとして機能します。同じパソコンの別フォルダへ複製しただけでは、そのパソコンが故障したときに一緒に失われます。

ここで間違えやすいのが、同期との違いです。同期は、複数の端末やクラウド上で同じ最新状態を使うための仕組みです。片方でファイルを削除すると、もう片方からも消える設定があります。破損したファイルや不正に暗号化されたデータが、そのまま同期されることも考えられます。

一方、バックアップには過去の時点へ戻せる世代が必要です。同期先に履歴機能があっても、保存期間や復元条件は設定によって変わります。「クラウドにあるから大丈夫」と考える前に、削除や上書きのあとでも戻せる範囲を確認しましょう。

最低限の設計が必要な理由

データが消える原因は、機器の故障だけではありません。操作ミス、アカウントへの不正アクセス、災害、盗難、ソフトウェアの不具合など、入口はいくつもあります。ランサムウェアに感染すると、業務データだけでなく、常時つないでいる保存先まで使えなくなるおそれがあります。

そのため、一つの機器や一つのアカウントへ全部を預ける設計は避けます。ただし、最初からすべてのデータを完璧に守ろうとすると、分類だけで止まりがちです。先に「失うと仕事が止まるもの」を絞ったほうが、少ない手間で実際の備えを作れます。

最低限の設計で決めるのは、何を守るか、どこへ保存するか、どの頻度で残すか、誰が確認するか、どう戻すかです。製品を選ぶのは、その条件が見えてからで構いません。

守るデータを業務の止まり方から絞る

まず、ファイルの量ではなく、消えたときの影響で分けます。請求や支払いができなくなるデータ、契約内容を確認できなくなる書類、進行中の顧客対応、法令や契約で保存が必要な記録などは優先度が高くなります。

次に、同じ情報を別の場所から取り直せるかを確かめます。公開資料や再ダウンロードできるソフトは、復旧の優先順位を下げられる場合があります。反対に、自社で作った原本、受領後に整理した証拠書類、やり取りの履歴は、失うと再現できないことがあります。

仮定例として、請求・契約・顧客対応の重要データを最優先にし、日次でクラウドへバックアップし、週次で外付け媒体にも保存して作業後は切り離す運用を考えます。完成済みの広報素材は週次、再取得できる資料は対象外というように、影響に応じて差をつけます。これは固定の正解ではなく、対象と頻度を決める考え方の例です。

保存先は3-2-1を基準に分ける

保存先を考えるときは、3-2-1ルールが目安になります。CISAの「Data Backup Options」では、データを3部持ち、2種類の異なる媒体へ保存し、そのうち1部を離れた場所に置く考え方が示されています。元データを含めて3部なので、バックアップは少なくとも2部です。

• 3：業務で使う元データと、バックアップ2部を持つ
• 2：パソコンと外付け媒体など、異なる種類の保存先へ分ける
• 1：災害や盗難の影響が重ならない離れた場所へ1部を置く

クラウドと外付け媒体を組み合わせると、場所と管理方式を分けやすくなります。ただし、二つのクラウドを同じ管理者アカウントだけで操作できる状態では、そのアカウントが奪われたときに両方へ影響が及ぶかもしれません。保存先の数だけでなく、アカウント、権限、接続方法も分けて考えます。

外付け媒体は、バックアップ作業が終わったら切り離します。IPAの「ランサムウェアの脅威と対策」でも、バックアップに使う外付け媒体を常時接続しない対策が示されています。つないだままでは、感染時にバックアップまで暗号化される可能性があるためです。

頻度は更新量と許容できる損失時間で決める

毎日、毎週といった頻度を先に決めるのではなく、「最後のバックアップ以降の何時間分なら、やり直せるか」から考えます。これが許容できる損失時間です。1日分の請求処理を作り直せないなら、週次では足りません。数時間ごと、または日次で残す必要があります。

更新量も一緒に見ます。同じ一日でも、月末に請求書を大量に作る日と、変更がほとんどない日では、失う量が違います。通常は日次でも、締め日や契約更新が集中する日は回数を増やす、といった決め方が現実的です。

頻度を上げるほど保存容量や確認の手間は増えます。そこで、重要度の高いデータは日次、更新の少ない資料は週次というように分けます。全データを同じ頻度にそろえる必要はありません。判断の軸は「何日ごとが普通か」ではなく、消えた分を人の手で戻せる時間と量です。

自動化と権限を運用に組み込む

決めた頻度で続けるには、自動化できる部分を自動化します。毎日決まった時刻に処理し、失敗時に通知が届く設定なら、担当者の忙しさに左右されにくくなります。ただし、自動処理が動いた表示だけを見て安心してはいけません。保存先に新しいファイルがあり、エラーがなく、復元できることまで定期的に確認します。

バックアップ先へ書き込める人は必要な範囲に絞ります。閲覧、追加、削除、設定変更の権限を分けられるなら、普段の利用者が過去データを削除できない構成が望ましいです。管理者アカウントには多要素認証を使い、退職や担当変更があったら権限を見直します。

個人情報や契約情報を外付け媒体へ保存する場合は、媒体やバックアップファイルを暗号化します。暗号化の鍵や復旧コードまで同じ端末だけに置くと、端末故障時に開けません。鍵の保管場所と、アクセスできる責任者も決めておきましょう。

運用記録には、対象、保存先、実行頻度、担当者、代替担当、最終確認日を残します。担当者が休んだだけで確認が止まる仕組みは、非常時にも止まりやすいものです。代替担当が読んで作業できる粒度で、保存先への入り方と連絡先も書きます。

復元テストで「戻せる」を確かめる

バックアップの完了条件は、コピー成功ではなく復元成功です。ファイルが保存先に並んでいても、破損している、権限がない、必要なソフトで開けない、どの版が正しいか分からないということがあります。実際に別の場所へ戻し、開いて内容を確認します。

1. 請求書や契約書など、重要データからテスト対象を一つ選ぶ
2. 元データを上書きしない別フォルダや検証用端末へ復元する
3. ファイルを開き、内容、日付、件数、必要な関連ファイルを確認する
4. かかった時間と詰まった箇所を記録し、手順を直す
5. 担当者とは別の人でも同じ手順をたどれるか確かめる

前述のIPA資料も、バックアップから正常に復元できることの確認を対策として挙げています。テスト日は月次や四半期など、データの重要度に合わせて決め、最終確認日を記録します。大きな設定変更や担当変更のあとも確認するタイミングです。

復元手順には、保存先、必要なアカウント、暗号化の解除方法、戻す順番、復元後の確認先を書きます。担当者だけが頭の中で分かっている手順では、本人が不在のときに使えません。代替担当が迷った場所は、手順書を直すための有益な情報です。

よくある失敗は保存しただけで安心すること

一つ目は、同期フォルダをそのままバックアップだと思うことです。削除や上書きが同期されるなら、過去の正常な状態が残らない場合があります。履歴の保存期間と、管理者による一括削除への備えを確認します。

二つ目は、外付け媒体を常時つないでおくこと。自動でコピーしやすい反面、事故や攻撃の影響も届きやすくなります。接続する時間を決め、終わったら安全に取り外します。

三つ目は、自動化したまま通知を見ないことです。容量不足や認証切れで処理が止まっていても、気づかなければ古いデータしか残りません。失敗通知の宛先と、確認する曜日を決めておきます。

最後は、復元テストを本番の障害まで先送りすることです。非常時に初めて手順を読むと、権限や暗号化の鍵で止まりやすくなります。小さなファイル一つでよいので、平常時に戻してみる。その一回で、保存だけでは見えなかった不足が分かります。

まとめ：重要データ一つから戻せる仕組みを作る

最低限のバックアップ設計は、守る対象を絞り、異なる保存先へ分け、必要な頻度で残すところから始まります。同期は便利ですが、それだけで過去へ戻れるとは限りません。3-2-1を目安に、離れた場所と切り離した保存先を組み合わせます。

運用では、自動化、権限、暗号化、担当者、代替担当、最終確認日まで決めます。そして、コピーができたという表示ではなく、別の場所へ復元して開けたことを完了条件にします。

最初の一歩は、請求・契約・顧客対応のうち、消えると明日の仕事が止まるデータを一つ選ぶことです。そのデータについて、何時間分までなら失っても戻せるかを決め、保存先を二つ用意し、今月中の復元確認日を置きましょう。