PR

 今回はバックアップについて,要件別にどのようなバックアップ方法・方式が適しているかを見ていくことにする。

 まずは,バックアップの目的がリカバリ(障害からの回復)なのかアーカイブ(長期的な保管)なのかをはっきりさせよう。従来はこの二つの要件を混同していたり,あえて区別していなかったりしていた。あるいは区別はするものの結果として一つのバックアップ・システムによって双方を実現するということが行われてきた。一つのシステムで実現してしまうことに特別に問題があったわけでもなく,むしろ効率的であったとも言えた。だが最近ではアーカイブに対する要件の変化や,技術の進化により,それぞれの目的に合ったシステムを構築する方が効率の良い場合もある。そのため,バックアップの目的がリカバリなのかアーカイブなのかを区別しておくべきである。

 リカバリを目的とする場合には,対象とする障害が広域災害(地震,洪水,津波など)や局所災害(火事など)を対象とするのか,それともシステム障害を対象とするのかを明確にする必要がある。災害(広域災害や局所災害)対策を目的とする場合,データの転送という要素が加わり最適な方法が変わってくるからである。

 災害対策については別の回に譲ることにし,ここではシステム障害からのリカバリを目的とするバックアップに焦点を絞ることにする。

システム障害からのリカバリのためのバックアップ

 システム障害からのリカバリの主要な要件としては,RTOとRPO,バックアップ対象のデータ特性(システム領域かデータ領域か,データベースなどアプリケーション・データか文書などのファイルか),バックアップ・ウインドウ,世代数などがある。中でも重要なのはRTOとRPOである。

RTOはRecovery Time Objectiveの略で目標復旧時間,つまり障害の発生後,どのくらいの時間でデータをリカバリできるかの目標時間を示す。RPOはRecovery Point Objectiveの略で目標復旧時点,つまりどのくらい“新しい”データを復旧できるかの目標値である。ビジネスの観点からすると,RTOには,(RPOまでの範囲において)欠損したデータを復旧する時間やビジネス・プロセスの復旧にかかる時間なども考慮に入れる必要があるが,ITアーキテクトの仕事の範囲を超える部分もあるので,ここではそれらを省略する。

 RTOは復旧までの時間なので(データを扱う)プロセスの重要度に依存し,RPOは復旧したデータの“新鮮さ”なのでデータの重要度に依存した指標である。

 一般的にRPOはバックアップの実施間隔で決まる。RPOが秒単位~分単位の要件の場合,いわゆるバックアップはできずレプリケーション(データ転送による複製)を行うことになる。RPOが0~数秒であれば「同期レプリケーション」,RPOが数十秒~数分であれば「非同期レプリケーション」,十数分であれば同期・非同期を組み合わせた「ハイブリッド・レプリケーション」を採用することになる。

 RPOが時間単位という要件の場合には,フルイメージ・スナップショット(プライマリ・ボリュームのコピーをセカンダリ・ボリュームに取る方法),Disk-to-Disk あるいは Disk-to-Disk-to-Tapeなどの方法によるバックアップになるだろう。ただディスク容量にもよるが数時間ごとにフルバックアップを取得するのは難しいので,休日など非営業日にフルバックアップを取得し,営業日には差分バックアップを取得するというのが一般的である。

 RTOが数時間の場合,バックアップにより取得したデータをリストアする時間的余裕はないので,フルイメージ・スナップショットを実施し,復旧の際にはスナップショット領域をプライマリ領域に「昇格」させるという方法を利用する。数時間以上,1日程度のRTOの場合は,フルイメージ・スナップショットあるいはバックアップ・データ(DiskまたはTape)からリストアによって復旧させることも可能であろう。

 ここまでは単一システムのバックアップについて説明した。ここからは,複数のシステムからなる複合システム,あるいは統合バックアップ環境での方法論を検討することにしよう。