バックアップ導入の勘所

こんにちは。SCSKの堀口です。

本記事では、バックアップシステムを導入する上で考慮すべきポイントを記載しています。

バックアップに関する技術記事は多く見かけますが、
実際にバックアップシステムを導入する際にどのような観点で考えればいいか迷った経験はないでしょうか。

筆者は、オンプレミスのバックアップから自社クラウドのバックアップサービス開発など
多くのバックアップシステム導入に携わってきました。

その経験・ノウハウの中で得たバックアップ導入の勘所をお伝えします。

記事内での用語

バックアップに関連する用語について文脈・読者によって解釈が変わる場合があります。
本記事内での用語の意味は以下の通りです。

用語	意味
バックアップ	特に断らない限り、サーバ全体のバックアップを意味します。 本記事ではシステムバックアップとデータバックアップを区別しません。
リストア	特に断らない限り、バックアップデータからサーバを復旧させること全般を意味します。
DRシステム	DRは、Disaster Recovery（ディザスタリカバリ）の略称。直訳で「災害復旧」です。 DRシステムは、DR対策用のシステムを意味します。
メインサイト	DRシステムにおいて、通常時にシステムが稼働する環境を意味します。
DRサイト	DRシステムにおいて、災害時にシステムが稼働する環境を意味します。

それぞれ特定の意味で用いる場合、説明を入れますのでご留意ください。

バックアップシステム導入の全体像

一般的なシステム開発と同様ですが、以下のようなステップでバックアップシステムの導入を検討するのが望ましいです。
※ 概要および一例なので、各ステップは細分化されたり一部前後・反復して実施される場合があります。

No.	ステップ	内容
1	アセスメント	システム全体およびバックアップ対象の情報を調査・整理、評価する。 CPU/メモリ/ディスク/ネットワーク構成などのスペックや稼働するアプリケーション、サーバの役割などの情報を明確にする。
2	要件定義	バックアップシステムに求められる要件を決定する。 バックアップシステム導入の「目的」と「目標」を明確にする。
3	製品選定	要件を満たすバックアップ製品を調査・選定する。
4	基本設計	バックアップシステムの構成、利用機能などを決定する。 各システム、サーバーに対して保存世代数やスケジュールなどのバックアップ設定を決定する。 運用設計もここに含む
5	詳細設計	基本設計の内容をもとにバックアップシステムのパラメーターシートを作成する バックアップジョブの設定値を決める
6	構築	パラメーターシートをもとにバックアップシステムを構築する バックアップジョブを作成する
7	テスト	バックアップシステムおよびバックアップジョブに問題ないかテストする

以下、アセスメント、要件定義を中心に各工程を考えるヒントになることを書いていきます。

アセスメントのポイント

アセスメントのポイントは、バックアップ対象のスコープ（範囲）と各対象の情報を洗い出し、整理することです。

まずは、システム全体の中でバックアップシステムの対象となる範囲を明確にします。
環境情報（ベアメタル環境、仮想環境、クラウド環境）やロケーション、設定ファイルなども対象になるかを洗い出してください。

次にスコープ内のバックアップ対象については以下の情報を最低限収集してください。

• バージョン情報：ハイパーバイザーのバージョン、OS種別
• スペック情報：CPU、メモリ
• ディスク情報：ディスク構成、ディスクサイズ、ディスク種別
• NW情報：NIC構成、IPアドレス
• システムの役割とシステム間の依存関係

既存のバックアップシステムがある場合、既存のバックアップシステムの構成や取得方法、バックアップジョブの情報も取得してください。
また、既知の問題や課題が発生している場合は洗い出し、原因や解決策を明確にするのが望ましいです。

これらの情報は、要件定義や製品選定時の適合性、バックアップシステム全体の設計、バックアップジョブの設計などに利用します。

要件定義のポイント

アセスメントによりバックアップ対象の全体像を把握した後は、バックアップ要件を決定していきます。

その上で重要となるのが、バックアップの目的を明確にし、目標を定めることです。

• 目的は、どのようなインシデントを最も脅威と考えて対策するかを意味します。
• 目標は、その目的を実現するためにどのような状態を目指すかを意味します。

「広域災害対策」を目的とした場合には、
普段システムが稼働する地域とは別に、遠隔地に災害時用の環境を準備する、いわゆるDRシステムの検討が必要です。

「ランサムウェア対策」を目的とした場合には、
保存したバックアップデータ自体をランサムウェアに書き換えられないようにする仕組みの検討が必要です。
なお、このようにバックアップデータを書換不可にする仕組みを「イミュータブルバックアップ」と呼びます。

※ ランサムウェアとは
マルウェアの一種で、感染したサーバーやデータを暗号化し、復号するために身代金を要求する攻撃です。
バックアップデータ自体を暗号化する攻撃も登場しており、より復旧が困難になる場合があります。
マルウェアについてより詳しく知りたい方は以下のコラムをご参照ください

ランサムウェアに気をつけろ！基礎知識と安全対策のポイント

このように、目的に応じて必要となる機能や構成が変わってくることがわかります。

複数の事象に対応しようとすると、様々な機能を利用し、構成が複雑になりがちで、コストが肥大化したり、運用負担が大きくなってしまう場合があります。

要件定義をする際にあれこれと要件を詰め込みそうになったり、記載内容に迷ったら、目的・目標を見返しましょう。

全てのシステムに対して同じレベルで対策するのではなく、
重要度やシステムの特性に応じてバックアップシステムを設計・導入することがカギになります。

では、どのように整理していくのか、重要な3つの指標を説明します。

RTO、RPO、RLOについて

一般的にバックアップやDRからの復旧時に利用される指標に以下の3つがあります。

RTOについて

RTOは対象のシステムを復旧させるまでの時間の指標です。指標の幅は数分、数時間、数日と様々です。

RTOを短く設定し、実現できるほど、より迅速にシステムやビジネスを復旧させることを意味します。
復旧時間は、復旧対象の規模やパフォーマンス、復旧方法に依存します。

以下、代表的な復旧方法の違いによるRTOの違いについて整理しました。
なお、RTOは復旧対象のサイズ、バックアップ環境や本番環境の構成・パフォーマンスにも影響されるため、参考程度に考えてください。

バックアップデータのマウント方式

バックアップデータのリストア方式（保存先と復旧先が同一リージョン）

バックアップデータのリストア方式（保存先と復旧先が異なるリージョン）

なお、RTOは以下のバックアップの仕組みにも左右されます。ご留意ください。

• バックアップ取得時の方式：フル、増分、差分、永久増分バックアップ
• バックアップメディア・保存先：ストレージ、バックアップテープ、クラウドストレージ

RPOについて

RPOは対象のシステムをどの時間に復旧させるかの指標です。指標の幅は数分、数時間、数日と様々です。
RPOは必ずしも短ければいいというものではないため注意が必要です。

例えば、RPOを1時間と定義し、以下の設定でバックアップジョブを作成・実行したとします。

• 実行周期：1時間ごとに実行
• 保存世代数：24世代

この場合、もしウイルスに感染して気づくまでに2日かかってしまうと、
バックアップデータもすべてウイルスに感染した状態のデータになってしまいます。

これを回避するためには、世代数を増やすか、バックアップの周期を長くする必要があります。
（もちろん、早期にウイルス感染を検知することも有用です）

RPOを達成するためには、基本的にバックアップジョブの実行周期を調整します。

RPOを1日とする場合は、毎日バックアップジョブを実行するようにします。
もしくは、より短い実行周期で世代数を多く保持する方法でも達成可能です。

このとき注意するポイントは、バックアップジョブが設定した周期で終わるように設計することです。

バックアップ対象のサイズや前回のバックアップ実行から差分が大きい場合、次回のバックアップ実行までに完了しない場合があります。
また、より短いRPOを達成する必要がある場合は「レプリケーション」方式のソフトウェアも検討されます。

レプリケーションは、常にレプリケーション対象（バックアップ対象）のデータをレプリケーション先の環境に転送する方式です。
これにより、数秒のRPOを実現することが可能になっています。

レプリケーション利用時は、データの変更量がレプリケーションの処理速度を超える場合、データが滞留してしまうため注意が必要です。

RLOについて

RLOはどのレベルでシステムを復旧させるかの指標です。
レベルを決める観点は「システムの優先度」、「スペック」、「可用性」などがあげられます。

例えば、災害発生により全システムが停止し、DRサイトでシステム復旧できる状態になったとします。
このとき、すべてのシステムを通常時と同じように復旧させようとするとリストアや動作確認に時間がかかり、結果的にRTOが満たせなくなる可能性があります。
そのため、あらかじめ復旧させるシステムに優先度を決め、優先度の高いシステムから復旧する準備が有用です。

また、DRサイトにメインサイト同様のリソースを準備できないこともあるため、
災害時には、スペックを落とした縮退運転や、冗長構成のものを単体で動作させることも検討が必要です。

実際の設計時には、復旧対象のグルーピングや復旧作業のフェーズ分けの明文化をお勧めします。

まとめ

要件定義する際には以下を明確にすることを説明させていただきました。

• アセスメントでバックアップ対象の情報を洗い出すこと
• バックアップの目的と目標を明確にすること
• RTO、RPO、RLOを定義すること

これらの情報を製品選定時に条件を満たしているか、設計フェーズでは抜け漏れがないか判断材料に活用してみてください。

USiZEシェアードモデルの紹介

当社のプライベートクラウド「USiZEシェアードモデル」では複数のバックアップサービスを提供しています。
要件に合わせてバックアップおよびDRシステムを複雑な設計不要で導入できます。

USiZEシェアードモデルの概要については以下のページも参照してください。

• 運用付きの国産クラウドサービス　USiZEシェアードモデル
• SCSKのプライベートクラウド「USiZEシェアードモデル」とは？