【基本がわかる】Windowsファイルサーバのバックアップ方法と実装の流れ

各業界でIT化やDXが進む中、企業は紙文化から脱却しデジタルシフトを進めています。その中で災害やマルウェア攻撃を想定し、データの機密性、完全性、可用性を高めることがますます重要になっています。

ファイルサーバのバックアップは、企業のデータを守る基本的な手段です。企業はバックアップ管理を個々の従業員に任せるのではなく、組織的な仕組みを構築し、適切に運用する必要があります。

この記事では、ファイルサーバのバックアップについて、手法の種類や実装の流れを解説します。また、陥りやすい失敗事例や、バックアップ管理の課題を解決するおすすめのファイルサーバサービスも紹介します。

ファイルサーババックアップの必要性

企業や団体など、組織において、ファイルサーバのバックアップを行うことは、以下の3つの観点で非常に重要です。

• データセキュリティと企業責任
• 規制遵守と法的要件への対応
• データ復旧計画の策定

データセキュリティと企業責任

組織が事業を進めるには、多くの人がそれぞれの役割を担い、プロジェクトを推進します。営業先リストや顧客情報、アプリケーション開発、プロジェクト管理、そして勤怠・労務管理など、サーバ内で共有されるデータは多岐にわたります。

ヒューマンエラーやソフトウェアの障害、機器の劣化や災害など、さまざまな要因でデータを消失や破損するリスクはゼロではありません。データの消失や破損が発生すると、企業としての利益を損ねるばかりでなく、顧客の信頼を失うことにもつながりかねません。

したがって、データセキュリティの観点から、企業はこうしたリスクを認識し、適切にファイルサーバのバックアップを行うことが重要です。

規制遵守と法的要件への対応

規制遵守や法的要件への対応といった観点でも、ファイルサーババックアップの必要性は今後さらに増していくといえるでしょう。総務省が運営する「国民のためのサイバーセキュリティサイト」において、システム管理者向けの対策として「企業や組織内の情報資産に対する可用性を維持するためには、保有している情報に対する適切なバックアップが必要^[*1]」と言及されています。

データ復旧計画の策定

企業は、自然災害やマルウェア攻撃などの事態を想定し、迅速にデータを復旧して事業を継続するために、適切な災害復旧計画（DRP）を策定することが求められます。また、企業は組織のビジネス継続計画（BCP）を踏まえた上で、事業資産の損害を最小限に抑えるために災害復旧計画（DRP）を策定する必要があります。

BCPを構築する際には、「RPO」「RTO」「RLO」という3つの指標に基づいて、復旧方法やデータの取扱いを検討しましょう。

RPO（目標復旧時点）とは

RPO（Recovery Point Objective）とは、データの破損や消失が発生した際に「過去のどの時点のデータまで復旧させるか」を示す指標です。

例えば、RPOを「1週間」と設定すると、1週間ごとにデータのバックアップが必要になります。RPOをゼロに近づけることで、災害時のデータ損失を最小限に抑えることができますが、その分頻繁にバックアップを行う必要があり、コストも増加します。

例として、金融機関などでは取引金額の正確性が重要視されるため、RPOはゼロに近い設定が求められます。一方、データの正確性がサービス品質や顧客の信頼に直接影響しない業種では、RPOは1～2週間程度で設定されることもあります。

RTO（目標復旧時間）とは

RTO（Recovery Time Objective）とは、システムのダウンやデータの破損・消失が発生してから、事業を再開するまでの時間を示す指標です。言い換えれば、「サービスやシステムの停止・中断が許される時間」を意味します。事業規模や顧客への影響を考慮して、適切な目標を設定する必要があります。

RLO（目標復旧レベル）とは

RLO（Recovery Level Objective）とは、システムが停止してから、いつまでにどのレベルまでシステムを復旧させ、事業を再開するかを示す指標です。「いつまでに」の時間軸は前述のRTOに相当します。平常通りの稼働状態を100%として、設定した時間内（RTO）に何%を復旧させるか、目標を設定します。

以下は、顧客向けのアプリケーションを提供する企業の段階的な目標設定例です。

• 1日以内にアプリケーションの機能を100%復旧する
• 3日以内にユーザーアカウントの50%を利用可能にする
• 5日以内にユーザーアカウントの100%を利用可能にする

バックアップの対象

前述のとおり、有事に備えてファイルサーバのバックアップを行うことは、企業の社会的責任を果たす上で必須です。また、「RPO」「RTO」「RLO」といった明確な指標を用いて、データ復旧計画を策定する必要があります。バックアップには、「システム」を対象とするものと、「データ」を対象とするものの2通りの考え方があります。

システムバックアップ

システムバックアップは、サーバ上で稼働しているOSやアプリケーションなど、システム全体とデータを丸ごとバックアップします。

システムが災害で停止した場合、OSの再インストールやネットワークの再設定が必要となり、簡単に復旧はできません。こうしたケースに備え、遠隔地にシステムのバックアップを用意しておくことで、迅速に事業を再開できます。

システム全体の冗長化を実現できますが、平常時で稼働しているシステムとは別に同じ環境を用意し、同期をとりながら運用する必要があるため、運用コストの増大が課題です。

データバックアップ

データバックアップは、アプリケーションに含まれるデータのみをバックアップする方法です。データの破損や消失など、クライアント単位で発生しやすい問題に対する対策として有効です。

データバックアップはシステムバックアップに比べて企業が取り組みやすい施策ですが、ビジネス継続の観点からはシステムバックアップが理想的です。

バックアップの方法

バックアップには、主に以下の4つの方法があります。

• フルバックアップ
• 差分バックアップ
• 増分バックアップ
• 永久増分バックアップ

それぞれの方法とそのメリット・デメリットについて解説します。

フルバックアップ

フルバックアップとは、全てのデータをその都度バックアップする方法です。4つの方法のなかで最も基本的な手法です。

フルバックアップによるバックアップ方法

メリット

フルバックアップのメリットは、単独のバックアップファイルからデータ全体を迅速かつ完全に復元できることです。シンプルな方法なので運用ルールも簡単です。データ全体をまとめて復元したいニーズに適しています。

デメリット

フルバックアップは毎回全てのデータをバックアップし、そのファイルを蓄積するため、必要なデータ容量が大きくなります。バックアップの回数が増え、保存期間が長くなるほど、ストレージへの負担も増加します。また、バックアップの作成に時間がかかる点にも留意が必要です。

差分バックアップ

差分バックアップとは、前回のフルバックアップ以降に変更があったデータのみをバックアップする方法です。フルバックアップと組み合わせて用いる手法です。

例えば、日曜日にフルバックアップを行い、月曜日から土曜日までは毎日差分バックアップを行います。そして、次の日曜日に最新の状態でフルバックアップを行い、過去のバックアップデータをリセットします。

復元には、フルバックアップファイルと最新の差分バックアップファイルの2つのデータを用います。

差分バックアップによるバックアップ方法

メリット

差分バックアップのメリットは、フルバックアップに比べて2回目以降のバックアップにかかる時間やストレージ容量を削減できる点です。

デメリット

差分バックアップのデメリットは、常にフルバックアップと差分バックアップの2つのデータを管理しなければならない点です。フルバックアップの頻度を少なくすると、その分差分バックアップが増え、ストレージの圧迫や管理コストの増加が課題となります。

増分バックアップ

増分バックアップとは、前回のバックアップから追加や変更があったデータのみを取得するバックアップ方法です。最初にフルバックアップを行い、そこからの変更箇所をバックアップする点では差分バックアップと共通しています。ただし、差分バックアップはフルバックアップからの変更箇所全てを毎回バックアップしますが、増分バックアップは前回のバックアップからの変更箇所のみをバックアップします。

増分バックアップによるバックアップ方法

メリット

増分バックアップのメリットは、差分バックアップに比べてバックアップデータ量を削減でき、ストレージを節約できる点です。また、バックアップの取得時間も短縮できます。世代を複数残してもストレージを圧迫しないため、バックアップの頻度を上げることも可能です。

デメリット

増分バックアップのデメリットは、復元時に複数のバックアップデータが必要になる点です。そのため、復元に手間と時間がかかります。また、複数のバックアップデータのうち一つでも破損していると復元に失敗するリスクが高まります。

永久増分バックアップ

永久増分バックアップとは、最初にフルバックアップを行い、その後は増分バックアップのみを行う方法です。定期的にデータを統合し、新たなフルバックアップを合成して世代を更新します。

永久増分バックアップによるバックアップ方法

メリット

永久増分バックアップのメリットは、フルバックアップを繰り返す必要がなく、毎回のバックアップ時間を短縮できる点です。設定した世代数を超えるとフルバックアップと増分データが自動的に合成されるため、復旧の手間も最小限に抑えられ、ストレージを効率的に使用できます。バックアップソフトウェアやシステムによっては、手動での合成も可能です。

デメリット

永久増分バックアップは、世代管理が簡単でストレージも節約できる一方、データの合成処理に手間や時間がかかる場合もあります。

バックアップの保存先

バックアップの保存先としては、主に以下の2種類があります。

• オンプレミスバックアップ
• クラウドバックアップ

それぞれの特徴を踏まえて、自社に合ったファイルサーバのバックアップ先を検討しましょう。

オンプレミスバックアップ

物理的なサーバを用意し、オンプレミス環境でバックアップを行う方法です。インターネットではなくLANを使用するためネットワーク品質が安定しており、高速なバックアップや復元が期待できます。また、機器の選定やデータセンターの配置場所、ネットワーク構成、セキュリティなど、自社の要件に合わせたオーダーメイド設計が可能です。

一方で、初期費用が高額になることが多く、運用・保守メンテナンスも自社で行う必要があります。そのため、専門知識を持つ人材が必要です。さらに、データ容量が不足した場合のサーバ増設には時間がかかることもあります。

クラウドバックアップ

クラウド上のサーバやストレージでデータのバックアップを管理する方法です。この方法では、自社で物理的なサーバを構築する必要がないため、オンプレミスと比べて初期費用を抑えることができます。また、ストレージの追加も容易で、拡張性にも優れています。

クラウドを提供する事業者がセキュリティ対策を含むハードウェアの運用保守を担うため、システム管理者の負荷も軽減されます。

多くのクラウド事業者は遠隔地に複数のデータセンターを所有しており、クラウドを活用することで、効果的な遠隔地バックアップが可能です。BCP（事業継続計画）の観点からも優れた対策となります。さらに、ユーザーはどこからでもセキュアにアクセスできるため、リモートワークを採用している企業にも適しています。BCPにクラウドを活用するメリットについては「BCPにクラウドを活用するメリットは？事例や注意点を解説」をご覧ください。

クラウドバックアップの場合、ネットワーク品質が懸念されることもありますが、専用線を使用することで安定した通信速度を実現できます。

バックアップの要件定義

これまでの解説で、バックアップの方法や保存先にはさまざまな選択肢があることをご理解いただけたでしょう。ファイルサーバのバックアップは、組織全体を俯瞰し要件を整理した上で適切な手法を選択しなければ、過剰なコストや管理の煩雑さを招くことがあります。

バックアップの運用ルールを構築する際は、以下の4つのステップで要件を定義しましょう。

• 目的と対象の明確化
• 運用体制の確立
• システムの現況確認
• バックアップ要件整理

各ステップでやるべきことを解説します。

目的と対象の明確化

最初のステップは、バックアップ目的と対象を明確にすることです。目的としては、以下が考えられます。

• 災害や停電などの障害対策
• 人的ミスによるデータ損失対策
• マルウェア攻撃時の早期復旧

特に、システム障害やデータの損失が顧客向けのサービスに影響を与える場合、迅速な復旧が求められます。災害対策としては、遠隔地のデータセンターやクラウドによるバックアップが有効です。

マルウェア攻撃や不正アクセスが発生した場合、データの漏えいや改ざんの範囲を調査する必要があります。世代管理されたバックアップは、エビデンスとして原因究明や再発防止にも役立ちます。

バックアップの対象としては、「顧客データ」や「バックオフィスの従業員データ」「提供サービスのデータ」などが挙げられます。全てのデータをバックアップするのが最も安心ですが、データの容量とコストが増加します。システム全体を対象とするか、データのみを対象とするかといった観点も考慮しましょう。

目的と対象を明確にすることで、障害発生時に「いつまでにどのレベルまで復旧すべきか」といった「RPO・RTO・RLO」の指標を具体的に設定できます。

運用体制の確立

バックアップの目的と対象を整理した上で、サーバのバックアップ運用体制を検討します。

仕組みを導入しても、運用体制が整っていなければ、データの適切な管理や迅速な復旧が難しくなります。担当者は定期的にバックアップの取得状況を調査し、正常に動作しているか確認することが重要です。

各担当者の業務状況を考慮し、管理者や技術担当者、運用保守担当者、復旧管理担当者などの作業分担を表にまとめておきましょう。また、復旧が必要になった場合の連絡体制図も用意します。

サーバ保守を業者に委託する場合やクラウドサービスを活用する場合、事業者との対応範囲を明確にしておくことで、スムーズな連携が可能になります。

システムの現況確認

バックアップ対象のシステムについて、現在の使用状況を確認します。ディスク全体の容量に対して使用されているデータ量を把握し、事業計画に基づいた今後の成長予測を行うことで、バックアップに必要なストレージ容量を算出します。

バックアップ要件整理

前述の3つのステップで把握した内容を基に、以下のようにバックアップ要件を具体的に整理します。

ここまで具体化できれば、導入すべき仕組みも絞りこめるはずです。いくつかのサービスを比較検討し、管理のしやすさやコストも踏まえて最適なものを選びましょう。

ファイルサーバのバックアップでよくある7つの失敗例

前項の要件定義が明確でなく曖昧な状態でバックアップを行うとさまざまな失敗に直面します。ここでは、よくある7つの失敗事例とその回避策をご紹介します。

バックアップの頻度や対象範囲が適切に設定されていない

バックアップの頻度が低いと、ファイルの誤削除や破損が発生した際に、最新バージョンがバックアップに含まれていない可能性があります。頻度を低くすればストレージの圧迫を避け、管理の負荷を軽減できますが、最新のファイルを復旧できないと本末転倒です。特に、ビッグデータをリアルタイムで更新する大規模システムでは、データ復旧ができないと被害が大きくなるため、バックアップの頻度を高く設定する必要があります。また、バックアップの対象が不適切な場合、必要なデータがバックアップされておらず、業務やサービスに支障をきたすことがあります。

バックアップストレージの容量が不足している

バックアップストレージの空き容量が不足すると、新しいバックアップデータを保存できない問題が発生します。ストレージ容量不足を避けるために、バックアップの対象や頻度を制限する方法もありますが、これは「保護されるべきデータのバックアップが存在しない」や「最新バージョンのファイルがバックアップに含まれていない」といった別の問題を引き起こすリスクがあります。本質的な解決策としては、ストレージの容量の拡張や、差分バックアップや永久増分バックアップの導入など、ストレージを効率的に使用する方法を検討する必要があります。

バックアップスケジュールを適切に設定できていない

バックアップのスケジュールが適切でない場合、さまざまな問題が発生します。例えば、スケジュールが重複していると同じデータが複数回バックアップされ、ストレージ容量を浪費し、処理速度も低下します。また、復元時にどちらのデータを使用するべきか判断が難しくなり、検証が必要になることもあります。システムの使用状況やバックアップの所要時間を考慮して、適切なバックアップスケジュールを設定し、予定通りにバックアップが実行されているかを定期的に確認しましょう。また、バックアップ失敗時の通知方法も検討が必要です。

正常に復元できない

復元作業の手順や範囲、連絡系統を担当者が把握していないと、復旧に時間がかかり、サービス停止の長期化につながることがあります。解決策として、定期的に復元のテストを行うことが重要です。停電や災害などのトラブルは突然発生します。バックアップの仕組みを整えても、復元時の失敗や、焦って二次災害を引き起こす可能性があります。復元手順をマニュアル化し、定期的にテストを行うことで、運用上の問題点を発見し、改善することが理想的です。

バックアップ中にネットワークやシステムのパフォーマンスが低下する

業務時間中にバックアップを行うと、ネットワーク帯域を占有し、他の業務のパフォーマンス低下につながる可能性があります。これを避けるために、システムやネットワークの稼働率が低い時間帯や曜日にバックアップを行いましょう。クラウドの場合は、AWS Direct Connectなどの専用線接続を利用する方法も有効です。

リソースやストレージ容量を過剰に消費する

頻繁なバックアップにより、CPUやメモリ、ネットワーク帯域などのリソースが過剰に消費されることがあります。バックアップの頻度やデータ量が多い場合は、ストレージ容量に合わせた最適なバックアップ頻度や方法を検討しましょう。

大容量ファイルのバックアップを保存できない

バックアップサーバの仕様によっては、1ファイルあたりの容量に制限があり、それを超えるファイルをバックアップできないことがあります。バックアップサービスを選定する際は、ファイルの容量制限に関する仕様も確認することをおすすめします。

バックアップ管理の課題を解決するWindowsファイルサーバ

ここまで、ファイルサーバのバックアップの重要性や方法、導入の流れなどについて解説しました。ファイルサーバを選定する際は、データの使用状況を考慮し、自社のバックアップ要件を満たすサービスを選ぶことが重要です。

i-TECファイルサーバは遠隔地バックアップ、世代管理、ユーザーによるファイル復元が可能なクラウド型のWindowsファイルサーバです。オンプレミスからシームレスに移行でき、ハードウェアの運用管理や24時間障害対応といった保守業務は提供事業者であるアイテック阪急阪神が担当します。日常の運用管理や緊急時の障害対応、サーバのリプレイス、データ容量の増設などの負担を大幅に軽減できます。また、1日1回、大阪のデータセンターから東京のデータセンターにバックアップを保存する遠隔地バックアップを標準で提供しています。

バックアップ業務の負荷軽減や遠隔地バックアップの実現を検討している方は、以下のサービス資料をご参照ください。

関連資料をダウンロード

出典

• [*1]総務省 「国民のためのサイバーセキュリティサイト」