バックアップの種類

データベースのバックアップは以下の3つの方法を組み合わせて行うことが一般的です。

  • フルバックアップ
  • 差分バックアップ
  • 増分バックアップ

今回はそれぞれのバックアップ方法の仕組みについて見ていきます。

フルバックアップ

完全バックアップとも呼ばれ、あらゆるバックアップ方法の基本となり、最も単純な方法です。
文字通り、ある時点でのデータベース内に保持されているすべてのデータをバックアップするものです。そのため、このバックアップファイルさえあれば、その時点のデータをすべて復旧させることが可能です。

フルバックアップ

上図では月~土曜まで毎日フルバックアップを取得しており、日曜日に障害が発生した場合の例です。この例の場合、バックアップから最新の状態に戻すために必要なのは「F」のバックアップファイルのみです。

非常にシンプルでわかりやすいバックアップ方法ですが、中・大規模システムにおいては、この方法のみでバックアップ運用することはまずありません。それは以下のようなデメリットがあるため、実質、運用が不可能なためです。

  1. バックアップに時間がかかる
  2. ハードウェアリソースへの負荷が高い
  3. サービス停止が必要

データベース内の全てのデータをバックアップするには、それなりに時間がかかります。その間、ストレージのディスクI/OやサーバーのCPU、メモリーの使用量も増えるため、各種リソースに負荷がかかります。そして何より、バックアップ取得中はデータベースを閉塞しないといけないため、(基本的に)サービス停止も必要になり、24時間365日の連続稼動が一般的なってきている昨今においては、致命的なデメリットとなります。

本来は、フルバックアップで運用する方法が最も簡単でわかりやすいのですが、上述したようにデメリットがあるため、それだけで運用するのは困難です。そこで通常は、フルバックアップを基本として、差分バックアップや増分バックアップと組み合わせた運用を行います。

フルバックアップは通常、DBMSが用意しているバックアップ機能を用いて行ないます。

差分バックアップ

最新のフルバックアップ以降に変更されたデータのみをバックアップする方法です。

差分バックアップ

上図では月曜日にフルバックアップを取得し、火~土までは月曜から変更が発生した分だけのバックアップを取得しています。この例のように、日曜日に障害が起きた場合、最新データを復旧するためにはフルバックアップファイルである「A」と差分バックアップファイルの「F」の2つが必要となります。

フルバックアップよりはバックアップにかかる時間は減りますが、リカバリのためにフルバックアップファイルに加えて差分バックファイルも必要となり、運用の煩雑さが増してしまいます。

差分バックアップは、フルバックアップ以降のトランザクションログをバックアップすることで実現できます。

増分バックアップ

前回のバックアップ以降に変更されたファイルのみをバックアップする方法です。差分バックアップは、フルバックアップを取得してからの変更データを取得するため、無駄が生じてしまいます。上図を見ればわかるようにフルバックアップを取得した翌日である火曜日はバックアップ対象データは少なく済みますが、土曜日になると火曜日~金曜日分の変更データも対象となり、効率が悪くなります。その無駄をなくしたのが増分バックアップです。

増分バックアップ

このバックアップ方法のメリットは、日々の変更分のみがバックアップ対象となるため、バックアップ時間が最もかからない点です。しかしその反面、リカバリにかかる時間が最も長くなってしまいます。理由は明瞭で、リカバリのためには、A~Fまでの全てのファイルが必要となるためです。また、A~Fのどれか1つでも壊れていたら,復旧できなくなるのもデメリットのひとつです。その対策として、バックアップのバックアップを取得するなどの手段を取ります。

増分バックアップは、前回のバックアップ以降のトランザクションログのみをバックアップすることで実現できます。

最適なバックアップ方法は?

最後にデータベース運用において最適なバックアップ方法は何なのかを考えてみます。

バックアップ方法は以下の3つが考えられます。

  1. フルバックアップのみ
  2. フルバックアップ + 差分バックアップ
  3. フルバックアップ + 増分バックアップ

この中から最適な方法を決めるためには、許容されるバックアップ時間およびリカバリ時間などを決めておく必要があります。

フルバックアップはバックアップ時間がかかりすぎるので、現実的には「2」か「3」の方法になります。

「3」の方法がバックアップの観点からみると最も効率的ですが、リカバリの観点からみると最も非効率となってしまいます。

リカバリ作業中は当然システムは停止しているわけで、1秒でも早く復旧させなければなりません。わたしも経験がありますが、その際のプレッシャーはとてつもないものです。オペレーションしているすぐ後ろではお客さんを含めたいろんな人がまだかまだかと無言のプレッシャーをかけながらモニターを覗き込んできて、手汗が尋常じゃありませんでした。人は追い込まれれば追い込まれるほど、普段では考えられないミスを犯します。

バックアップ設計を行なう上で大事なのはリカバリ要件を先に考えることです。そうすることで最適なバックアップ方法が自然と見えてきます。