バックアップデータベース作成時によくある12の間違い

著者：Alexey Kovyazin、2015年11月11日

PDFをダウンロード（英語） この記事は当初Firebird DBMSの開発者と管理者を対象としていましたが、他のデータベースの管理者とのやり取りを通じて、ほとんどの間違いは彼らにも共通しており、文字通り誰もがほぼ同じ石につまずくことが明らかになりました。このリストに何か追加できる場合（特定のDBMSに固有のものでも構いません）、メール[email protected]でご連絡ください。

1. 新しいバックアップコピーが作成される前に以前のバックアップコピーを削除する

この間違いは、データベースのバックアップコピーの主な目的が単にデータベースのコピーを作成することではなく、情報システム（その重要な一部がデータベースである）のダウンタイムを可能な限り短くすることであると理解していない初心者に最もよく見られます。

その結果、最新のバックアップコピーが削除された瞬間から新しいコピーが作成される瞬間まで、システムは保護されないままになります。なぜなら、この期間中データベースにはバックアップコピーが一つも存在しないからです。バックアップコピーの作成にはかなりの時間がかかる可能性があるため、これはマーフィーの法則が発動する絶好のタイミングです。このアプローチは、下記の問題7と組み合わせると特に効果的です。

推奨事項：新しいバックアップコピーが作成されるまで、以前のバックアップコピーを削除しないでください！（また、既存のファイルに新しいバックアップコピーを作成しないでください）。

Firebird向けの推奨事項：HQbird（Firebirdの高度な配布パッケージ）に含まれるFBDataGuardツールは、新しいバックアップコピーが作成された後にのみ履歴内の最も古いバックアップコピーを削除します。

2. バックアップコピーからの復元中に既存のデータベースを上書きする

この間違いはあまり一般的ではありませんが、結果ははるかに悪いものになる可能性があります。バックアップコピーが検証されておらず、破損していることが判明した場合（問題6を参照）、以前のデータベースのコピーも有効なバックアップコピーも失うことになります。

このような混乱は通常、金曜日の夕方に発生します。物事が慌ただしくなり、経営陣からの指示が矛盾したものになる時期です。少し不運があれば、サーバールームでののんびりした週末が待っています。

Firebirdにはこの間違いに対する一種の保護があります。gbakユーティリティのデフォルトの-createスイッチがオンで、指定されたファイル名が既存のデータベースを指している場合、バックアップコピーからデータベースを復元することはできません。残念ながら、この保護を回避する方法があります：-repスイッチを使用すると、既存のファイルを上書きできます。

推奨事項：経営陣からの書面による指示なしに、稼働中のデータベースのファイルを上書きしないでください。

Firebird向けの推奨事項：FBDataGuardはデータベースファイルを決して上書きしないため、これを使用してください。

3. 中間バックアップファイルを使用しないワンステップのバックアップ/リストア

標準入出力ストリームにより、多くのDBMS（Firebirdを含む）で面白いトリックが可能です：ストリーミングバックアップを実装し、そこからデータベースを即座に復元します。その結果、中間バックアップファイルは作成されません。これは日常のメンテナンスやテスト復元操作の実行（別のバックアップコピーが利用可能な場合）には便利ですが、自動バックアップには使用してはいけません！

例えば、このバックアップ/リストアプロセス中に深刻なディスク障害が発生した場合、初期データベースが損傷する可能性があり、新しいデータベースはまだ作成されていません。もちろん、問題1を考慮して前回の試行からのデータベースコピーが存在する場合、そのコピーが作成された後にデータベースで作成または更新されたデータのみが失われます。

推奨事項：自動モードでワンステップのバックアップ/リストアを使用せず、手動モードでは常に十分に新しいコピーの可用性を確認してください。

4. バックアップコピーとデータベースを同じ物理デバイスに保存する

私たちのアドバイスが幼稚なもの（バックアップのABC）だと感じる方も多いかもしれません。その通りですが、仮想環境の人気により、データベースとディスクが同じデータストレージシステムに保存されることになる可能性があります。そして、それは最も不適切な瞬間に確実に故障します。さらに、RAIDアレイ（バージョン1以上：）を使用すればデータに何も起こらないと信じている人々もまだいます。また、一部の「ブランド」サーバーは故障しないと信じている人々もいますが、それは特別なケースです。

推奨事項：どれほど信頼性が高く見えても、バックアップコピーとデータベースを同じデバイスに保存しないでください。

5. バックアッププロセスの正常完了の監視がない

これは管理者とIT部門の責任者の両方にかなり一般的な間違いです。バックアッププロセスの結果を確認しないのであれば、そもそもバックアップを実行しないのと同じです。バックアッププロセスが正常に完了したことをメールで通知を受け取る必要があります。できればSMSでも通知を受け取るのがさらに良いでしょう。そして、そのような通知がないことは問題の兆候です！

ここまで記事を読んだ注意深い読者（ただし、まだ賞を授与するには早すぎます）はこう尋ねるかもしれません：「それは経営陣と何の関係があるのですか？」ここにその答えがあります - 管理者は通常バックアッププロセスを設定しますが、特に通知が別のフォルダに保存されている場合、通知を確認するのは退屈だと感じます。そのため、プロセスのステータスに関する追加レポートを要求することは決して多すぎることはありません。バックアップコピーが存在するように見えたのに、必要な時に実際には存在しない場合、誰の責任なのかという問題に関係しています:)

！問題2と組み合わせると、データベースもそのバックアップコピーも失うことになります。

推奨事項：成功したバックアッププロセスと失敗したバックアッププロセスを監視し、問題をユーザーに通知し、サマリー管理ツールを提供するバックアップ自動化ツールを使用してください（異なるサーバー上の数十から数百のバックアッププロセスを管理する必要がある場合に特に重要です）。

Firebird向けの推奨事項：FBDataGuardはバックアッププロセスが完了したかどうかを確認し、対応する通知を送信します。多数のデータベースを持つシステムでは、Control Centerツールを使用した第2レベルのサマリー監視があり、監視対象のすべてのサーバーとデータベースのステータスを1つのページで確認できます。

6. バックアップの検証がない

バックアップコピーがどこかに保存されているという事実は、そこから読み取れることを意味しません。

そのため、作成したバックアップコピーが破損していないか、/dev/nullにコピーされていないかを確認するために、定期的に検証する必要があります。

Firebird向けの推奨事項：FBDataGuardを使用してバックアップ検証を自動化できます。

7. 未検証のバックアップコピーを使用したデータベースの健全性チェックがない

通常、データベースは複数のタイプのバックアップ（ダンプ、通常のバックアップコピーなど）を使用します。詳細には立ち入らずに、検証済みと未検証の2つのカテゴリに分類できます。Firebirdの場合、それはgbakとnbackupです。

Gbakはバックアップファイルを作成するためにレコードレベルでデータベース全体を読み取り、新しいデータベースにレコードを挿入してデータベースを作成することで、バックアップコピー（復元されたコピーにエラーが紛れ込む方法はありますが、それは組織化が不十分な移行に関連するデータベース管理者の別の失敗方法です）とデータベース自体（最初から最後まで読み取れる場合、おそらく破損していません）を検証します。

Nbackup（別名インクリメンタルバックアップ）は、メインデータベースファイルを更新用に一時的にロックし（一貫性のある状態で）、データベースファイルを（完全または部分的/増分的に）迅速にコピーできるようにします。

500 GBを超える大規模なFirebirdデータベースの場合、ユーザー操作を遅くしないためにnbackupを使用することをお勧めしますが、同時にデータベースを検証する必要があります。なぜなら、作成される未検証のバックアップコピーはデータベースページのコピーであり、レコードレベル（RAM障害による）または論理レベルでエラーが存在する場合、未検証のバックアップコピーには元のデータベースと同様にそのエラーが含まれるからです。

これを避けるためには、元のデータベースに対してオンライン検証を使用するべきです（gfixを使用したオンライン検証はFirebirdバージョン2.5.4以降で利用可能であり、当社のFBDataGuardツールはバージョン1.5〜2.5のオンラインデータベース検証をサポートしています）。

また、未検証のバックアップに加えて、検証済みバックアップを定期的に（たとえば週に1回）実行することをお勧めします。

Firebird向けの推奨事項: オンラインヘルスチェックに加えて、FBDataGuardを使用すると、自動モードでバックアップの復元プロセスをテストできます。

8. バックアップコピー用の空き容量を管理していない

実際、これは古典的な間違いです。十分な容量がない場合、バックアップコピーがすべての空き容量を占有し、プロセスがエラーで終了します。バックアップコピーをデータベースと同じディスクに保存すると、データベースの運用が中断される可能性があり、システムディスクに保存するとシステム障害が発生する可能性があります。

問題4と組み合わせると、最良の結果は、データベースも空き容量を必要とするのにバックアップコピーが占有しているためにシステムが機能停止するというものです。問題5および2との組み合わせでは、データベースもそのバックアップコピーも失うことになります。

推奨事項: バックアップサイズを予測し、空き容量の不足を警告するバックアップツールを使用してください。

Firebird向けの推奨事項: FBDataGuardは、バックアップ用の空き容量のサイズと、データベースが置かれているディスクおよびシステムディスクの空き容量のサイズを管理します。

9. バックアップコピーの作成にかかる時間を管理していない

ちょうど半年前はバックアッププロセスに40分かかっていたのに、突然3時間かかるようになったのはなぜでしょうか？データベースのサイズが増加したか、RAIDアレイからディスクが脱落して書き込みパフォーマンスが大幅に低下し、すべてのバックアップコピーが失われる寸前かもしれません。または、同僚が同時に別のバックアップシステムを実行したかもしれません（ちなみに、Firebirdでは複数のバックアッププロセスを同時に実行できますが、そもそもなぜそれが必要なのかはよくわかりません）。バックアップコピーの作成にかかる時間を管理していないと、新たに発生した問題を見逃し、それが大規模になる前に修正する機会を逃す可能性があります。

さらに、バックアップシステムがバックアップタスクのステータスを監視せず、スケジュールに従って実行するだけの場合、前のバックアッププロセスがまだ終了していないのに新しいバックアッププロセスを開始するという「早まった実行」が簡単に発生する可能性があります。

推奨事項: バックアッププロセスにかかる時間を管理するツールを使用してください！

Firebird向けの推奨事項: FBDataGuardはバックアッププロセスにかかる時間を管理します。

10. オペレーティングシステムの更新が適用されている間にデータベースをバックアップする

これは非常に一般的な問題であり、特に問題9と有効な自動Windows更新（デフォルトでは更新は午前3時に適用されます）と組み合わせると顕著です。最悪の場合でも速度低下を引き起こしますが、更新を適用するためにオペレーティングシステムが再起動されると、バックアップコピーが破損します。少なくとも、オペレーティングシステムが毎日更新されるわけではないという点は良いニュースです。

推奨事項: バックアッププロセスと干渉しない時間にオペレーティングシステムの更新をスケジュールしてください。

11. データベースサーバーが実行中にファイルバックアップツールまたは仮想マシンバックアップツールを使用してデータベースをバックアップする

多くの管理者は、あらゆるDBMSには、データベースファイル自体がランダムアクセスモードで開かれている間に読み書きされるデータを含む、アクティブで複雑なキャッシュがあることを忘れています。そのため、単純なファイルバックアップ（データベースファイルの単純なコピーを含む）や仮想マシンバックアップではなく、特別なバックアップタイプを使用する必要があります。ファイルバックアップツールはデータベースを順次読み取るため、特に大規模なデータベースの場合にはかなり時間がかかり、作成されたバックアップコピーの整合性を保証することは不可能です。

仮想マシンはスナップショットやChanged Block Trackingのメカニズムを使用できますが、一貫性のあるデータベースバックアップコピーを取得するには、作成されたバックアップコピーを同期する必要があります。変更されたブロックの収集を整理する時点でデータベースへのアクティブな書き込み操作がある場合、バックアップコピーは不整合になるためです。

ファイルまたは仮想マシンバックアップツールを使用してデータベースをバックアップしたい方には、2つの方法を提供できます：

1. DBMSサービスとプロセスを完全にシャットダウンして、キャッシュに何も残らないようにする、
2. データベースを特別なモードに切り替えて、データベースファイルを順次安全にコピーできるようにするエージェントやスクリプトを使用する。たとえば、MSSQLデータベースにはVSSライターと呼ばれるメカニズムがあります。要求に応じて、スナップショットが作成される時点でデータベースをスナップショット対応モードに切り替えます。Changed Block Trackingに基づくメカニズムを使用する場合は、同期の時点でデータベースが一貫性があることを自分で確認する必要があります。

データベースをバックアップ対応モードに切り替えない場合、結果として得られるデータベースコピーは、ホストコンピューターでハードリセット（たとえば停電）が発生したかのように見えます。このレベルの信頼性は、ほとんどの企業にとって絶対的に不十分です。詳細については、「仮想マシン上のデータベースの操作の特性」という記事で学ぶことができます。

Firebirdの場合、バックアッププロセスが開始される前にnbackupを使用してデータベースのメインファイルをロックし、プロセスが終了した後にロックを解除する必要があります。他のDBMSにも、対応するモードをオン/オフに切り替えるための同様のツールがあります。

一部のデータベース管理者は、DBMSにトランザクションログがある場合、標準のファイルバックアップツールを使用してデータベースを安全にバックアップできると確信しています。なぜなら、最悪の場合でもこのログだけが破損するからです。これは、DBMS開発者がサポートしていない危険な誤解です。

この誤解の根源は明らかです。仮想マシンやバックアップツールの開発者による積極的な広告では、データベースやその他の頻繁に更新されるファイルには高度な設定が必要であることが通常言及されていません。誇大広告を信じないでください。すべてのヨーグルトが同じ効果を持つわけではありません。

推奨事項: データベース用の対応する自動化ツールなしでファイルおよびVMバックアップツールを使用しないでください。

Firebird向けの推奨事項: FBDataGuard（HQbirdディストリビューションパッケージから）を使用してください。VSS対応のバックアップツールとの統合を提供します。

12. バックアップをレプリケーションに置き換える

データバックアップとデータレプリケーションは、信頼性を高め、データ損失を防ぐために使用されますが、それらはかなり異なります。

誰もがレプリケーションの、最小限の遅延で別のサーバー上のデータを同期できる能力を好みますが、バックアップにも紛れもない利点があります。たとえば、偶発的（または意図的な）データ削除の場合、レプリケーションは迅速かつ冷静に変更をレプリカに送信しますが、バックアップ（特に読み取り専用メディア上のコピー）はそのような操作の影響を受けません。レプリケーションとバックアップの両方を正しく設定するにはある程度の労力が必要であり、それでもエラーの可能性は常に存在します。

推奨事項: レプリケーションを設定している場合でも、バックアップコピーを軽視せず、両方を使用してください。

Firebird向けの推奨事項: HQbird Enterpriseディストリビューションパッケージを使用してください。バックアップツールとレプリケーションツールの両方が含まれています。

まとめ

お気に入りのDBMSのバックアップを設定するのはそれほど簡単ではないため、データを重視する組織のデータベース管理者は通常、上記の問題を考慮し、問題を防ぐことができるプロフェッショナルなバックアップツールを使用します。

Firebird向けには（宣伝をお許しください）、FBDataGuardを含むHQbirdというパッケージがあります。

また、当社はFirebirdおよびその他のデータベースの完全なバックアップおよびメンテナンスサポートを提供しています。これは、バックアップのすべての技術的詳細を知らない方にとって良い選択肢です。

そして、もちろん、管理者としてのパラノイアを大切にし続けてください。例えば、今すぐ立ち上がってバックアップコピーを確認しましょう :)

連絡先

ご質問がございましたら、お気軽にお問い合わせください: [email protected]

Firebirdに関するニュースや記事を受け取りたいですか？ Telegramで私たちに参加してください: https://t.me/firebirdsql