データベースのバックアップ時によくある12の間違い
Alexey Kovyazin著、2015年11月11日
PDFをダウンロード（英語） この記事は当初Firebird DBMSの開発者と管理者を対象としていましたが、他のデータベースの管理者とのやり取りから、ほとんどの間違いは彼らの間でも共通しており、文字通り誰もがほぼ同じ落とし穴につまずくことが明らかになりました。このリストに何か追加できることがあれば（特定のDBMSに固有のことであっても）、私たちのメール[email protected]までご連絡ください。
1. 新しいバックアップコピーが作成される前に前回のバックアップコピーを削除する
この間違いは、データベースのバックアップコピーの主な目的が単にデータベースのコピーを作成することではなく、情報システム（その重要な部分がデータベースです）のダウンタイムを可能な限り短くすることであると気づいていない初心者に最も多く見られます。
その結果、最新のバックアップコピーが削除された瞬間から新しいものが作成される瞬間まで、システムは無防備なままになります。なぜならこの期間中、データベースにはバックアップコピーが1つも存在しないからです。バックアップコピーの作成にはかなりの時間がかかる場合があるため、マーフィーの法則が発動する絶好のタイミングとなります。このアプローチは、問題7（以下参照）と組み合わせると特に効果を発揮します。
推奨事項: 新しいバックアップコピーが作成される前に前回のバックアップコピーを削除しないでください！（また、既存のファイルに新しいバックアップコピーを作成しないでください）。
Firebird向けの推奨事項: HQbird（Firebirdの高度なディストリビューションパッケージ）に含まれるFBDataGuardツールは、新しいバックアップコピーが作成された後にのみ、履歴の中で最も古いバックアップコピーを削除します。
2. バックアップコピーから復元する際に既存のデータベースを上書きする
この間違いはそれほど多くありませんが、結果ははるかに深刻になる可能性があります。バックアップコピーが検証されておらず、破損していることが判明した場合（問題6参照）、以前のデータベースのコピーも有効なバックアップコピーも失うことになります。
このような混乱は通常、物事が慌ただしくなり、経営陣からの指示がやや矛盾する金曜日の夕方に起こります。少しの不運が重なれば、サーバールームでの気だるい週末が待っています。
Firebirdにはこの間違いに対するある種の保護機能があります。デフォルトの-createスイッチがオンで、指定されたファイル名が既存のデータベースを指している場合、gbakユーティリティを使ってバックアップコピーからデータベースを復元することはできません。残念ながら、この保護を回避する方法があります。-repスイッチを使えば、既存のファイルを上書きすることが依然として可能です。
推奨事項: 経営陣からの書面による指示がない限り、稼働中のデータベースのファイルを決して上書きしないでください。
Firebird向けの推奨事項: FBDataGuardはデータベースファイルを決して上書きしないため、FBDataGuardを使用してください。
3. 中間バックアップファイルを使用せずにワンステップのバックアップ/リストアを使用する
標準の入出力ストリームにより、多くのDBMS（Firebirdを含む）で面白いトリックが可能になります。ストリーミングバックアップを実装し、そこからデータベースを一度に復元するのです。その結果、中間バックアップファイルは作成されません。日常的なメンテナンスやテスト復元操作の実行には便利ですが（別のバックアップコピーが利用可能であることが前提）、自動バックアップには使用してはいけません！
例えば、このバックアップ/リストア処理中に深刻なディスク障害が発生した場合、初期のデータベースが破損する一方で、新しいデータベースはまだ作成されていない可能性があります。もちろん、問題1を考慮して前回の試行からのデータベースコピーがあれば、そのコピーが作成された後にデータベースで作成または更新されたデータのみが失われます。
推奨事項: 自動モードではワンステップのバックアップ/リストアを使用せず、手動モードでは十分に最新のコピーが利用可能であることを常に確認してください。
4. バックアップコピーとデータベースを同一の物理デバイスに保存する
私たちのアドバイスがまるで子供じみているように感じる方も多いかもしれません。バックアップのいろはです。確かにその通りですが、仮想環境の普及により、データベースとディスクが同じデータストレージシステム上に保存されてしまうことがあります。そしてそれは必ず最も不適切な瞬間に故障します。さらに、RAIDアレイ（バージョン1以上 :)）を使用していればデータに何も起こり得ないと信じている人々も依然としています。また、一部の「ブランド」サーバーは故障しないと信じている人々もいますが、それは特殊なケースです。
推奨事項: どれほど信頼できるように見えても、バックアップコピーとデータベースを同じデバイスに保存しないでください。
5. バックアップ処理の正常完了に対する管理がない
これは管理者とIT部門の責任者の両方に共通するかなり一般的な間違いです。バックアップ処理の結果を確認しなければ、バックアップを実行しないのと同じです。バックアップ処理が正常に完了したことの通知をメールで、さらにはテキストメッセージでも受け取る必要があります。そして、そのような通知がないことは問題の兆候です！
ここまで記事を読んだ注意深い読者（ただし、それに対して賞を与えるにはまだ早いですが）はこう尋ねるかもしれません：「しかし、それが経営陣とどう関係するのですか？」それはこういうことです。管理者は通常バックアップ処理を設定しますが、通知の確認は特に別のフォルダに保存されている場合は退屈に感じるので、処理の状態に関する追加レポートを要求して損はありません。バックアップコピーがあったように見えて、実際に必要な瞬間には存在しない場合、誰の責任かという問題についてです :)
! 問題2と組み合わさると、データベースもそのバックアップコピーも存在しなくなります。
推奨事項: バックアップの成功と失敗を監視し、問題をユーザーに通知し、サマリー管理ツールを提供できるバックアップ自動化ツールを使用してください（異なるサーバー上の数十、数百のバックアップ処理を管理する必要がある場合に特に重要です）。
Firebird向けの推奨事項: FBDataGuardはバックアップ処理が完了したかどうかを確認し、対応する通知を送信します。多数のデータベースを持つシステム向けには、Control Centerツールによる第2レベルのサマリー監視があり、監視対象のすべてのサーバーとデータベースのステータスを1ページで確認できます。
6. バックアップの検証がない
バックアップコピーがどこかに保存されているという事実は、そこから読み取れることを意味するものではありません。
そのため、作成したバックアップコピーを定期的に検証し、破損していないこと、または/dev/nullにコピーされていないことを確認する必要があります。
Firebird向けの推奨事項: FBDataGuardを使用してバックアップの検証を自動化できます。
7. 検証されていないバックアップコピーを使用する際のデータベースの健全性チェックがない
通常、データベースではダンプ、定期的なバックアップコピーなど、いくつかの種類のバックアップが使用されます。詳細には立ち入らずに、検証済みと未検証の2つのカテゴリを挙げることができます。Firebirdの場合、それはgbakとnbackupです。
Gbakはバックアップファイルを作成するためにレコードレベルでデータベース全体を読み取り、新しいデータベースにレコードを挿入してデータベースを作成することで、バックアップコピーを検証します（復元されたコピーにエラーが紛れ込む方法はありますが、それは適切に組織されていない移行に関連してデータベース管理者が物事を台無しにする別の話です）。また、データベース自体も検証します（最初から最後まで読み取ることができれば、破損していない可能性が高いです）。
Nbackup（別名インクリメンタルバックアップ）は、メインデータベースファイルを一時的に（一貫性のある状態で）更新用にロックし、データベースファイルを迅速にコピー（完全または部分的/インクリメンタル）できるようにします。
大規模なFirebirdデータベース（500 GB以上）の場合、ユーザー操作を遅くしないためにnbackupを使用することが推奨されますが、同時にデータベースを検証する必要があります。なぜなら、それが作成する未検証のバックアップコピーはデータベースページのコピーであり、エラーがレコードレベル（RAM障害によるもの）または論理レベルに存在する場合、未検証のバックアップコピーにも元のデータベースと同様にそれが含まれるからです。
これを避けるには、元のデータベースに対してオンライン検証を使用すべきです（gfix を使ったオンライン検証は Firebird バージョン 2.5.4 から利用可能ですが、当社の FBDataGuard ツールはバージョン 1.5〜2.5 のオンラインデータベース検証をサポートしています）。
また、検証済みバックアップを、未検証バックアップに加えて時々（例えば週に一度）実行することをお勧めします。
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 つの方法を提供できます：
- DBMS のサービスとプロセスを完全に停止し、キャッシュに何も残らないようにする、
- データベースを、データベースファイルを安全に順次コピーできる特別なモードに切り替えるエージェントやスクリプトを使用する。例えば、MSSQL データベースには VSS writer と呼ばれるメカニズムがあります。要求に応じて、スナップショットが作成される時点でデータベースをスナップショットに適したモードに切り替えます。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 にご参加ください