DBアタマアカデミー

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

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

バックアップの一般的な運用形態

さて,これで基本的なバックアップの区別ができました。これらには一長一短があるため,実際の運用においては,複数のバックアップ方式を組み合わせるのが普通です。前述のように常にフルバックアップを取得する「富豪」運用が可能なら話は非常に簡単になるのですが,人生の大概の局面において,問題はそんなシンプルなものではありません。さまざまな入力条件に応じて,最適解を見つける努力が必要になります。

要件とバックアップ方法の選択

バックアップの方式を選択する場合,考慮するべき要件には次のようなものがあります。

  • どの時点の状態に復旧させる必要があるか/そもそも復旧の必要があるか
  • バックアップに使用できる時間(バックアップウィンドウ)注3
  • リカバリに使用できる時間(リカバリウィンドウ)
  • 何世代までのデータを残す必要があるか

バックアップって本当に必要?

は,最も根本的な要件です。もしそもそも「データの復旧の必要なし」ということであれば,バックアップとリカバリについて考える必要がなくなるからです。そんなシステムがあるのか,と疑問に思うかもしれませんが,これはまったくない話ではありません。DWH/BIDataWareHouse/Business Intelligenceのような情報系システムの場合,データは読み取り専用ですので,大元の基幹系システムからもう一度データを流し込めば復旧が可能です。わざわざバックアップファイルから戻す必要がないのです注4)⁠

また,バックアップファイルからの復旧自体は必要だとしても,特に最新の状態に戻さなくてもよい,という場合には定期的にフルバックアップだけ取得して,差分/増分のバックアップは行わない,というシンプルな運用が可能になります。

データベースの基本精神
本当にバックアップが必要か,3回自問しよう

事件は夜中に起きている

はどのようなバックアップ方式を用いるかの選択に大きく関係する要件です。一般的に,バックアップを行えるのは,サービスを止めたメンテナンス時間帯か,データへのアクセスが少ない夜間帯(だいたいAM0~6時ぐらい)です。万が一,このウィンドウ内でバックアップが終わらなかった場合注5)⁠日中にユーザがアクセスする負荷とバックアップの負荷が重なることになり,リソースの食い合いが発生します。これは深刻なパフォーマンス低下を招くため,通常は,安全のためバックアップウィンドウの半分ぐらいでバックアップを終わらせることが目標になります。夜間にはバックアップ以外のさまざまなバッチ処理も実行されるので,これらの実行時間も除外すると,条件はかなり厳しくなります。

こうした厳しい時間的な制約条件から,夜間帯に差分バックアップや増分バックアップをホットバックアップで取得する,というのがOLTP系のシステム注6では一般的です。

また,の条件は,ちょうどの条件の裏返しです。差分/増分バックアップは,日々のバックアップ時間を短く終わらせることができる一方,リカバリ時間は長くなります注7)⁠そのため,バックアップ方式の選定においてはリカバリ時のことも考える必要があります。

注3)
ここでのウィンドウは,Windowsなどで用いられる「窓」の意味ではなく,⁠範囲」とか「期間」という意味です。SQLのウィンドウ関数の「ウィンドウ」も同じ意味です。
注4)
情報系の場合,もう一つバックアップに向かない理由があります。データ量がテラバイト級のため,そもそもバックアップを取るだけで大量の媒体と時間が必要になってしまいます。
注5)
この事態を俗に「突き抜ける」などと表現します。
注6)
On-Line Transaction Processing。ネットワークに接続された複数の端末がそれぞれサーバに処理の要求を行い,サーバがデータの追加・変更・削除などを行って結果をその都度端末に返す情報の処理形式。一般的にBI/DWH系システムよりも利用ユーザ数が多く,高速なレスポンスが要求されます。
注7)
この欠点を解消する技術が統合フルバックアップでした。

バックアップ媒体から見た運用形態

の条件は,主にバックアップデータを保管しておく媒体の選定に関わります。これについては,少し詳しく見ていくことにしましょう。

バックアップの間隔と当該システムにおけるデータ更新の多さ,何世代分を残すかといった要件にも依存しますが,バックアップファイルの累積サイズはかなり大きなものになります。また安全の観点からもサービス系のシステムとは独立した媒体に保管しておく必要もあるため,バックアップ専用の記憶媒体を用意することが一般的です。

このとき,問題になるのはメディアの容量と性能です。本連載の第1回でも取り上げましたが,記憶装置の容量と性能はトレードオフ,つまりどちらか一方が良いものはもう一方が悪い,という関係にあります。そのため,ここでも開発者は「あちらを立てればこちらが立たず」のパズルを解く必要が生じます。


D2T,D2D

バックアップ媒体としてこれまで一番ポピュラーだったのは,テープです。これは3次記憶装置に分類されることからもわかるとおり,大容量のデータを保存できて信頼性が高い代わりに書き込み/読み込みの速度は低速です。そのため,バックアップとリカバリに長時間を要します。他方,最近ではディスクの大容量化と低価格化が急速に進んだことで,バックアップ媒体としてディスクを使用することも増えてきました。そのため,一般的にはこの2つが候補となります。

バックアップ対象データが格納されているディスクから直接テープへバックアップする方法をD2TDisk to Tape図5)⁠テープの代わりにディスクへバックアップする方法をD2DDisk to Disk図6と呼びます。

図5 D2T

図5 D2T

図6 D2D

図6 D2D

D2Dのメリットは,バックアップが高速に行われることです。特にスナップショット機能を持っているディスクならば非常に高速なバックアップが可能です。


D2D2T

もっとも,ディスクを永続的なバックアップ媒体として使用することは,費用や耐久性の観点から問題がある場合も多いので,ディスクはあくまで仲介機能としてのみ使用して,最終的にテープに再コピーするD2D2Tというハイブリッド方式もあります。

これはテープとディスクの「いいとこ取り」を狙った方式です図7)⁠まず,D2Dによってディスクへのコピーが終わった時点で,DBサーバと業務データの入ったディスク(D1)はバックアップ処理から解放されるため,実質的にバックアップ時間が短縮されます。後半のD2Tによるテープへのコピーは,あとでゆっくりやってもかまわないからです。また,いざ障害発生時においても,中間のディスク(D2)に最新世代のバックアップが残っているため,これを利用することで高速なリカバリが可能になるというメリットがあります。実装方式は最も複雑ですが,こうした大きなメリットが得られるため,近年,採用が増えている方式です。

図7 D2D2T

図7 D2D2T

そのほかのバックアップの分類

本稿で解説した3つ(統合フルバックアップも入れると4つ)のバックアップの種類以外にも「~バックアップ」と名前の付く分類がいくつかあります。このコラムではそれらについて簡単に解説しておきます。

コールドバックアップ/ホットバックアップ

まず,コールドバックアップ/ホットバックアップという区別があります。これはバックアップを取るときのデータベースの状態を基準にした分類です。データベースを停止させて,ほかのアプリケーションからのアクセスがない状態で取得するのがコールドバックアップ,データベースが稼働していてほかのアプリケーションからアクセス可能な状態で取得するのがホットバックアップと呼ばれます。これらは,オフラインバックアップ/オンラインバックアップという名前でも呼ばれますが,同じ意味です。コールドバックアップにおいてはバックアップ中にデータが変更される可能性がないため,データの一貫性が保証されます。そのため,これによって取得したファイルは,リカバリ時のベースファイルとして使うことができます。フルバックアップは原則としてコールドバックアップによって取得されます。

物理バックアップ/論理バックアップ

ほかによく目にする分類として,物理バックアップ/論理バックアップというのもあります。これは,バックアップを取得する手段を基準にした分類です。物理バックアップというのは,平たく言ってファイルそのものをコピーする方法です。Windows ならcopy,UNIX/Linux ならcpやtar といったOSコマンドを使えばOKです。

一方,論理バックアップとはデータの中身注aを取得することで,DBMSが用意している専用のコマンドで行います。そのため,論理バックアップは必然的にホットバックアップとなります(これが意味することは,基本的に,論理バックアップをリカバリ時のベースバックアップに使うことはできない,ということです)⁠

DBMSが用意している論理バックアップのコマンドには表aのようなものがあります。それぞれ,DBMSが提供するコマンドラインインタフェースから実行できます。

注a)
データの中身,というと漠然としていますが,要するにバックアップ時点のデータを復旧するDDLData Definition LanguageやDMLData Manipulation Languageと考えるとイメージがわくでしょう。実際,PostgreSQL では出力形式にテキストを指定すると,INSERT 文などのDML が出力されるので,ファイルをエディタで開いて確認できます。

表a  DBMSが用意している論理バックアップコマンド

DBMS論理バックアップのコマンド
Oracleexp
SQL Serverbcp
DB2export
PostgreSQLpg_dump
MySQLmysqldump

著者プロフィール

ミック

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

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

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

コメント

コメントの記入