バックアップはどのくらいの頻度で行うべきか？

これで、組織に必要なデータ保護要件を理解し、それを実現するための手段も整いました。次に行うべきことは、バックアップスケジュールを設計することです。バックアップ対象のデータ量がごく少ない、あるいは十分な予算を確保できる場合を除き、通常は複数のスケジュールを組み合わせて運用します。

バックアップスケジュールを設計する際は、次の3つの要素を基準に検討します。

• データの重要度
• データの更新頻度
• バックアップアプリケーションの機能

データの重要度がバックアップスケジュールに与える影響

フルバックアップの実施頻度は、時間の経過とともに保持されるバックアップコピー数に影響します。同じデータのコピーが多いほど、災害や障害が発生した場合でも少なくとも1つのコピーが残る可能性は高くなります。そのため、絶対に失うことのできない重要なデータについては、その重要性を反映したバックアップスケジュールを設計する必要があります。

データの更新頻度がバックアップスケジュールに与える影響

頻繁に更新されるデータは、それに見合った頻度でバックアップする必要があります。RPO（Recovery Point Objective：目標復旧時点）はバックアップ間隔の上限を定義し、障害発生時に失われても許容できる最新データ量を決定します。しかし、RTO（Recovery Time Objective：目標復旧時間）だけではなく、データ自体がどの程度の頻度で更新されるかも考慮しなければなりません。

更新頻度が低いデータであれば、RPOを長めに設定することも可能です。例えば、数か月に一度しか変更しないデータであれば、毎週バックアップを取得する必要はないかもしれません。しかし、その判断には思わぬ落とし穴があります。

例えば、人事異動がほとんどなく、PCの入れ替えも年間数台程度しかないため、ドメインコントローラーを毎月1回だけバックアップするスケジュールにしたとします。ところが、バックアップの翌日に新しい社員を採用し、新しいPCをセットアップしました。

その月の間にActive Directoryで障害が発生すると、新しく追加したユーザーやコンピューターの情報はすべて失われてしまいます。このようなケースも想定したうえで、バックアップスケジュールを設計する必要があります。

バックアップアプリケーションの機能がスケジュールに与える影響

現在の商用バックアップソフトウェアは、多くの機能を共通して備えています。いずれもジョブのスケジュール機能を備え、バックアップを効率化するさまざまな最適化機能を提供しています。利用する製品の機能によって、最適なバックアップスケジュールは変わります。

以下は、バックアップソフトウェアの機能を活用する際に検討すべきポイントです。

​仮想マシン対応

バックアップソフトウェアが仮想マシンを適切に認識してバックアップできる場合は、効率的な処理順序をソフトウェアに任せることができます。対応していない場合は、ゲストOSのバックアップジョブがシステムリソースを圧迫しないよう、手動でスケジュールを調整する必要があります。

容量節約機能

ストレージ容量を節約できる機能には大きなメリットがあります。ただし、すべての機能にはメリット、デメリットが存在するため、容量を節約する代わりに何を犠牲にするのかを理解しておくことが重要です。

代表的な考慮事項は次のとおりです。

• 従来型の差分バックアップおよび増分バックアップは、その前提となるフルバックアップよりも短時間で完了します。ただし、元となるフルバックアップがなければ意味を持ちません。時間と容量が許す限り、フルバックアップを組み込めるようスケジュールを設計してください。
• より新しいデルタ方式や重複排除技術は、差分・増分ジョブ以上に容量を節約できますが、必要となるフルバックアップに加えて、計算処理と変更の追跡が必要になります。CPU時間を大きく消費することはないはずですが、実際に検証しておく必要があります。また、ご利用のアプリケーションが変更を追跡するかどうか、また追跡する場合はその方式も確認してください。製品によっては、稼働中のディスク上の容量を消費するものもあります。
• ストレージメディアに容量の余裕がある場合は、これらの技術に過度に依存しないでください。可能であれば、フルバックアップの取得回数を増やすことをおすすめします。

時間短縮につながる機能

前項で挙げた機能の多くは、容量だけでなく時間の節約にもつながります。容量の場合と同様に、必要のない時間短縮を無理に追い求めないでください。

レプリケーション

レプリケーション機能には帯域幅が必要であり、インターネット回線を経由する場合には深刻なボトルネックとなることがあります。次のジョブが開始される前にレプリケーションジョブが完了しない場合、使用できないバックアップが生成されてしまうおそれがあります。

メディアの種類

バックアップメディアは種類によって性能が大きく異なるため、選択するメディアによって、バックアップのスケジュール設計や利用すべき容量削減機能が決まります。たとえば、数テラバイトのデータをテープにバックアップする必要があり、フルバックアップに12時間かかる場合、12時間を確保できるときにしかフルバックアップを実行できません。

スナップショット機能

バックアップアプリケーションがVSS（ボリューム シャドウ コピー サービス：Windowsオペレーティングシステムの機能）と連携している場合、あるいはクラッシュ整合性またはアプリケーション整合性のあるバックアップを取得する別の手法を用いている場合、スケジュール設計の選択肢が広がります。

バックアップはシステムリソースを消費するため、あるジョブが別のジョブと競合することは避けたいものですが、スナップショットを利用すれば、システムの稼働中でもバックアップを実行できます。

導入フェーズを通じて、お使いのバックアップ製品について十分に理解が深まっているはずです。時間をかけて、その製品の動作を完全に把握してください。また、定期的なフルバックアップが必要であることも忘れないようにしましょう。

​実践に移す

毎回フルバックアップを取得していては、現実的な時間とメディア容量をたちまち超えてしまうため、妥協が必要になります。ただし、可能であれば全データの完全なバックアップを1日1回以上取得するのが理想である、という点は忘れないでください。

バックアップスケジュール設計のガイドライン：

• フルバックアップには、処理を中断しないスナップショット技術を用いる場合であっても、時間とリソースが必要です。稼働の少ない時間帯に実行できるようスケジュールしてください。
• フルバックアップは他のバックアップに依存しません。そのため、大きな変更が発生した直後に取得すると、最も高い価値を発揮します。たとえば、複雑な月次締め処理を行う組織もあります。その直後にバックアップを取得しておけば、復元が必要になった際に大幅な時間短縮につながります。
• 増分・差分・デルタ・重複排除の各バックアップは、フルバックアップと比べて必要な時間と容量が比較的少なくて済みますが、他のバックアップに依存します。フルバックアップの間を埋める手段として活用してください。
• バックアップ方式が主にオンラインストレージを利用している場合は、オフラインメディアへのバックアップも必ずスケジュールに組み込んでください。それが手作業による運用となる場合は、実施を確実にするための責任体制を整備してください。
• 管理者は夜間にバックアップを実行しがちですが、同様にシステムやソフトウェアの更新も夜間にスケジュールする傾向があります。スケジュールが重複しないよう注意してください。

祖父・父・息子（GFS）方式のサンプルプラン

データを3代にわたってバックアップする「祖父・父・子（Grandfather-Father-Son：GFS）」方式は非常に一般的です。テープなど、ローテーションして使用するメディアに最も適しています。典型的なスケジュール例は次のとおりです。

• 「祖父」：月に1回実施するフルバックアップ
  祖父メディアは年単位でローテーションします（2020年1月のテープに2021年1月のバックアップを上書きし、2020年2月のテープには2021年2月のデータを上書きする、など）。年に1本の「祖父」メディア（通常は組織の会計年度末の直後に取得したもの）は、データ保持ポリシーに従い、一切上書きしません。
• 「父」：週に1回実施するフルバックアップ
  「父」メディアは月単位でローテーションします（つまり「第1週」用のテープ、「第2週」用のテープ、というように用意します）。
• 「息子」：毎日実施する増分バックアップまたは差分バックアップ
  そのメディアは週単位で上書きします（つまり「月曜日」用のテープ、「火曜日」用のテープ、というように用意します）。

上記の例は、GFS方式の唯一の形というわけではありません。GFS方式であるかどうかを決めるのは、ローテーションを構成する各要素の関係性です。すなわち、非常に長期間保管するフルバックアップのメディア一式、それより保管期間の短いフルバックアップのメディア一式、そして短い周期でローテーションするメディアがある、という構成です。

実装によっては、年次メディアを保管しない場合もあります。また、月次のフルバックアップをローテーションせず、フルバックアップの保持期間が満了するまで保管し続けるケースもあります。日次メディアを毎週ローテーションしない場合もあります。どのような運用にするかは、組織のニーズと予算によって決まります。

GFS方式であれば、完全復元までに必要なメディアは常に数本程度で済みます。ここで注意したいのは、「差分」方式のバックアップでは最新の「子」メディアと、その直前の「父」メディアが必要になるのに対し、「増分」方式のバックアップでは最新の「父」メディアと、それに紐づくすべての「子」メディアが必要になるという点です。

GFS方式の難点は、日次バックアップの細かな粒度が早期に失われてしまうことです。日次メディアをローテーションしてしまうと、上書きされたデータは、残っていたとしても直近の月次バックアップ、あるいは年次バックアップの中にしか存在しません。

オンラインメディアのサンプルプラン

バックアップソリューションが主にオンラインメディアを利用している場合、伝統的なGFS方式はうまく機能しない可能性があります。常時オンラインのシステムの多くは、GFSと同じ「ローテーション」という考え方を持ちません。その代わりに、設定された保持ポリシーの期限に達した時点で、古いデータを順次消去していきます。

このような環境での設定は、バックアップ製品がデータをどのように保存するかによって変わります。重複排除方式を採用し、フルバックアップを1世代のみ保持する仕組みであれば、バックアップの実行頻度と保持ポリシーを設定する以外に、ほとんど行うことはありません。

継続的バックアップのサンプルプラン

多くのアプリケーションには、何らかの形で「継続的」バックアップ機能が備わっています。これは、極めて短い時間間隔でデータを取得するものです。たとえば、HornetsecurityのVM Backupには「継続的データ保護（CDP：Continuous Data Protection）」機能があり、最短5分間隔でスケジュールを設定できます。

この種のバックアップのスケジュール設計では、次の3点を考慮する必要があります。

• バックアップアプリケーションは、「継続的」バックアップのデータをどのように保存するのか
• 保護対象データはどれくらいの速さで変化するのか
• 対象とする時間枠の中で、保護対象データはどの程度変化するのか

バックアップ製品が各インターバルごとに独立したフルコピーを取得する方式であれば、メディアの容量はきわめて短期間で枯渇するおそれがあります。重複排除型の保存方式であれば、消費量は大幅に少なくなるはずです。いずれの場合も、必要となる容量はデータの変化率（チャーンレート）によって決まります。

変化率が非常に高いシステムでは、バックアップシステムが次のジョブの開始前に1回分のバックアップを完了できない場合があります。これは深刻な問題につながりかねず、なかでも重大なのは、本来求めていた継続的なバックアップが実現できなくなるという点です。

システムによっては動作を容易に予測できますが、より多くの手間を要するものもあります。設定を調整し、その動作を観察し、再度調整するという作業に、ある程度の時間を費やす必要が生じるかもしれません。

複合的なバックアッププランの例

すべてに共通する画一的なスケジュールを用意する必要はありません。対象ごとに異なるスケジュールを設定して構いません。その際は、RTO、RPO、保持ポリシー、容量の上限を判断基準としてください。

一例を挙げます。

• ドメインコントローラー：標準的なGFS方式、保持期間1年
• 基幹業務アプリケーションサーバー（アプリケーションのみ）：月次フルバックアップ（OSおよびソフトウェアの更新後に実行）、保持期間3か月
• 基幹業務データベースサーバー：継続的バックアップ、保持期間6か月
• メインファイルサーバー：標準的なGFS方式、保持期間5年
• メールサーバー：Exchangeに特化した別のバックアップ製品を使用。日次フルバックアップ＋1時間ごとの差分バックアップ、保持期間5年
• 全対象：毎日午前0時にリモートサイトへレプリケーション
• 全対象：保持ポリシーに従い、月次でオフラインのフルバックアップを取得

---

Microsoft 365環境のバックアップは、Hornetsecurityのバックアップソリューションである365 Total Backupによって実施します。

包括的なガイダンスをお求めの場合は、Backup Bible（英語）をご入手ください。バックアップと災害復旧に関する貴重な情報を網羅した、必携のリソースです。

最新の記事や実践的な情報を継続的にご確認いただくには、ぜひHornetsecurityブログをご覧ください。

---

まとめ

すべてを漏れなく文書化することを忘れないでください。