データベースをバックアップするためのガイド

「ああ、流星の衝撃に耐えられる避難所はありません。しかし、皆さんと同じように、あなたには予備がありますので、心配しないでください。



スタニスラフ・レム、「ティキイのイヨンの星日記」

バックアップとは、データのコピーをプライマリストレージの場所以外の場所に保持することです。







バックアップの主な目的は、データが失われた後にデータを復元することです。この点で、データベースのレプリカがあれば、いつでもそこからデータを復元でき、バックアップは必要ないとよく耳にします。実際、バックアップを使用すると、レプリカを使用して解決できない少なくとも3つのタスクを解決でき、バックアップなしでレプリカを初期化することはできません。



まず、バックアップを使用すると、論理エラーの後にデータを回復できます。たとえば、会計士がトランザクションのグループを削除したり、DBAがテーブルスペースを破壊したりします。どちらの操作もデータベースの観点からは完全に正当であり、レプリケーションプロセスはそれらをレプリカデータベースに複製します。



次に、最新のDBMSは非常に信頼性の高いソフトウェアシステムですが、データベースの内部構造が損傷することがあり、その後、データへのアクセスが失われます。特に不快なのは、このような違反は通常、高負荷時または何らかの更新のインストール時に発生します。ただし、高負荷と定期的な更新はどちらも、データベースがテストデータベースではなく、そこに保存されているデータが貴重であることを示しています。



最後に、その解決策にバックアップコピーが必要な、3番目のタスクは、たとえばテスト目的でデータベースのクローンを作成することです。



データベースのバックアップは、次の2つの原則のいずれかに基づいています。

• データをフェッチし、その後任意の形式で保存します。
• データベースファイルのスナップショットとログの保存。

これらの原則とそれらを実装するツールを詳しく見てみましょう。

データのアップロード

DBMSに付属する一連のユーティリティには、データをアップロードおよびダウンロードするためのツールが必要です。データは、テキスト形式または特定のDBMSに固有のバイナリ形式で保存されます。次の表に、これらのツールを示します。





テキスト形式の良いところは、外部プログラムで編集または作成できることです。バイナリ形式は、フォーマット変換での並列ロードとリソースの節約により、データのアンロードとロードを高速化できるため、優れています。



データをダウンロードするというアイデアの単純さと明白さにもかかわらず、この方法は、ロードされた産業基盤をバックアップするために使用されることはめったにありません。オフロードが完全バックアップに適していない理由は次のとおりです。

• アンロードプロセスは、ソースシステムに大きな負荷をかけます。
• アンロードには多くの時間がかかります。アンロードが終了するまでに、それは無関係になります。
• DBMSは、アンロードの開始時にその状態のスナップショットを保持する必要があるため、高負荷の下でデータベース全体を一貫してアンロードすることはほとんど不可能です。アップロードの開始以降にコミットされたトランザクションが多いほど、スナップショットのボリュームが大きくなります（PostgreSQLのデータの無関係なコピー、Oracleの元に戻すスペース、Microsoft SQL Serverのtempdbなど）。
• アンロードは、データの論理構造を保持しますが、物理構造（テーブル、インデックスなどの物理ストレージのパラメーター）は保持しません。起動時にインデックスを再構築するには、長い時間がかかる場合があります。

それにもかかわらず、アンロードには利点があります。

• 高い選択性：個々のテーブル、個々のフィールド、さらには個々の行をアンロードできます。
• アップロードされたデータは、別のバージョンのデータベースにロードできます。アップロードがテキスト形式で行われている場合は、別のデータベースにロードできます。

したがって、アンロードは主に、小さなテーブル（ディレクトリなど）のバックアップや、アプリケーションの次のリリースでのデータセットの配布などのタスクに使用されます。



データベースをバックアップするための最も一般的な方法は、データベースファイルをコピーすることです。

データベースファイルの「コールド」保存

明らかなアイデアは、データベースを停止し、そのすべてのファイルをコピーすることです。これはコールドバックアップと呼ばれます。この方法は非常に信頼性が高くシンプルですが、2つの明らかな欠点があります。

• コールドバックアップからは、シャットダウン時のデータベースの状態のみを復元できます。データベースの再起動後に行われたトランザクションは、「コールド」バックアップには含まれません。
• データベースを停止できる場合、すべてのデータベースに技術的なウィンドウがあるわけではありません。

コールドバックアップに満足している場合は、次のことを覚えておいてください。

• «» . , «» , . , Oracle online redo, , , . PostgreSQL , , .
• , . , «» .

«»

最新のデータベースバックアップのほとんどは、データベースを停止せずにデータベースファイルをコピーすることによって実行されます。ここにいくつかの問題があります。

• 一部の情報はキャッシュにあり、まだディスクに書き込まれていないため、コピーの開始時に、データベースの内容がファイルの内容と一致しない場合があります。
• コピー中に、データベースの内容が変更される場合があります。可変データ構造が使用されている場合、ファイルの内容が変更され、不変構造が使用されている場合、ファイルのセットが変更されます。新しいファイルが表示され、古いファイルが削除されます。
• データベースへのデータの書き込みとデータベースファイルの読み取りは同期されていないため、バックアッププログラムは誤ったページを読み取る可能性があり、半分は古いバージョンのページから、残りの半分は新しいバージョンからのものになります。

バックアップの一貫性を保つために、各DBMSには、バックアッププロセスが開始されたことを通知するコマンドがあります。構文的には、このコマンドは異なって見える場合があります。

• Oracleでは、これは別個のコマンドALTER DATABASE / TABLESPACE BEGINBACKUPです。
• PostgreSQLでは、pg_start_backup（）関数。
• Microsoft SQL ServerおよびDB2では、バックアップの準備はBACKUPDATABASEコマンド中に暗黙的に行われます。
• MySQL Enterprise、Percoba Server、Cassandra、およびMongoDBでは、準備は外部ユーティリティ（それぞれ、mysqlbackup、Percona XtraBackup、OpsCenter、およびOps Manager）によって暗黙的に実行されます。

構文の違いにもかかわらず、バックアップの準備プロセスは同じように見えます。



これは、可変ディスク構造を持つDBMS、つまりすべての従来のディスクリレーショナルシステムでのバックアップの準備がどのように見えるかを示しています。

1. バックアップが開始された瞬間が記憶されます。今後、バックアップにはデータベースログが含まれる必要があります。
2. チェックポイントが実行されます。つまり、その時点までにデータページで発生したすべての変更がディスクにフラッシュされます。これにより、リカバリ中にバックアップを開始する前にログが不要になります。
3. : , , , . , . , . , , .
4. , , . , , .

上記のすべての手順が完了したら、オペレーティングシステムツール（cp、rsyncなど）を使用してデータファイルをコピーできます。バックアップモードを有効にすると、データベースのパフォーマンスが低下します。まず、ログの量が増加し、次に、バックアップモードで突然障害が発生した場合、データファイルのヘッダーが更新されないため、リカバリに時間がかかります。バックアップの完了が速ければ速いほど、データベースにとっては良いので、ファイルシステムのスナップショットやディスクアレイのミラーブレーク（BCV）などのツールを使用するのが適切です。一部のDBMS（Oracle、PostgreSQL）では、管理者がコピー方法を個別に選択する機会があります。その他（Microsoft SQL Server）は、ネイティブバックアップユーティリティをファイルシステムまたはストレージエンジンと統合するためのインターフェイスを提供します。



バックアップの最後に、データベースを通常の状態に戻す必要があります。Oracleでは、これはALTER DATABASE / TABLESPACE END BACKUPコマンドを使用して、PostgreSQLではpg_stop_backup（）関数を呼び出すことによって、他のデータベースでは、対応するコマンドまたは外部サービスの内部ルーチンによって実行されます。



バックアッププロセスのタイムラインは次のようになります。

• バックアップの準備（バックアップの開始）には時間がかかり、場合によってはかなりの時間がかかります。ミラーリングされたボリュームまたはスナップショットファイルシステムが使用されている場合でも、バックアッププロセスは瞬時には行われません。
• バックアップの準備が始まった瞬間から、データベースが通常の状態に戻った瞬間までのログをデータファイルと一緒に保存する必要があります。
• データベースが通常の状態に戻ったときに、このバックアップから回復できます。以前の瞬間に回復することはできません。

不変のデータ構造（スナップショット、LSMツリー）を使用するデータベースを使用すると、状況が簡単になります。バックアップの準備は、次の手順で構成されます。

1. メモリからのデータはディスクにフラッシュされます。
2. バックアップに含まれるファイルのリストが記録されます。バックアッププロセスが終了するまで、データベースはこれらのファイルが不要になった場合でも削除することを禁止されています。

バックアップの終了を通知すると、不変の構造を持つデータベースは、不要なファイルを再び削除できます。

ポイント回復

バックアップを使用すると、データベースの状態を、バックアップモードから戻るコマンドが完了した瞬間に復元できます。ただし、回復が必要な災害はいつでも発生する可能性があります。データベースの状態を任意の時点に復元するタスクは、「ポイントインタイムリカバリ」と呼ばれます。



これを行うには、バックアップが終了した瞬間からデータベースログを保存し、復元プロセス中に復元されたコピーにログを適用し続ける必要があります。コピーの最後にバックアップコピーからデータベースが復元された後、データベースの状態（ファイルとキャッシュされたページ）が正しいことが保証されるため、特別なロギングモードは必要ありません。必要な時点までログを適用することにより、任意の時点でデータベースの状態を取得できます。



バックアップの復元速度がディスク帯域幅によってのみ制限される場合、ログの適用速度は通常、プロセッサのパフォーマンスによって制限されます。メインデータベースの変更が並行して発生した場合、リカバリ中に、すべての変更がログから読み取られた順序で順番に実行されます。したがって、リカバリ時間は、リカバリポイントがバックアップのエンドポイントからどれだけ離れているかに直線的に依存します。このため、完全なバックアップを頻繁に作成する必要があります。トランザクションの負荷が低いデータベースの場合は少なくとも週に1回、負荷の高いデータベースを毎日コピーする前に作成する必要があります。

インクリメンタルバックアップ

ポイントツーポイントリカバリを高速化するために、できるだけ頻繁にバックアップできるようにしたいのですが、同時に、余分なディスクスペースを占有したり、バックアップタスクでデータベースに負担をかけたりしないようにします。



この問題の解決策は、増分バックアップです。つまり、前回のバックアップ以降に変更されたデータページのみをコピーします。

インクリメンタルバックアップは、可変データ構造を使用するDBMSに対してのみ意味があります。



増分は、完全バックアップ（累積コピー）と以前のコピー（差分コピー）の両方から計算できます。







残念ながら、統一された用語はなく、メーカーごとに異なる用語が使用されています。





インクリメンタルバックアップの場合、ポイントツーポイント復元プロセスは次のようになります。

• 復元が復元される前に行われた最後の完全バックアップ。
• インクリメンタルコピーはフルコピーよりも復元されます。
• バックアップが開始された時点から回復の時点までログをロールします。

累積コピーがあると、リカバリプロセスが高速化されます。したがって、たとえば、基本状態をT3とT4の間のポイントに復元するには、2つの増分コピーを復元し、T4の後のポイント（1つだけ）に復元する必要があります。

一部のページは数回変更されており、各増分コピーには独自のバージョンのページが含まれているため、明らかに、1つの累積コピーのボリュームは複数の差分コピーのボリュームよりも少なくなります。



インクリメンタルコピーを作成するには、次の3つの方法があります。

1. フルコピーを作成し、前のフルコピーとの差を計算します。
2. ログの解析、変更されたページのリストの作成、およびリストに含まれるページのバックアップ。
3. データベース内の変更されたページの要求。

最初の方法はディスクスペースを節約しますが、データベースの負荷を減らすという問題を解決しません。さらに、完全バックアップがある場合、それを増分バックアップに変えることは無意味です。完全バックアップの復元は、前の完全コピーと増分を復元するよりも高速だからです。このアプローチでは、ディスク領域を節約するタスクを、組み込みの重複排除メカニズムを備えた特別なコンポーネントにシフトすることをお勧めします。これらは、特別なストレージシステム（EMC DataDomain、HPE StorageWorks VLS、NetAppライン全体）またはソフトウェア製品（ZFS、Veritas NetBackup PureFile、Windows Serverデータ重複排除）のいずれかです。



2番目と3番目の方法は、変更されたページのリストを決定するメカニズムが異なります。ログの解析はより多くのリソースを消費します。さらに、ログを実装するにはログファイルの構造を知る必要があります。どのページが変更されたかをデータベース自体に確認するのが最も簡単ですが、このためには、DBMSカーネルに変更されたブロックを追跡する機能（ブロック変更追跡）が必要です。



インクリメンタルバックアップ機能は、Oracle8iリリースで導入されたOracleRecovery Manager（RMAN）ソフトウェアで最初に導入されました。 Oracleは変更されたブロック追跡をすぐに実装したため、ログを解析する必要はありません。



PostgreSQLは変更されたブロックを追跡しないため、ロシアの会社Postgres Professionalによって開発されたpg_probackupユーティリティは、ログを分析することによって変更されたページを検出します。ただし、同社は、ページの変更を追跡するptrack拡張機能を含むPostgresProも提供しています。 PostgresProでpg_probackupを使用する場合、ユーティリティは、RMANと同様に、データベース自体に変更されたページを照会します。



Oracleと同様に、Microsoft SQL Serverは変更されたページを追跡しますが、BACKUPコマンドは完全な累積バックアップのみを許可します。



DB2には変更されたページを追跡する機能がありますが、デフォルトでは無効になっています。有効にすると、DB2は完全、差分、および累積バックアップを許可します。



このセクションで説明するツール（pg_probackupを除く）とファイルベースのバックアップツールの重要な違いは、ディスク自体からデータを読み取るのではなく、データベースにページイメージを照会することです。このアプローチの欠点は、ベースにかかる追加の負荷が小さいことです。ただし、この欠点は、読み取られたページが常に正しいという事実によって十分に補われるため、バックアップ中に特別なジャーナルモードを有効にする必要はありません。



増分バックアップの存在は、ログを任意の時点に復元するための要件に置き換わるものではないことに再度注意してください。したがって、産業用データベースでは、ログは常に外部メディアに書き換えられ、完全または増分、あるいはその両方のバックアップがスケジュールに従って作成されます。



今日のインクリメンタルバックアップのアイデアの最良の実装は、ゼロデータロスリカバリアプライアンス（Oracleの用語では-エンジニアリングシステム）-独自のデータベースをバックアップするための特殊なOracleソリューションです。コンプレックスは、Recovery Managerソフトウェアの修正バージョンがインストールされ、他のOracleソフトウェアとハ​​ードウェアコンプレックス（Database Appliance、Exadata、SPARC Supercluster）、および従来のインフラストラクチャ上のOracleデータベースの両方で動作できる大量のディスクを備えたサーバーのクラスターです。 「通常の」RMANとは異なり、ZDLRAは「永遠にインクリメンタル」の概念を実装しています。システムはデータベースの完全なコピーを1回だけ作成し、次に増分コピーのみを作成します。追加のRMANモジュールを使用すると、コピーをマージできます。インクリメンタルコピーから新しいフルコピーを作成します。



ロシアの開発者の功績により、pg_probackupはインクリメンタルコピーを結合することもできることに注意してください。







多くの同様の質問とは異なり、「どのバックアップ方法が優れているか」という質問には明確な答えがあります。インクリメンタルバックアップ機能を提供する使用済みDBMSのネイティブユーティリティが最適です。



DBAにとって最も重要な問題は、バックアップ戦略の選択と、データベースバックアップの企業インフラストラクチャへの統合です。しかし、これらの質問はこの記事の範囲を超えています。