DBアタマアカデミー

第3回 バックアップとリカバリ―「もしも」に備え,転んでも泣かない子になる(1)

この記事を読むのに必要な時間:およそ 3 分

はじめに

データベースには,重要なデータが多く保存されています。企業の財務状況から,私たち個人のプライバシーに関わるものまで,近年ではほとんどありとあらゆるデータがデータベース化されています。もし,そのデータが何かの間違いで消失してしまったら,データベースを管理していた企業やシステム構築を請け負った企業の受けるダメージは計りしれません。

しかし現実には,データ消失のニュースは定期的と思えるぐらい繰り返し報じられます。最近では,クラウドサービスのEvernoteでデータが消え,顧客6,323人に影響を与えた可能性があると報じられた話は記憶に新しいですし,昨年にはMicrosoft傘下の携帯電話向けサービスDangerでもユーザデータが消失する事件が起きました。

こうした障害が発生する原因は,大きく分けて2つあります。1つ目は論理障害と呼ばれるもので,そもそもシステムのロジックに欠陥があって,データを壊してしまうとか,人のオペレーションミスによるデータ損失です。2つ目は,物理障害です。文字通り,サーバやストレージなどハードウェアが物理的に壊れることによってデータが破壊されるケースです。

現在の多くのシステムでは,こうした事故が起きてもデータを失わないよう,冗長化などの手段が講じられていますが,それでもデータ損失の確率をゼロにすることは原理的に不可能です。そのため,そうした不運な場合に備えて,データを復旧できるようバックアップとリカバリの手段を持つことが,堅牢なシステム運営のために必要になります。DBMSもこのためのしくみを持っており,リカバリマネージャというモジュールがこの機能を担います注1)。

本稿では,データベースを中心としたバックアップ/リカバリのしくみについて解説します。特定のDBMSに限定せず,システム全般に適用できる一般的なロジックについて解説していきます。

対象読者
  • バックアップ/リカバリのプランを作ることになった人
  • 「~バックアップ」という言葉が多過ぎて整理できていない人
  • データ損失を経験して痛い目を見たことのある人/または将来そうなりそうな予感のする人
対象環境
  • すべてのリレーショナルデータベース
注1)
DBMSのアーキテクチャについては,本連載第1回 図1を参照してください。

バックアップ

まずは,バックアップの基本的な分類から話を始めます。最初に理解していただきたいのは,バックアップの種類にどのようなものがあるか,という点です。

よくシステム関係の書籍や製品のマニュアルを読むと,「~バックアップ」という用語がたくさん出てきて,最初はそれらの意味や相互の区別を理解するだけでも大変です。しかも,製品ごとに独自の名称が使われていたりして2ページの表1参照),理解を妨げられることもよくあります。

しかし,実際のところ覚えるべきものは少なく,基本的な分類は3つしかありません。それ以外の種類については,あとでゆっくり理解すればかまいません。

その3つの種類とは,フルバックアップ(または完全バックアップ),差分バックアップ増分バックアップです。この名称は「どんなデータをバックアップするか」という観点から付けられています。

フルバックアップ(完全バックアップ)

一番簡単な,そしてすべてのバックアップの基礎となるのがフルバックアップです。これは文字通り,ある時点でそのシステムで保持されているすべてのデータをバックアップするものです。そのため,このバックアップのファイルさえあれば,その時点のデータをすべて復旧することが可能になります。

これはもしもの話ですが,運用中のバックアップにおいて常にフルバックアップを取ることが可能なら,バックアップの運用は極めて単純なものになります。というのも,上記のように,これさえあればデータ復旧は簡単に終わってしまうからです。

データベースの基本精神
フルバックアップがすべてのバックアップの基礎

図1のように,月~土曜まで毎日フルバックアップを取得していたとして,日曜に障害が発生したとします。この場合,最新のデータを戻すのに必要なバックアップファイルはFだけです。A~Eの古いバックアップファイルはなくてかまいません。逆に言うと,Fのファイルが壊れてしまった場合には,最新の状態に戻すことはできないため,次善策としてEのファイルを使うことになります(Eも壊れていたらD…とさかのぼります)。

図1 毎日フルバックアップを取れるなら,話はとても簡単

図1 毎日フルバックアップを取れるなら,話はとても簡単

しかし実際のシステムでは,こういう「贅沢な」バックアップ運用を行っていることはまずありません。というのも,フルバックアップには次のような高いコストがかかるからです。

コスト①:バックアップにかかる時間が長い
システム内のすべてのデータをバックアップするため,バックアップに長時間かかります。読み取り専用ファイルなど,変更が発生しないデータを除外することで多少の軽減は可能としても,肝心の業務系データは日々変更されるのが普通のため,バックアップ対象に含めざるを得ません。
コスト.:リソースへの負荷が大きい
バックアップ対象のデータ規模が大きいということは,バックアップ中,データが保存されているディスクに対して大量の読み込み処理を発生させることを意味します。そのため,ディスク,サーバのCPU,さらに,もしネットワーク経由でバックアップする場合にはネットワーク回線まで,バックアップ処理だけで大きくリソースを消費します。そのため,バックアップ中にほかの処理を並行して行うことは現実的な運用ではありません。フルバックアップは,バックアップの中で最もリソースを大きく消費するのです。
コスト.:サービス停止が必要
フルバックアップを取得する場合,一般的にはDBMSなどのソフトウェアをシャットダウンし,サービスを停止させてから行います。これは,データの整合性を保った状態でバックアップを取得しなければならないためです。しかし,頻繁にサービス停止の可能なシステムというのは,それほど多くありません。

このように,フルバックアップはバックアップとリカバリの手順が簡単というメリットがありますが,実行コストが大きいので,これ単独で運用を行うことは現実的に不可能です。本連載の第1回でも述べましたが,「システムの世界にフリーランチ(ただめし)は存在しない」のでしたね。そこで通常は,フルバックアップを基本として,差分バックアップや増分バックアップと組み合わせた運用を行います。

差分バックアップ

差分バックアップdifferential backupとは,名前のとおり前回のフルバックアップからの変更分だけをバックアップする方法です。

図2 差分バックアップはフルバックアップより短時間で終わるのがメリット

図2 差分バックアップはフルバックアップより短時間で終わるのがメリット

図2を参照してください。たとえば,月曜日にフルバックアップを取得したとすると,火~土までは月曜から変更が発生した分だけのバックアップを取得することになります。具体的には,トランザクションログ前回参照)をバックアップすることで実現します。トランザクションログには,データベース内のデータに対するあらゆる変更操作の履歴が残っているのでしたね。そのため,これを保管しておくと,データベースに対する変更操作をもう一度再現することが可能になるわけです。

さてそうすると,月曜日から運用を始めて日曜日に障害が起きた場合,最新データを復旧するのに必要なファイルは,「A+F」となります。Aのフルバックアップのファイルは絶対に必要です。変更履歴のログだけあっても,変更を適用するべき大元のファイルがなくては話になりません。一方,B~Eのファイルは不要です。これらのファイルに含まれているデータはFにすべて含まれているからです。その点で,差分バックアップは冗長なデータをバックアップすることになります。

このように,差分バックアップを利用すると,復旧時の手順が1つ増えますが,その代わり,日々のバックアップに必要なデータは小さくなるため,バックアップに必要な時間が短くなります。その分,リソースへの影響も小さくなります。

著者プロフィール

ミック

SI企業に勤務するDBエンジニア。主にデータウェアハウス業務に従事している。自身のサイト「リレーショナル・データベースの世界」でデータベースとSQLについての技術情報を公開している。『Web+DB Press』で「SQLアタマアカデミー」を連載中。

著書:『SQL ゼロからはじめるデータベース操作』(翔泳社,2010)『達人に学ぶ SQL徹底指南書』(翔泳社,2008)訳書:J.セルコ『SQLパズル 第2版』(翔泳社,2007)

DBアタマアカデミー:サポートページ

コメント

コメントの記入