会社のデータを守る方法を考えるとき、「バックアップを取れば大丈夫」「NASを2台にすれば安心」と一つの対策だけで考えたくなります。
でも、実際に会社のデータが使えなくなる原因は一つではありません。
- HDDやNAS本体の故障
- ファイルの誤削除や上書き
- ランサムウェアなどによる暗号化
- 停電やネットワーク障害
- 水害・火災・地震などの災害
- アカウントや設定の問題
原因が違えば、効く対策も変わります。
この記事では、いきなり製品や機能を選ぶのではなく、
- 何が起きることに備えるか
- 起きたらどのくらい困るか
- どのくらいで業務を再開したいか
- どの時点のデータまで戻れればよいか
- そこにどのくらいのコストと運用負荷をかけられるか
という順番で、会社のデータ保護と業務継続を考えます。
先に結論：対策を決める前に「何が起きると困るか」を整理する
最初に考えたいのは、どの仕組みを導入するかではありません。
自社にとって、どんな事故が起きたときに、どのくらい影響が出るのかです。
たとえば、NASのHDDが1台壊れることと、ランサムウェアで共有フォルダ全体が暗号化されることでは、必要な備えが違います。
同じように、同じ部屋にNASを2台置いていても、水害や火災で部屋ごと使えなくなれば、2台とも失う可能性があります。
まずは「起きやすさ」と「起きたときの影響」をセットで考えてみます。
| 想定すること | 起きたときに困ること | 主に考えたい備え |
|---|---|---|
| HDDが1台故障 | NASが止まる、または冗長性が失われる | RAID、予備HDD、交換手順 |
| NAS本体が故障 | 共有フォルダへアクセスできない | バックアップ、予備NAS、レプリケーション |
| 誤削除・上書き | 必要なファイルが消える | ごみ箱、スナップショット、世代バックアップ |
| ランサムウェア | 多数のファイルが暗号化・破損 | 世代管理、隔離されたバックアップ、復元確認 |
| 停電・瞬停 | NAS停止、データ破損、業務停止 | UPS、安全停止、電源対策 |
| 水害・火災・地震 | 機器や同じ場所のバックアップをまとめて失う | 別拠点、クラウド、3-2-1バックアップ |
| ネットワーク障害 | NASは正常でも社員が使えない | スイッチ・回線・経路の確認、必要に応じた冗長化 |
全部の事故へ同じ強さで備える必要はありません。
発生したときの影響が小さいものに高額な対策を入れるより、会社にとって本当に止まると困る部分から優先した方が現実的です。
「データが残る」と「仕事を続けられる」は別
バックアップがあることはとても重要です。
ただし、バックアップがあるからといって、すぐ仕事を再開できるとは限りません。
たとえばNASが完全に故障し、クラウドに5TBのバックアップが残っていたとします。
データは失っていません。
それでも、業務を元に戻すには、
- 代わりのNASやサーバーを用意する
- 初期設定する
- 共有フォルダを作る
- ユーザーやアクセス権を戻す
- バックアップからデータを復元する
- 各PCから接続できるか確認する
といった作業が必要です。
データを守ることと、業務を再開できる状態に戻すことは、分けて考える必要があります。
ITでは、トラブルが起きてもサービスを使い続けやすい状態を「可用性」と呼びます。
難しい言葉を覚える必要はありませんが、「データは残っている。でも仕事はまだできない」という状態があることは押さえておきたいところです。
次に考えるのは「何時間で戻したいか」
同じ共有フォルダでも、止まったときの影響は会社によって違います。
数時間使えなくても、その間は別の仕事を進められる会社もあります。
一方で、図面、受発注データ、制作データなどを常に共有フォルダから参照していて、使えなくなるとほとんど業務が進まない会社もあります。
そこで考えたいのが、
「障害が起きてから、どのくらいの時間で使える状態へ戻したいか」
です。
| 復旧の目安 | 考えやすい構成 |
|---|---|
| 半日〜1日程度でも対応できる | RAID + バックアップ + 復元手順 |
| 数時間以内に戻したい | 予備NAS + レプリケーション + 切り替え手順 |
| 数分〜短時間の停止も大きな影響がある | HA + 自動フェイルオーバーを検討 |
| オンプレ機器の復旧自体を減らしたい | クラウドストレージも比較する |
高可用性の仕組みは強力ですが、その分、機器代や管理負担も増えます。
停止時間の影響に合わせて、必要なところまで備えるのが現実的です。
「何時間前のデータまでなら戻っても困らないか」も考える
復旧時間とは別に、もう一つ考えたいことがあります。
それは、どの時点のデータまで戻れればよいかです。
たとえば15時に障害が起きたとして、
- 14時59分までのデータが必要
- 正午時点まで戻ればよい
- 昨日の夜のバックアップでも仕事を再開できる
では、必要なバックアップ頻度やレプリケーション方法が変わります。
ITでは、復旧までの目標時間をRTO、どの時点までデータを戻すかをRPOと呼びます。
ただ、最初から用語で考える必要はありません。
「何時間で仕事を戻したい？」
「何時間前のデータまでなら戻っても困らない？」
この2つを決めるだけでも、必要な対策がかなり見えやすくなります。
RAIDはHDD故障への備え。バックアップとは役割が違う
会社のNASではRAIDを使っていることも多いと思います。
RAID1、RAID5、RAID6など、故障に耐えられる構成であれば、対応範囲内のHDD故障では運用を続けられる場合があります。
ただし、RAIDは万能なデータ保護ではありません。
- 誤削除
- 上書き
- ランサムウェアによる暗号化
- NAS本体の故障
- 火災や水害
といった問題には、別の備えが必要です。
RAIDとバックアップの違いは、RAID1とバックアップの違いで詳しく整理しています。
誤削除・上書きには「過去へ戻れる仕組み」が必要
ファイルを間違えて削除した場合、RAIDでは戻せません。
必要なのは、削除前の状態を残しておく仕組みです。
たとえば、
- NAS側のごみ箱
- Windows Serverの「以前のバージョン」
- NASのスナップショット
- 世代を残すバックアップ
などです。
「今と同じデータをもう1台に持っていること」と、「昨日の状態へ戻れること」は別です。
実際に共有フォルダからファイルを削除してしまった場合の確認順は、共有フォルダのファイルを削除してしまった！まず確認したい復元方法で紹介しています。
ランサムウェアを考えるなら、バックアップの置き方も重要
ランサムウェアでは、普段使っている共有フォルダだけでなく、ネットワークから書き込み可能なバックアップまで狙われる可能性があります。
そのため、大切なデータでは「バックアップがあるか」だけでなく、
- 過去の世代が残っているか
- バックアップ先が常に書き換え可能になっていないか
- オフラインや変更しにくいコピーを持てるか
- 実際に復元できるか確認しているか
まで考えます。
すべての会社が高度な仕組みを必要とするわけではありません。
ただ、重要データを同じNAS内だけで守ろうとせず、少なくとも別の場所にもコピーを持つ考え方は重要です。
災害を想定するなら「同じ部屋に2台」だけでは足りない
NASを2台に増やせば、NAS本体故障への備えとしては有効です。
しかし、2台とも同じ部屋、同じ建物にある場合、水害・火災・大きな地震などでは同時に影響を受ける可能性があります。
災害まで想定するなら、
- 別の拠点
- クラウド
- 持ち出し管理されたバックアップ媒体
など、物理的に離れた場所にもコピーを持つことを考えます。
この考え方の基本が3-2-1バックアップです。
詳しくは3-2-1バックアップとは？で整理しています。
数時間以内に戻したいなら、予備NASとレプリケーション
NAS本体が壊れたあと、新しいNASを購入してバックアップから復元する方法では、どうしても時間がかかります。
そこで、停止時間を短くしたい場合は、もう1台のNASへ普段からデータを複製しておく方法があります。
これがレプリケーションです。
ただし、レプリケーションしただけで自動的に業務が再開できるわけではありません。
- IPアドレスや接続先をどう切り替えるか
- 共有フォルダ名や権限をどう合わせるか
- 誰が切り替えを判断するか
- 元のNASが復旧したあと、どう戻すか
まで決めておく必要があります。
そして、レプリケーションはバックアップの代わりではありません。
誤削除や暗号化などの変更が、そのまま予備側へ反映される可能性があるためです。
さらに停止時間を短くしたいならHA・フェイルオーバー
数分〜短時間の停止でも業務への影響が大きい場合は、HA（高可用性）の仕組みを検討することがあります。
代表的なのが、2台のNASをアクティブ／パッシブで動かす構成です。
通常時は、
- アクティブ側：実際に共有サービスを提供
- パッシブ側：データや設定を同期しながら待機
という役割になります。
アクティブ側で障害が起きたとき、パッシブ側へサービスを切り替えるのがフェイルオーバーです。
現在の法人向けNASには、対応する2台でHAクラスタを構成し、自動フェイルオーバーする製品もあります。
ただし、HAは機器を2台買えば終わりではありません。
- 対応機種・構成
- ネットワーク
- 電源
- 監視
- アップデート
- 再同期
- フェイルオーバー確認
まで含めて運用します。
停止時間の影響がそれほど大きくない会社では、ここまでの構成は過剰になることもあります。
NASを守る前に「そもそもNASが必要か」も考える
共有フォルダを守る方法を考えていると、NASをどう二重化するかに意識が集中しがちです。
でも、会社によってはMicrosoft 365のSharePoint・OneDriveやGoogle WorkspaceのGoogle Driveなど、クラウドストレージを中心にした方が運用しやすいこともあります。
たとえば、
- 主にOffice文書やPDFを共有する
- 社外やテレワークから利用することが多い
- NAS本体の交換や保守を担当できる人がいない
- 数TB〜数十TBの高速なローカルアクセスを必要としない
といった場合です。
一方で、
- 大容量データを社内LANで高速に扱う
- 専用機器やアプリがNAS共有を前提にしている
- インターネット障害時も社内で利用したい
といった場合はNASを残す理由があります。
NASかクラウドかを「新しい方が上」と決めるのではなく、自社の使い方で判断します。
最後にコストと「誰が運用するか」を確認する
理想だけを考えれば、対策はいくらでも増やせます。
- RAID
- UPS
- スナップショット
- 別NAS
- レプリケーション
- HA
- クラウドバックアップ
- 別拠点バックアップ
全部あれば強くなりますが、その分コストも運用負担も増えます。
ここでいうコストは、機器代やクラウド料金だけではありません。
- バックアップ結果の確認
- HDD交換
- アップデート
- 障害時の切り替え
- 復元テスト
- 担当者への引き継ぎ
も必要です。
仕組みが高度でも、誰も確認していなければ、いざというときに使えないことがあります。
そのため、対策を決めるときは、
「障害でどのくらい損失が出るか」
「その対策を維持するのにどのくらい掛かるか」
「誰が運用するか」
を一緒に考えます。
会社の規模ではなく、データの重要度で考える
専任のIT管理者がいない会社でも、重要なデータを持っていることはあります。
反対に、会社規模が大きくても、すべての共有フォルダを数分以内に復旧する必要があるとは限りません。
大切なのは会社の大きさではなく、
- そのデータを失ったらどのくらい困るか
- 使えない時間がどのくらい業務へ影響するか
- どの時点までデータを戻す必要があるか
です。
重要なデータから優先順位を付ければ、過剰な構成を避けながら必要な場所へコストを掛けやすくなります。
まずは1枚に書き出してみる
難しい設計書を最初から作る必要はありません。
会社で重要な共有データがあるなら、まず次の5つだけ書き出してみてください。
| 確認したいこと | 例 |
|---|---|
| 何が起きることに備える？ | HDD故障、誤削除、ランサムウェア、水害 |
| 起きたら何が止まる？ | 見積作成、受発注、図面確認 |
| 何時間で戻したい？ | 4時間以内 |
| 何時間前のデータまでなら戻ってもよい？ | 1時間前まで |
| どのくらいのコスト・運用が可能？ | NAS2台まで、月額クラウド費用あり、担当者1名 |
これだけでも、「とりあえずNASを2台にする」より、自社に必要な対策を考えやすくなります。
よくある疑問
RAIDを組んでいればバックアップはいらない？
いいえ。
RAIDは主にHDD故障への備えであり、誤削除、ランサムウェア、NAS本体故障、災害などには別の対策が必要です。
レプリケーションしていればバックアップはいらない？
いいえ。
レプリケーションは別のNASへ早く切り替えるためには有効ですが、削除や暗号化などの変更まで複製される可能性があります。
過去の状態へ戻すためのバックアップやスナップショットは別に考えます。
クラウドにバックアップがあれば災害対策は十分？
データを別の場所へ残す点では有効です。
ただし、災害後にオンプレNASへ戻すなら、復元先の機器、ネットワーク、復元時間も必要です。
クラウド上のファイルをそのまま利用できる構成なら、復旧方法は変わります。
「データが残っていること」と「業務を再開できること」を分けて確認してください。
バックアップがちゃんと動いているか不安
バックアップジョブが成功表示になっているだけではなく、実際にファイルを取り出して確認することが大切です。
確認方法はバックアップがちゃんと取れているか確認する方法で解説しています。
まとめ：一番強い構成ではなく、自社に必要な備えを組み合わせる
会社のデータを守るとき、最初から「NASを2台にする」「全部クラウドへ移す」と決める必要はありません。
まず、
- 何が起きることに備えるか
- 起きたらどのくらい影響があるか
- 何時間で業務を戻したいか
- どの時点のデータまで戻れればよいか
- どのくらいのコストと運用負荷をかけられるか
を整理します。
そのうえで、RAID、スナップショット、バックアップ、別拠点、レプリケーション、HA、クラウドなどを必要な分だけ組み合わせます。
大切なのは、一番高機能な構成を作ることではありません。
トラブルが起きたときに「データを戻せる」「仕事を再開できる」と分かっている状態を作ることです。
