バックアップとは

データベースシステムの障害や操作ミスなどに備えて、データの複製を作成することです。対象はアプリケーションに使われているデータのみの場合や、データベースのユーザーや権限などの定義データ、データファイル、定義ファイル、トランザクションのログファイルなど多岐に渡り、システム要件に合わせてバックアップ対象を検討することが必要です。

データベース管理者にとって、データベースに格納されたデータをいかに守るかは重要なテーマで、バックアップはデータベース運用において重要な仕事の一つです。ダウンタイムやパフォーマンスの低下を起こさないためにもバックアップを最初から計画し設計しておく必要があります。

バックアップが必要な理由

システムのクラッシュ、ハードウェアの障害、誤ったデータ操作による削除などの問題が発生した場合に備え、データを復旧して元に戻せるようにデータベースをバックアップすることが重要です。その代表的な理由は以下のようなものです。

障害からの復旧

バックアップの最も一般的な理由は障害から復旧することです。障害とは何か、データの重要な部分が壊れたり利用できなくなったりすることを指しています。

障害の例

ハードウェアの異常
ソフトウェアの異常
データの誤った削除
サーバーの故障

しかし、この動機は実際には他の理由ほど重要でないことが多くなっています。AWSやGCPといったクラウド環境を利用することが多い現代では、物理サーバーを運用することに比べ、障害が発生することが少なくなっています。

データの分析、調査、チューニング

サービスを運用していると、過去のある時点に戻ってデータベースのテーブルやレコードがどのような状態であったかを分析したいことがあります。バックアップがあれば過去の状態を調べることが可能となります。適切なデータをテストサーバーに戻してプロダクション環境に影響与えずデータを分析、調査することができるようになります。パフォーマンスに影響与えるような遅いクエリを実行したい時や、遅いクエリをチューニングしたい時も同様に役に立ちます。

また、開発の過程でテストを実施することにも利用できます。

レプリケーションの実施

MySQLではデータを別のサーバーに転送したりレプリケーションのスレーブサーバーをセットアップするために使用することもできます。

突発的なことへの対応

サービスにとって重要な顧客が誤って（または自分の意志で）何らかのデータを削除したけれど、それをもとに戻したくなることは少なくありません。また、訴訟や法的な要件により過去のある時点のデータベースの状態を知る必要が生じることもあります。

バックアップからのリカバリー

リカバリーが大切

バックアップが必要な理由を述べてきましたが、バックアップ以上に大切なのがリカバリーです。優れたバックアップシステムがあっとしても、リカバリーが機能していないとそれは意味がありません。リカバリーシステムがスムーズに機能することは、バックアップシステムを構築するよりも大切なことなのです。しかし、リカバリーよりもバックアップが優先されてしまうには以下のような背景があります。

手順としてはバックアップが先です。バックアップがないとリカバリーは実施できません。そのためバックアップの作成を優先してしまいます。しかしリカバリーの要件、目的を達成するためにバックアップは存在します。まずはリカバリーの要件を洗い出さなければなりません。
バックアップは日常的な作業になりえます。バックアッププロセスの自動化や調整は日々の作業で最適化されていきます。しかしリカバリー作業は日常的に発生しません。意図的にリカバリープロセスを調整していかないと、スムーズなリカバリーシステムを構築することはできません。
バックアップは日常的な状況で行われますが、リカバリーは危機的状況に行われます。それも突発的に発生します。
バックアップは誰でもできる作業にしやすいですが、リカバリーは属人性が高くなる傾向にあります。日々のトレーニングや仕組みによって、リカバリー作業を複数のスタッフが行えるようにしておく必要があります。

障害が発生した場合に備えてバックアップを作成しますが、いざ障害が発生した時にバックアップから障害発生の直前の状態にもどすためにはリカバリーについてよく知る必要があります。

リカバリーの要件

リカバリーについて検討するためには、まずリカバリー要件を定義することが大切です。例えば次のようなことを検討します。

データの損失がどの程度許容できるか。Point-In-Time リカバリは必要か、それとも標準バックアップ以降に発生した作業が失われても容認できるか。
リカバリーはどれくらい素早く実施できるか。ダウンタイムがどれくらいなら許容できるか。
アプリケーションとユーザーが受け入れることができるのはどのような影響か（一部の機能が使えない、など）。また、そのよう状況でも引き続き稼働するには、どうすればよいか。
リカバリが必要なのはなにか。サーバー全体、1つのデータベース、1つのテーブル、など。

心情としてはいかなる損失も許容せず、迅速なリカバリーを実施したいところですが、人的リソースやバックアップにかかる費用などを踏まえ現実的な選択をすることが大切です。

リカバリーに必要なもの

バックアップはある時点でのデータベースの状態なので、障害発生の直前までにはズレがあります。そのズレを埋めるために必要なのが更新ログで、この2つを組み合わせてバックアップ時点以降の任意の状態にデータベースを復旧することが可能となります。一般的にロールフォワードによるリカバリーと呼ばれます。

バックアップの種類

バックアップにはデータベースサーバーの状態や、バックアップデータのフォーマットなどで分類できる様々な方法があります。

データベースサーバーの状態による分類

ホットバックアップ

ホットバックアップはデータベースサーバーを停止させずにバックアップを行う方法です。データが多い場合はバックアップに時間がかかる為、バックアップ作成中にデータが更新される可能性があります。バックアップ中にデータの整合性を失うような変化が行われないように適切にロックを行うよう注意する必要があります。オンラインバックアップとも呼ばれます。

コールドバックアップ

コールドバックアップはデータベースサーバーを停止してバックアップを行う方法です。サーバーが停止しているのでデータファイルをそのままコピーすることが可能なので、最も速く簡潔なバックアップの方法の1つです。ただしサーバーを停止する必要があるためあらかじめ予定されたメンテナンス期間など限られた場面だけで利用可能です。

バックアップ中にサーバーが使用できないためクライアントが悪影響受ける可能性があります。そのためオフラインにすることができるレプリケーションサーバーから取得することでこれを回避することもできます。

オフラインバックアップとも呼ばれます。

バックアップデータのフォーマットによる分類

物理バックアップ

物理バックアップはサーバーのデータファイル自体をバックアップする方法です。データベースの内容を格納するディレクトリとファイルのコピーで構成され、OSのファイルコピー機能を使って実施することができます。バックアップにはログや構成ファイルなどの関連ファイルも含めることができます。

利点としては最小限のサイズで取得できる点と、バックアップとリストアにかかる時間が最も短くできるという点です。一方欠点はバックアップやリストアする単位はツールに依存するため、自由度が低い場合があります。また、バージョンの異なるサーバーやマシンの間では互換性が取れない場合があります。

このバックアップは問題が発生した場合に短時間で回復することができるので、大規模で重要なデータベースに適しています。

論理バックアップ

データベースからデータを抜き出してバックアップする方法です。データベースに格納されているテーブルのデータやテーブルを構築するためのSQLを出力します。 SQL文を用いて記述されるためバージョン間の互換性が高く、他のRDBMSにも移植することができます。また、バックアップ内容をテキストで出力するので人間が見て判断することができます。

一方、物理バックアップに比べサイズが大きくなりやすく、またリストアにかかる時間がとても大きくなってしまいます。リストア時にテキストデータをバイナリデータに変換したり、インデックスの作成等の処理を行う必要があるためサーバーにかかる負荷も大きくなります。

バックアップの取得方式による分類

フルバックアップ

ある時点のデータベースの内容をすべてを対象としたバックアップです。すべてが対象となるためバックアップにかかる時間が長くなりデータサイズも大きくなりますが、リストアの処理が単純になります。安全性としては最も高くなりますが、データの増加に比例してバックアップにかかる時間が長くなります。

差分バックアップ

直前のフルバックアップ以降に更新されたデータのみのバックアップです。更新されたデータのみを対象にするため、バックアップにかかる時間が短くなり、データのサイズも小さくなります。更新された部分のみが対象となるため、単体だけではデータをリカバリーすることはできません。リストア時には直前のフルバックアップと合わせて行う必要があり手順が複雑になる傾向にあります。