「やっているつもり」のバックアップが一番危ない
NASや社内サーバーのバックアップを設定すると、ひとまず安心したくなります。毎晩決まった時刻に処理が走るようにしている。別の保存先も用意している。管理画面にはバックアップの設定が残っている。こうした状態なら、「何かあっても戻せる」と考えるのは自然です。
しかし、バックアップで本当に必要なのは、データをコピーする設定そのものではありません。必要なときに、必要なデータを復元できることです。
ここには大きな差があります。設定は残っていても、処理が途中で失敗しているかもしれません。保存先に問題が起きているかもしれません。コピーは作れていても、実際に戻す手順を誰も確認していないかもしれません。障害や誤操作が起きて初めて、「バックアップはあったが復元できない」と分かる状態では、備えとして十分とはいえません。
特に中小企業では、NASやサーバーの管理を専任者ではなく、総務や情シスを兼任する担当者が見ていることもあります。その場合、重要なのは高度な仕組みを増やすことではなく、「失敗しても気づける」「実際に戻せることを確認する」という運用を作ることです。
2021年の調査ではバックアップジョブの37%、復元の34%が失敗
Veeamが2021年に実施した、IT意思決定者約3,000人を対象とする調査では、バックアップジョブの37%が失敗し、復元の34%が失敗していました。
つまり、バックアップ処理を実行したからといって、必ず成功しているわけではありません。また、バックアップデータが存在していても、復元まで問題なく完了するとは限りません。
ここで注意したいのは、この数字がNASだけを対象にした統計ではないことです。バックアップ全般についての調査結果であり、「NASのバックアップの37%が失敗する」という意味ではありません。
それでも、この調査が示している点は重要です。バックアップは、設定した時点で完了する仕事ではありません。処理が成功しているか、さらに復元できるかまで確認しなければ、実際の備えになっているか判断できないということです。
なぜバックアップの失敗に気づけないのか——4つの思い込み
1. 失敗通知は出ているが、誰も見ていない
バックアップ処理が失敗したときに通知する設定があっても、その通知を誰が確認するのか決まっていなければ、異常は放置されます。
「通知メールを送る設定にしている」ことと、「失敗を担当者が把握して対応できる」ことは別です。通知先が使われているか、担当者が確認しているか、失敗が出たときに誰が対応するのかまで決めて、初めて通知が機能します。
バックアップの失敗を防ぐ以前に、まず失敗を見逃さない仕組みが必要です。
2. 復元テストを一度もしていない
バックアップの成否は、最終的には復元してみるまで分かりません。
管理画面に「成功」と表示されていても、実際に必要なファイルを戻せるかどうかは別の確認です。どの保存先から、どの手順で、どこまで戻せるのか。担当者がその手順を実行できるのか。これは実際に復元テストをしなければ確かめられません。
「バックアップデータがある」と「業務を復旧できる」は同じではありません。定期的な復元テストは、その間を埋める確認作業です。
3. 「RAIDがあるから大丈夫」と考えている
RAIDは、複数のディスクを組み合わせ、ディスク故障に備える仕組みです。NASで使われることもありますが、バックアップとは役割が違います。
たとえば、利用者が必要なファイルを誤って削除した場合、RAIDは削除前のファイルを別に保存してくれる仕組みではありません。ランサムウェアによって共有フォルダ内のファイルが暗号化された場合も、RAIDだけでは暗号化前の状態には戻せません。
RAIDは機器内のディスク故障に対する備えであり、誤削除や暗号化からデータを戻すためのバックアップの代わりにはなりません。NAS自体の安全な使い方はNASの外部アクセスを安全にする記事でも整理しています。
4. 「クラウドに同期しているから大丈夫」と考えている
同期型のクラウド共有も、バックアップと同じものではありません。
同期は、複数の場所で同じ状態を保つための仕組みです。そのため、誤ってファイルを削除した場合、その削除が同期先にも反映されることがあります。ランサムウェアによってファイルが暗号化された場合も、暗号化後の状態が同期されることがあります。
必要なのは「現在の状態をもう一か所に持つこと」だけではありません。誤削除や暗号化が起きる前の状態へ戻れることです。
失敗しにくいバックアップ設計の基本は「3-2-1」
バックアップ設計を見直すときの基本として使えるのが「3-2-1ルール」です。米国のセキュリティ機関CISAも公開資料で紹介している考え方で、重要なデータについて次の状態を作ります。
- データのコピーを3つ持つ
- 2種類の媒体に保存する
- 1つは別の場所に置く
一つのNASや一つの保存先だけに依存すると、その場所で問題が起きたときにバックアップまで同時に使えなくなる可能性があります。保存先や置き場所を分けるのは、同じ原因でまとめて失う状態を避けるためです。
世代管理で「壊れる前」に戻れるようにする
さらに重要なのが世代管理です。世代管理とは、最新状態だけを残すのではなく、過去の時点のデータも一定の範囲で残しておく考え方です。
ランサムウェアの被害では、共有フォルダ単位でファイルがまとめて暗号化・削除されることがあります（→ 中小企業のランサムウェア対策）。このとき、バックアップ先まで常に最新状態へ上書きされる構成では、暗号化や削除後の状態しか残らない可能性があります。
そのため、バックアップは「コピーがあるか」だけでなく、「暗号化や削除の前の状態に戻れるか」を確認する必要があります。
1つは普段の経路から切り離す
もう一つ意識したいのが、バックアップのうち1つを普段の利用経路から切り離しておくことです。
日常的に利用している環境とバックアップ先が常につながり、同じ経路から操作できる状態では、障害や不正な操作の影響がバックアップ側にも及ぶ可能性があります。すべてを同じ経路に置かず、少なくとも1つは切り離した状態を作ることで、同時に失うリスクを下げられます。
3-2-1ルール、世代管理、普段の経路からの切り離しは、それぞれ役割が異なります。複数のコピーを持つだけでなく、同じ事故でまとめて使えなくならないように設計することが重要です。
バックアップは設計よりも「運用できているか」で決まる
仕組みを整えても、その後に確認しなければ再び「設定してあるから大丈夫」に戻ってしまいます。バックアップは一度作って終わる設定ではなく、継続的に状態を確かめる運用です。
定期的に復元テストを行う
実際にファイルを復元し、必要なデータが戻ることを確認します。目的は作業手順を覚えることだけではありません。バックアップデータが利用できること、復元の手順が成立していることを確認するためです。
障害が起きた当日に初めて復元操作を試すのではなく、平常時に一度でも実行しておけば、「何を、どこから、どう戻すのか」を具体的に確認できます。
失敗通知を見る担当を決める
通知は、受信するだけでは意味がありません。誰が確認するのかを明確にし、失敗が出たときに放置されない状態を作ります。
担当者が変わった場合にも通知先や確認方法を引き継げるようにしておくと、「以前の担当者にだけ通知が届いていた」といった状態を避けやすくなります。
バックアップ対象を年に一度見直す
業務で使うデータは変わります。新しい共有フォルダや保存場所が増えても、バックアップ設定が以前のままなら、必要なデータが対象から漏れている可能性があります。
年に一度は、「現在重要なデータはどこにあるか」「その保存場所はバックアップ対象に入っているか」を見直します。設定そのものだけでなく、業務側の変化と照らし合わせることが重要です。
まとめ——復元できると確認できて初めてバックアップ
バックアップの基準は、「設定してあるか」ではなく「必要なときに復元できるか」です。
2021年のVeeam調査では、バックアップジョブの37%が失敗し、復元の34%が失敗していました。NAS限定の数字ではありませんが、バックアップは実行と復元の両方を確認する必要があることを示す材料になります。
自社のNASやサーバーを点検するなら、まず次を確認してください。
- バックアップの失敗通知を誰が確認しているか
- 実際に復元テストをしたことがあるか
- RAIDや同期をバックアップの代わりにしていないか
- 3つのコピー、2種類の媒体、1つは別の場所という3-2-1ルールを満たしているか
- 暗号化や誤削除の前に戻れる世代管理があるか
- 少なくとも1つのバックアップが普段の経路から切り離されているか
- 現在の重要データがすべてバックアップ対象に入っているか
「バックアップを取っている」ではなく、「復元できると確認できている」。この状態を運用の基準にすることが、バックアップ失敗を見逃さないための出発点です。
あわせて、バックアップと外部からの安全な利用は別の備えです。NASを社外から使う場合の危険と点検項目はNASの外部アクセスで何が起きるかを解説した記事で確認できます。自社の構成に合わせた考え方は、お問い合わせで個別にご相談いただけます。