【初心者エンジニア向け】知っておきたいバックアップの基礎知識まとめ

システムは安定稼働させる事はもちろんだが、普段からバックアップを取得しておきいざという時にはリストアできる環境を整えておく事は今や当たり前の時代となっています。

そんなバックアップについてですが、実はシステムをトータルで理解しないと設計から実装が難しく、エンジニアの地力が出る分野でもあります。

そんな中で最近話題に上がってくるのが、そもそもバックアップ用語を理解できていない場合があるという事。

「RTO、RPOって何？」

とか

「増分バックアップと差分バックアップの違いは？」

といった話題が上がってくる事が結構な頻度でありました。

実際近年では大規模災害に備えたBCP(事業継続計画)やDR(災害復旧)のような環境を構築する企業も増えている事から、バックアップに対する理解は多くの環境で必要になってきます。

そこで本記事ではバックアップ設計をトータルで行う上で必要な用語をまとめ、基本的な知識をお伝えしていこうと思います。

バックアップ取得方法の基本

まずは通常のバックアップに関する用語と特徴です。

システムバックアップやデータバックアップ、差分バックアップと増分バックアップの違いなどを説明していきます。

システムバックアップ

一般的にシステムバックアップと言うとシステムのOS部分を取得するバックアップの事を指します。

バックアップ対象はWindowsやAIX、LinuxといったOSのシステム起動に必要なファイルで、バックアップ取得したファイルをリストアすればOSが起動してくる状態のものを指します。

近年ではイメージバックアップやSnapshotといった技術が発達してきた為か、システム部分とデータ部分を区別なくバックアップ取得するシステムも増えてきました。

しかし、大容量データを包括するシステムにおいてはシステムバックアップとデータバックアップを区別して取得するシステムの方が大多数で、データ部分のみ毎日バックアップを取得し、システム部分は数か月に1回とかパッチ適用前後といったシステムも多く存在しています。

その他にも以下のような特徴があります。

データバックアップ

システムバックアップと対になって取得するのがデータバックアップ。

データバックアップは業務データを格納する領域やデータベースを格納している領域を取得する事が一般的です。

仮にデータの一部分が壊れてしまった場合でも戻せる事を条件に組み込む事が多いので、データバックアップは毎日取得するシステムも多いです。

仮にOSごとシステムが壊れた場合、「システムリストア」＋「データリストア」を行う事で完全なリストアが行われる状態となります。

更にデータバックアップには以下の考え方が存在しており、システムの特徴とあわせてトータルで考えた設計が必要となります。

フルバックアップ

データバックアップの対象とした領域やファイルを全てバックアップする方法。

バックアップ対象のデータ量によって毎日取得するか週に1回、2週に1回といった頻度を決定します。

システムリプレース時期にあわせて大体5年～8年ぐらいのバックアップ対象データ量を見積もっておき、

フルバックアップに耐えうる時間帯がどれぐらいあるか？

によって取得頻度を決定する必要があります。

後述するウォームバックアップを採用する場合を除き、データ部分にはアクセスがない状態で取得する事が多数の為、メンテナンス時間を日次で設けて取得する場合が多いです。

特徴は以下の通り。

差分バックアップ

フルバックアップの次に考慮されるのが差分バックアップです。

差分バックアップとは、フルバックアップで取得した時点から変更のあったファイルのみバックアップする手法になります。

例えばフルバックアップを毎週月曜日の夜中に取得し、差分バックアップを日次で取得する場合、

火曜日のバックアップは月曜日のフルバックアップ時点から変更のあったファイル全てを対象に取得
水曜日のバックアップは月曜日のフルバックアップ時点から変更のあったファイル全てを対象に取得

といった形で月曜日のフルバックアップを基準として変更があったファイル全てをバックアップ取得します。
よって火曜日時点で変更が入ったファイルは水曜日以降も毎回取得される事となる為、火曜日時点から次の月曜日時点まで変更が入らなかった場合でもずっと取得対象となります。

その他の特徴は以下の通りです。

増分バックアップ

差分バックアップと同様に検討されるのが増分バックアップです。

差分バックアップとの違いは、フルバックアップと増分バックアップに関わらず前回取得時点から変更があったファイルをバックアップ対象とする事です。

よって例えばフルバックアップを毎週月曜日の夜中に取得し、増分バックアップを日次で取得する場合、

火曜日のバックアップは月曜日のフルバックアップ時点から変更のあったファイル全てを対象に取得
水曜日のバックアップは火曜日の増分バックアップ時点から変更のあったファイル全てを対象に取得

といった形となり、差分バックアップよりも効率的なバックアップとなっています。

ただし、増分バックアップを取得する場合、リストア時はフルバックアップに加え、取得した増分バックアップ全てを戻さないといけません。

例えば上述したサイクルで取得しているシステムが木曜日の増分バックアップ取得後に壊れ、リストアが必要な場合、

月曜日のフルバックアップをリストア後、火曜日、水曜日、木曜日に取得した増分バックアップをリストアする必要があります。

差分バックアップの場合、最短で月曜日のフルバックアップと木曜日の差分バックアップを戻せばよい為、リストア時の手順は簡単になるというメリットがあります。

その他の特徴は以下の通りです。

差分バックアップと増分バックアップの選定について

差分バックアップと増分バックアップについては一長一短の為、どちらを選定しようか迷う場合も結構あります。

基本的にはリストア時の手順の楽さから差分バックアップを選ぶシステムが多いように感じますが、実際選ぶときの指針は以下の通りです。

バックアップ関連用語

バックアップリストア時に抑えておきたい設計用語を紹介していきます。

RTO(Recovery Time Objective)

RTO(Recovery Time Objective)はシステム障害が発生してからリカバリ完了するまでにかける事が可能な時間の事です。

RTOが24時間なら障害発生からリストア完了まで24時間以内に終わらせなければなりません。

RTOは最悪のパターンを想定して設定される時間の事になりますので、障害発生発覚時点で機器交換が必要な場合は機器交換を含めての時間を規定する場合が多いです。

中には機器が調達できてからの時間を指す場合もありますが、それらは設計時点で明確に規定されるべき事項になりますので
RTOを定める際に、障害発生時点から「どんな事項を含め」「何が必要となるのか？」を設計するように心がける必要があります。

RPO(Recovery Point Objective)

RPO(Recovery Point Objective)は障害発生時から過去のどの時点までのデータを復旧させるか？の指針となります。

例えばRTOが24時間なのであれば、障害発生時点から24時間手前までのデータは必ず復旧させる必要があります。

よって障害発生時点から直前のバックアップまでは確実に取得されている必要がありますし、リストア可能な状態を構築する必要があります。

よくあるのが、RTOは24時間と設定されているにも関わらず営業日のバックアップしか取得されておらず、月曜日に壊れると直前の営業日である金曜日時点に戻ってしまうといったトラブルです。

営業日時点の24時間なのであればその旨を設計に組み込む必要がありますので、ちゃんと設計時点で考慮するようにしておきましょう。

コールドバックアップ

コールドバックアップは文字通りOSやサービスを停止して静的な状態(コールド)として取得するバックアップです。

一般的なバックアップと言えばコールドバックアップを指します。

コールドバックアップはファイルへのアクセス状態を最小限にしてバックアップ取得する為、書き込み完了したファイルの整合性が取れた完全な状態でバックアップする事を特徴としています。

よって基本的にはリストア時にファイルが壊れている事はないですし、もし壊れていたらバックアップ取得時の状態に異常があったと言えます。

バックアップはコールドバックアップが取得できるメンテナンスのタイミングを調整し、メンテナンス時間内に

サービス停止⇒バックアップ⇒サービス起動

といった流れを設計する事が基本です。

ウォームバックアップ

コールドバックアップとは反対にサービスが起動している状態で取得するバックアップです。

サービスを停止せずにバックアップ対象ファイルの入出力トランザクションを一時的にロックした状態で静的な状態を作り出し、バックアップを取得する方法です。

一般的にメンテナンス時間が捻出できないシステムもしくはRPOが極端に短いシステムの場合に検討する手法ですので、あまりお目にかからないかもしれませんが、昨今のシステムは24時間運用のシステムも多いため、徐々に取り入れられてきた手法でもあります。

その他にも下記のような理由でウォームバックアップの採用を検討する事があります。

D2T(Disk to Tape)バックアップ

ディスクからテープへ取得するバックアップの事をD2T(Disk to Tape)バックアップといいます。

現在でこそ後述するD2Dバックアップが主流となりつつありますが、昔はDATテープやLTOテープに取得するテープバックアップが基本でした。

ディスクとは別のテープ媒体を用いる事によって、データバックアップをサーバOSとは別の領域に保管する事ができる事から大変重宝されているバックアップ手法です。

また後述するD2Dバックアップと比べると安価で済むことが多いという特徴を持ちます。

D2D(Disk to Disk)バックアップ

ディスクからディスクへ取得するバックアップの事をD2D(Disk to Disk)バックアップといいます。

バックアップ用のディスク領域に対してバックアップ取得を行う事により、テープバックアップに比べて高速なバックアップやリストアが可能となります。

ただし、テープバックアップと比較するとバックアップ用のディスクを用意しなければならないコストが高くつくことが多いです。

バックアップ取得方法

データバックアップを取得する方法について種類ごとで簡単に説明します。ファイルバックアップやsnapshotなど、近年のデータバックアップにおける基本的な取り方を紹介していきます。

ファイルバックアップ

ファイル単位で取得するバックアップになります。

1ファイルごとをバックアップ領域にコピーする事で取得されるバックアップになりますので、リストアも1ファイルごとで実施できるという特徴があります。

ただ、近年では技術の進歩により、Snapshotを利用したバックアップから1ファイルごとにリストアできる技術も出てきているので、ファイルバックアップをとらないシステムも出てきているので一概にファイルバックアップのみが単独ファイルに対応しているわけではありません。

ファイルバックアップは基本的にコピーする事が前提の動きの為、取得対象が増えれば増えるほどにバックアップ時間が延びるという特徴があります。

単純な話、OSのコピーコマンドで退避する事もファイルバックアップですし、ARCserveやNetVaultといったバックアップソフトを利用する事でもファイルバックアップが可能です。

最も単純かつ簡単な手法でバックアップを取得する事もできるのがファイルバックアップの特徴です。

イメージバックアップ

ISOイメージをはじめとしたイメージ媒体に落とし込むバックアップです。

基本的にイメージバックアップは対象領域を丸ごとイメージとして取得する為、ファイル数やファイルサイズには依存しません。

代わりにイメージ対象となるディスクや仮想イメージのサイズに依存する事から、システム構築時点でかかったバックアップ時間から大きな差異が出ないという特徴があります。

一見するとイメージバックアップは便利なように思えますが、実態としてシステム停止が伴う事が大半の為、システムバックアップを兼ねて取得する事が一般的になっています。

snapshot

VMwareやストレージなどをはじめとするブロック単位のバックアップがSnapshotとなります。

snapshotはファイル単位ではなくブロックの位置情報を記録するバックアップ方法で、Snapshot領域という保管領域にブロックの位置情報と差分ブロックデータをため込む事によって取得されるバックアップです。

snapshot自体はブロック情報を記録するバックアップの為、OSが動いていようと取得する事は可能です。

一瞬の状態をスナップ写真のように取得する事からsnapshotと言われています。

よって、Snapshotを取得する一瞬のみサービス停止して静的な状態を作り出し、ブロックの位置情報を記録、その後サービス起動したバックグラウンドでブロック情報をコピーする事が可能です。

一見するととても便利な機能なので全てSnapshotで良いのでは？となりがちですが、実はsnapshotというのはsnapshot領域だけではバックアップが成立しておらず、全損した場合はディスクのリストアが必要となります。

よってSnapshotを取得すると共にディスク全体を外部媒体にバックアップしたり、DR環境へディスク全体をミラーするバックアップなどを別途検討する必要があります。

近年はVMwareをはじめとする仮想OSの台頭やAWSやGCPといったクラウド環境においてもsnapshotを利用する事が多いため、snapshot取得後にDR環境へ退避のような構成が一種のスタンダードにもなっています。

まとめ

書いていたら長くなってしまいましたが、バックアップの手法として様々な手法や用語を一通りざっと記載しました。

他にもこんな情報を教えてほしいといった要望があれば追加していきますので、ご意見お待ちしています。