IT用語集 2019/08/08

データが消失する原因と対処法～ファイルサーバーのバックアップ～

コラム

業務で使うパソコンやファイルサーバーから、ある日突然データが消え、必要な情報を取り出せなくなる――。できれば避けたい事態ですが、データ消失のリスクは日常業務の中に常に潜んでいます。被害を最小化するには、「なぜ消えるのか」と「消えた直後に何をすべきか」、そして「平時にどう備えるか」をセットで理解しておくことが重要です。

この記事では、データ消失の代表的な原因と、発生時の現実的な対処法（バックアップからの復旧・業者への相談）を整理します。あわせて、ファイルサーバーのバックアップで失敗しやすいポイントや、方式選定の考え方も解説します。

データが消失する原因と対処法

ビジネスで扱っているパソコンや社内のファイルサーバーから、ある日突然データが消失し、重要な情報を取り出せなくなることがあります。データ消失を防ぐ、あるいは消失したデータを復旧するには、原因と正しい対処法を知っておく必要があります。ここでは、データ消失について押さえるべきポイントを整理します。

データが消失する主な原因

データの消失はなぜ起こるのか、原因から見ていきましょう。代表的には次の3つが挙げられます。

人的ミス

人的ミスはデータ消失の原因として非常に多く見られます。不注意で重要なファイルやフォルダを削除してしまった、上書き保存してしまったといったミスは典型例です。操作を誤ってストレージをフォーマットしてしまうケースもあります。

ここで注意したいのは、「削除＝即消失」ではなく、環境によって挙動が異なる点です。例えばWindowsのローカルディスクではごみ箱に入る場合がありますが、ネットワーク共有（SMB）の共有フォルダはごみ箱を経由せず削除される構成も多く、気づいた時点で既に元に戻せないケースがあります。さらに、ファイルサーバー側でスナップショット（過去時点の状態保存）を運用していない場合、復旧手段はバックアップに依存します。

また「バックアップを取っているはず」でも、いざ復旧しようとするとバックアップが想定どおり取得できていないことが発覚する場合があります。例えば、バックアップの実行順序や同期方向を誤り、現行データがバックアップデータに上書き同期されてしまうといった事故も人的ミスに含まれます。

この種の事故は、バックアップと称しつつ実態が「同期（ミラーリング）」になっていると起こりやすいのが特徴です。同期は速くて便利ですが、誤削除・暗号化・破損もそのまま反映されるため、「過去の状態へ戻す」目的には向きません。バックアップ設計では、まずこの違いを明確にする必要があります。

ハードウェアの破損・障害

人的ミスと並んで多い原因が、ハードウェアの破損や障害です。特にハードディスクドライブ（HDD）は論理障害・物理障害のリスクを抱えます。

論理障害の一部は操作ミスなどが引き金になりますが、物理障害は経年劣化、熱、水没、落下・振動などが原因で起こります。不良セクタの増加、磁気ヘッドやメディアの損傷、データ領域の破損などが代表的な症状で、障害が複合すると復旧は難しくなります。

サーバー用途では、複数のHDDをまとめて運用するRAID（レイド）を構成していることも多いでしょう。ただしRAIDは「壊れにくくする仕組み（可用性向上）」であって「バックアップの代わり」ではありません。複数台が同時期に故障したり、故障ディスク交換後のリビルド中に別ディスクで障害が顕在化したりすると、RAIDが崩壊して復旧が困難になる可能性があります。

特に近年の大容量HDDでは、リビルド（再構築）に時間がかかり、再構築中はI/O負荷が上がりやすい点に注意が必要です。結果として「リビルドが終わる前に別ディスクが耐えられない」「潜在不良が顕在化する」といった事故が起こり得ます。RAIDは障害の“発生確率”を下げるというより、障害時の“止まりにくさ”を高めるものだと理解しておくと判断しやすくなります。

ソフトウェアのトラブル

人的ミスやハードウェア障害に次いで多いのが、ソフトウェアに起因するトラブルです。ソフトウェアの不具合でマシンがフリーズし、強制シャットダウン後にファイルが破損して開けなくなるケースが代表例です。

ほかにも、OSやファームウェア更新の失敗、エラー発生時に市販ユーティリティで復旧を試みた結果、状態を悪化させてしまうケースがあります。特にストレージ障害が疑われる状況では、安易な書き込みを伴う操作が被害拡大につながることがあります。

加えて、業務現場で無視できないのがランサムウェアです。これは「データが消える」というより「暗号化されて使えなくなる」被害ですが、業務影響はデータ消失と同等、あるいはそれ以上になり得ます。さらに厄介なのは、暗号化された状態がそのまま同期・レプリケーションに反映されると、バックアップが存在していても復旧可能な世代が短期間で失われる点です。バックアップ設計では、ランサムウェアを“前提条件”として扱うのが現実的です。

データが消失したときの対処法0：最初にやるべきこと（悪化させない）

復旧方法に入る前に、最初の数分でやるべきことを押さえておきます。原因が何であっても、初動を誤ると復旧確率が下がります。

書き込みを止める：誤削除・破損直後に操作を続けると、削除済み領域が上書きされ、復旧が難しくなります。対象端末では新規ファイル作成やアプリ起動を控えます。
状況を切り分ける：消えたのが「ローカルだけ」か「共有フォルダ全体」か、「特定ユーザーだけ」か（権限・マッピングの問題）を確認します。
ランサムウェア兆候の確認：拡張子の変化、復号要求メモ、急に大量のファイル更新が起きていないかを確認し、疑わしければネットワークから隔離します。
ログ・証跡の保全：復旧業者や内部対応に回す場合、いつ・どこで・何が起きたか（操作履歴、アラート、イベントログ、バックアップログ）を残します。

特に物理障害が疑われる場合は、通電・再起動を繰り返すだけで状態が悪化することがあります。「とりあえず何度か再起動してみる」は避け、次の対処へ進みましょう。

データが消失したときの対処法1：バックアップから復旧

対処法として最も現実的で効果が高いのは、バックアップからの復旧です。失うと困るデータは必ずバックアップを取得し、さらに「復旧できる状態で取れているか」を定期的に確認しておく必要があります。

バックアップから復旧する際は、単に「戻す」だけでなく、次の観点で手順を組むと失敗しにくくなります。

復旧対象の粒度：ファイル単位で戻すのか、フォルダ単位か、ボリューム全体か。被害範囲が限定できるほど復旧は速くなります。
復旧先の選定：同じ場所へ上書き復旧するのか、別領域へ復元して差分を確認するのか。誤復旧で二次被害を避けるには「別領域へ復元→確認→切替」が安全です。
世代の選択：いつの時点へ戻すべきか（暗号化や破損が始まった前の世代）を判断します。世代数が少ないと、ここで詰みやすくなります。
復旧時間の見積り：復旧にはネットワーク帯域、ストレージI/O、バックアップ方式（増分の適用数）が直結します。RTO（どれくらいで業務を再開したいか）を意識して進めます。

バックアップ先としては、外付けHDD、光学メディア、テープメディア、クラウド、LAN接続のNASなどが選択肢になります。重要なのは媒体の種類よりも、障害や事故のパターンを想定して「同時に失われない配置」になっているかです。

実務では3-2-1（3つのコピー、2種類の媒体、1つはオフサイト）という考え方がよく使われます。特にランサムウェアを考えると、「オンラインで常時見えているバックアップだけ」では不十分になりやすく、オフライン/隔離（イミュータブルなど）を含めた設計が重要になります。

データが消失したときの対処法2：業者に相談

ハードウェアの物理障害が疑われる場合は、メーカーやデータ復旧業者に相談するのが現実的です。HDDから異音がする、焦げ臭いなどの異臭がする、モーターが回っていないといった症状がある場合は、物理障害の可能性が高いと考えられます。

この場合、市販の復旧ユーティリティを試すことは極力避け、状態を悪化させないことを優先してください。業者に依頼する際は、症状や経緯を具体的に説明し、復旧の見込みを確認しましょう。対応の仕方から、得意領域や技術力の方向性が見えることもあります。例えば、クライアントPCとサーバー（RAID構成など）では復旧の難易度や手順が大きく異なります。

さらに、復旧業者選定では「論理障害に強いのか」「物理障害（クリーンルーム等）に対応できるのか」「RAID/仮想化/暗号化ボリュームに対応できるのか」といった観点で確認すると、ミスマッチを減らせます。業者によって得意領域が分かれるためです。

ただし、メーカーや復旧業者に依頼しても必ずデータが戻るとは限りません。復旧できないケースや、機器のリプレースが必要になるケースもあることは前提として押さえておきましょう。

トラブルに備えて定期的なバックアップの徹底を

バックアップは「確実に行う」だけでなく「定期的に行う」ことが重要です。例えば毎日バックアップを取れていれば、万一データが消失しても前日の状態に戻せる可能性が高まり、被害を小さく抑えられます。

この「どこまで戻れればよいか」を要件として整理したものが、RPO（目標復旧時点：どれだけのデータ損失を許容するか）です。RPOが1日なら日次バックアップで足りる可能性がありますが、RPOが1時間なら日次では不足します。業務要件（締め処理、受注、設計データ、共有ドキュメント等）ごとにRPOは変わるため、データを一括りにせず、重要度で分けて考えるのが現実的です。

そのためには、運用に無理がなく、失敗しにくい仕組みを採用することが重要です。バックアップの自動化、実行結果の監視、復旧テストの定期実施までを含めて、日常業務の一部として回る設計にしておきましょう。

データ消失は思わぬタイミングで発生します。定期的なバックアップを欠かさず、万一のときに復旧できる備えを平時から整えておくことが肝要です。

何に注意すればいい？ファイルサーバーのバックアップ

ファイルサーバーのバックアップは、特に慎重に設計・運用する必要があります。「一応バックアップは取ってある」という状態では、必要なときに完全な復旧ができない可能性があります。ここでは注意点を整理します。

業務を止めないためのバックアップの重要性

ファイルサーバーのバックアップが重要となる理由は、主に次の3つです。

操作ミスや不注意、不慣れなどのヒューマンエラーでファイルが消失する可能性があるため
サーバーやストレージが故障・不具合を起こした場合でも、バックアップから復旧できるようにするため
大規模災害などの緊急事態でも事業を継続するため（事業継続計画：BCPの一要素）

このほかにも、ソフトウェア障害、マルウェア感染、ランサムウェアによる暗号化、不正侵入などのリスクが想定されます。ファイルサーバーへの依存度が高いほど、障害時に業務が停止する影響は大きくなります。

また、ファイルサーバー特有の落とし穴として、権限・共有設定の変更があります。データ自体は残っているのに「見えない」「アクセスできない」状態になり、現場では“消えた”と認識されるケースです。監査ログや変更履歴が追えないと、復旧より先に混乱が長引きやすくなります。バックアップはデータだけでなく、設定・権限の復元も視野に入れる必要があります。

こうした前提に立つと、ファイルサーバーのバックアップは「保険」ではなく「業務継続の設計要件」として扱うべきものだといえます。

さまざまなバックアップ方法

ファイルサーバーのバックアップ方法には、代表的に次のようなものがあります。

テープによるバックアップ

LTOなどの磁気テープを利用したバックアップ方法です。可搬性が高く、社外で保管しやすい点が特徴です。一方で、テープの交換作業が手動になりやすく、ファイル単位のリストアや過去世代の検索では運用上の手間が増える場合があります。

ただし、テープは「オフライン保管」による耐ランサム性を持たせやすいのが強みです。クラウドやNASだけに寄せると、攻撃者がバックアップ領域まで到達するリスクが増えるため、要件次第では依然として有力な選択肢です。

ハードディスクによるバックアップ

外付けハードディスクを使用する方法です。バックアップソフトを使うことで自動化しやすく、NAS（ネットワークHDD）を使ったバックアップも可能です。ただし、サーバーと同じ場所・同じ建物内に置く場合、災害や盗難などで同時に使えなくなるリスクがあります。

また、バックアップ先NASが同一ドメイン/同一権限で運用されていると、ランサムウェアや不正侵入時にバックアップ側も暗号化される事故が起き得ます。バックアップ先は「運用権限の分離」「アクセス経路の制限」「世代の保持」「変更不可（イミュータブル）設定の有無」など、セキュリティ面の設計が重要です。

遠隔地バックアップ

遠隔地にバックアップデータを保管する方法です。従来はテープを物理的に搬送する方式が一般的でしたが、現在は遠隔地にストレージやサーバーを設置し、回線経由でバックアップする方法や、クラウドへバックアップする方法が広く利用されています。

なお、遠隔地や同一ネットワーク内のサーバー、NASなどに更新データをリアルタイムで同期する方法はレプリケーションと呼ばれます。レプリケーションは迅速な切り替えに強みがありますが、誤削除やランサムウェアによる暗号化などもそのまま同期される可能性があり、世代を保持するバックアップとは役割が異なります。

実務では「レプリケーション（可用性）＋バックアップ（復旧性）」の両立が重要です。片方だけでは、いざという時に戻れない、切り替えられない、という穴が残ります。

ファイルサーバーのバックアップにおけるポイント

バックアップ頻度は「どの時点まで戻れれば業務継続できるか」という要件（許容できるデータ損失：RPO）に合わせて決めるべきです。頻繁に更新されるホットデータがある場合は、少なくとも1日1回以上、場合によっては数時間おきのバックアップが必要になることがあります。

また、復旧にかけられる時間（RTO：目標復旧時間）も同時に考える必要があります。たとえバックアップがあっても、復旧に2日かかる設計では「業務が止まらない」要件を満たせません。RPOとRTOはセットで設計し、次のような観点で現実解を探ります。

データ分類：全部を同じ頻度・同じ方式で守らない（重要度別に分ける）
復旧手段：ファイル単位復旧か、ボリューム復旧か、別サーバーへのリストアか
復旧手順の標準化：誰がやっても戻せる手順書・チェックリストを作る

さらに、バックアップは世代管理できることが基本です。最新時点に戻れるだけでなく、数世代前にも戻れることで、例えば感染や破損が発生する前の状態へ復旧できる可能性が高まります。

世代管理では「保持期間（例：日次30世代、週次12世代、月次12世代）」のように階層化すると、容量と復旧性のバランスを取りやすくなります。ランサムウェアの潜伏期間や発覚の遅れを考えると、日次だけでなく週次・月次の保持が効いてきます。

バックアップの注意点（失敗しやすい落とし穴）

バックアップを実行したら、バックアップログを確認し、コピーに失敗したファイルがないかを必ずチェックしましょう。これを怠ると、失敗が放置されたまま次回以降もエラーが引き継がれ、いざというときに「取れていない」状態になりかねません。エラー発生時に通知されるよう、アラート設定も行っておくと安心です。

加えて、ファイルサーバーでは次の落とし穴が頻出します。

開いたままのファイル：業務アプリがロックしているファイルを取り損ねる（VSS等の仕組みがないと失敗しやすい）
アクセス権限・ACL：データは戻ったが権限が戻らず、業務が再開できない
パス長・文字コード：特定ファイルだけバックアップに失敗しているのに気づけない
除外設定の事故：拡張子・フォルダ除外が意図せず広がり、重要データが対象外になる
バックアップ先の容量枯渇：世代が増えるにつれ失敗し、最新世代だけが残らない

さらに、世代管理が想定どおり機能しているか、バックアップデータから任意のファイルやフォルダを取り出して復元できるかも定期的に確認しましょう。バックアップは「取ること」よりも「戻せること」が重要です。

また、バックアップ媒体の保管・管理にも注意が必要です。損傷や紛失、盗難から守ることに加えて、媒体の耐用年数や交換計画も含めて運用設計を行いましょう。

バックアップに時間がかかりすぎる場合の対処法（方式と設計の見直し）

バックアップ方式には、毎回すべてのデータを取得する「完全バックアップ」、初回の完全バックアップ以降に変更・追加されたデータを取得する「差分バックアップ」、前回のバックアップ以降に変更・追加されたデータを取得する「増分バックアップ」があります。

完全バックアップはデータ量が増えるほど時間がかかり、世代分の容量も必要になりますが、復旧時に必要な作業は比較的シンプルになります。

差分バックアップと増分バックアップはバックアップ時間を短縮しやすい方式です。ただし、増分バックアップは復旧時に複数世代を順に適用する必要があり、状況によってはリストアに時間がかかります。差分バックアップは増分バックアップに比べて復旧しやすい一方、差分が積み上がるほどバックアップ時間や必要容量が増える傾向があります。

そのため多くの企業では、完全バックアップと差分バックアップ、増分バックアップを組み合わせて運用します。例えば週次で完全バックアップを行い、日次は差分や増分で取得するといった運用にすることで、時間と安全性のバランスを取りやすくなります。

加えて、バックアップに時間がかかる場合は「方式」だけでなく、次の観点も効きます。