前回は、ファイルサーバの現状を弊社が行なっている「簡易情報アセスメント」の結果と絡めて課題の洗い出しをしました。今回は、多くの情報システム部門が頭を悩ましているだろうバックアップについて、2回に分けて考えてみたいと思います。

前回、ファイルサーバに求められる管理策として、「有効かつ確実な」という修飾をつけました。
これには、「バックアップの目的を明確にし、求められる要件を満たす」という思いを込めています。

バックアップの目的

ファイルサーババックアップの目的は、以下の2点に集約できると思います。

• 操作ミス・勘違い等によるファイル消失からの復旧
• 装置自体の故障・損傷時のデータ復旧

バックアップの要件

これらの目的を達成するため、バックアップの要件を決定します。要件には以下の4つが挙げられます。

バックアップのタイミング

バックアップのタイミング（頻度）は「どれだけ情報の鮮度が必要とされるか」によって決まります。通常のファイルサーバであれば、最低限日次でのバックアップが必要になります。

バックアップの世代

バックアップの世代はどのようなバックアップでも共通の要件として最低で2世代以上必要となります。これは、バックアップ実施中に主装置が壊れると、主・バックアップ、双方のデータ共に使えなくなってしまうからです。
後は、組織の必要性として「何日前の状態にまで戻す必要性・可能性があるか」によって決まります。ファイルサーバの場合、1週間（6世代）または1ケ月（30世代）とする場合が多いようです。

復旧時間

復旧時間は、目的によって2つ設定する必要があります。

• 誤操作等の対応として、ファイル単位の復旧を目的としたもの
  ファイル単位の復旧は、情報システム部門のマンパワーにもよりますが、作業着手からどんなに時間がかかっても1時間以内が目処になると思います。
• 全データの復旧を目的としたもの
  全データの復旧は、データ量とバックアップの手法、回線速度、ハードウェアの性能によって決まります。一つの目安として、バックアップ・リストアの時間として共に、Windows系、GbitLAN、一般的なNASへのバックアップの環境だと、1～2GByte/分程度、増分・差分の読込み・再構成はその半分程度（0.5～1GByte/分）程度のスループットとなるようです。
  仮に1TByteのフルバックアップからの復旧だと8時間20分～16時間40分は見ておくことが必要となり、更に差分・増分の量と世代分の作業時間も必要なることを考慮しておく必要があります。

バックアップの媒体と保管

バックアップの媒体としてはテープとハードディスクが一般的だと思います。ただし、ファイルサーバのバックアップとして、ファイル単位の復旧を考慮すると、テープでは操作性が悪くなってしまいます。従って、ハードディスクを主たる媒体とすることが考えられます。一方、全データの復旧ではテープを媒体とすることも選択肢に入ってきます。
実際の運用を考えると、サーバルーム内のハードディスクに最新を含む必要世代分のバックアップを保管することと、最新版は遠隔地に保管することが望ましいと思います。

バックアップの方法

バックアップの方法としては、大きく3つの方法があります。

フルバックアップ

• 対象データを全てバックアップする方法
  データの全復旧は1回で可能となるが、データ量は元データ量☓世代分必要となる

差分バックアップ

• 前回のフルバックアップからの変更分のみをバックアップする方法
  リストアはフル＋最新差分のみの2回で可能

増分バックアップ

• 前回のバックアップからの変更点のみをバックアップする方法 リストアはフル＋増分回数分実施する必要がある

通常、ファイルサーバのバックアップでは差分もしくは増分バックアップを行うのが一般的です。通常、1週間分の世代が必要となるのであれば、週1回（休日）にフルバックアップを行い、平日に差分もしくは増分バックアップを行うことが考えられます。

バックアップの課題

フルバックアップ取得にかかる時間

先に上げたように1TByteのデータをフルバックアップするのに8時間以上かかるのだとすれば、6TByte以上のフルバックアップだと、48時間以上かかることになり、土日で終わらないことになりかねません。これはバックアップに関する最大の問題点となります。
最近のバックアップソフトでは、この問題を解決するため、初回のみフルバックアップを行えば、増分のデータから内部でフルバックアップイメージを生成する機能を持った製品が出てきています。

バックアップ媒体の肥大化

ファイルやブロック単位での重複排除や圧縮機能を用いて、バックアップ媒体の容量を圧縮する機能を持ったものもあります。また、これらの機能をハードウェアとして実装しているバックアップ専用ストレージも製品化されています。

遠隔地への保管

これまで、遠隔地への媒体保管を考える場合、テープの搬送を行うことが一般的でした。これは、オンラインバックアップは回線スピードの問題、データ量の問題から現実的ではなかったからです。また、以前の基幹系システムのように、月次や週次でバッチ処理を行うシステムであれば、月次／週次でテープバックアップを行い、搬送することも可能だったと思います。
しかし、これを日次で行うには、搬送時の紛失・盗難対策としての暗号化、鍵管理、搬送にかかる手間等の問題から、非常に困難です。

最近のバックアップツールやバックアップ専用ストレージではバックアップデータの重複排除・圧縮を行った上で、遠隔地へのレプリケーション（複製）を行う機能を装備したものも出てきています。

参考までに、これはファイルサーバの例ではないのですが、ある情報系システムのバックアップ・遠隔地レプリケーションの例と挙げておきます。バックアップ専用ストレージをデータセンタと本社に設置（重複排除、独自圧縮機能装備）、本番機はデータセンタに設置、本社をバックアップの遠隔地としています。

バックアップ対象データ量は約1.9TByte、日次で3世代フルバックアップしています。 フルバックアップといっても、装置内でフルバックイメージを自動で生成しているため、実際には増分のみを取り込んでいます。
本番機のバックアップ時間が約3時間、データセンタから本社のデータ同期は約1時間以内で完了しています。
この際、重複排除、圧縮がかかり、バックアップ媒体上のデータは運用初期で9.2倍、現在は13.3倍の圧縮率となっているとのことです。

今回は、ファイルサーバのバックアップとして、その目的・要件・方法・課題について考えてみました。次回はバックアップの構成例と、ファイルサーバの現状とバックアップのまとめについてお話しします。