12の典型的なデータベースバックアップエラー

当初、この記事はFirebird DBMSの開発者と管理者のみを対象としていましたが、他のデータベースの管理者と話し合った結果、ほとんどのエラーは一般的であり、文字通り誰もが非常に似たレーキを作成しました。 このリストに何かを追加できる場合（特定のDBMSに固有のものであっても）、個人のメールまたはコメントに書き込みます。

英語：データベースのバックアップ中によくある12の間違い



当社は、リカバリ、バックアップ、最適化、およびデータベース管理ツール（主にFirebirdですが、MSSQL、PostgreSQL、InterBaseなどもあります）に従事しており、多数の監査と修復の結果、バックアップに関連するエラーのコレクションを蓄積しています。 以下のすべてのポイントは、データベースの破損、バックアップの損失と損傷、ディスク、サーバーのクラッシュ、およびデータベース管理者の他の「喜び」の実際のケースに基づいて設定されています。



管理者と開発者がバックアップを管理するアプローチを変更し、起こりうる問題を回避できるように、それらについてお話したいと思います。



それでは始めましょう。



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

ほとんどの場合、この間違いは、データベースのバックアップコピーの存在の主な目的が、データベースのコピーを作成するだけでなく、最小限のシンプルな情報システム（データベースは重要な部分）を提供することであると理解していない初心者によって行われます。

その結果、最後のバックアップを削除してから新しいバックアップを作成するまで、システムは安全でない状態になります。この期間中、データベースには単一のバックアップがないためです。 バックアップは十分に長く作成できるため、これはマーフィーの法則が機能する理想的な時期です。 このアプローチは、パラグラフ7と組み合わせて特にうまく機能します（以下を参照）。

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



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

この間違いはあまりありませんが、結果はもっと悲しくなります。 バックアップがチェックされず、破損した場合（条項6を参照）、上書きの結果として、データベースの以前のコピーも有効なバックアップもありません。

通常、この不名誉は金曜日の夜に行われ、当局からの指示、混乱、矛盾する指示が出されます。 サーバールームでのちょっとした不運と憂鬱な週末が提供されます。

Firebirdはこのエラーに対してある程度の保護があります。指定されたファイル名が既存のデータベースを指している場合、gbakユーティリティとデフォルトキー-createを使用してバックアップからレストランを作成することはできません。 残念ながら、この保護には回避策があります。-repスイッチを使用すると、既存のファイルを上書きできます。

推奨事項 ：マニュアルから書面による指示を受けずに、できれば新しい仕事の提案を受けずに、戦闘データベースファイルを決して上書きしないでください。



3.中間バックアップファイルを作成せずにワンステップバックアップレストランを使用する

標準I / Oストリームを使用すると、多くのDBMS（Firebirdを含む）で面白いトリックを実行できます。データベースからすぐにデータベースを復元してストリームバックアップを実行できます。 その結果、中間バックアップファイルは作成されません。 これは、定期的なメンテナンスやテスト復元の開始（別のバックアップがある場合）には便利ですが、決して自動バックアップに使用しないでください！

このようなバックアップレストランのプロセスで深刻なディスク障害が発生した場合、たとえば、元のデータベースが破損し、新しいデータベースがまだ作成されていない可能性があります。 もちろん、アイテム1が尊重され、以前の試行からデータベースのコピーが存在する場合、そのコピーの作成時点からデータベースで作成または変更されたデータのみが失われます。

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



4.同じ物理デバイス上のストレージバックアップとデータベース

ここでは、多くの人が何らかの子供っぽいアドバイスをすることを笑うかもしれません-これがシステム管理のABCです。 ですから、仮想環境とデータベースの広がりに関連して、ディスクは同じストレージシステム上に存在できます。 そして、それはビジネスにとって最も不適切な瞬間に確実に壊れるでしょう。 さらに、RAID（1以上）を使用すると、データに何も起こり得ないと考えている人がまだいます。 「ブランド」鉄の超信頼性を信じる人々はまだいますが、これは特別な場合です。

推奨事項 ：バックアップとデータベースを同じ物理デバイスに保存しないでください。



5.バックアップが正常に完了したことを確認できない

これは、管理者とIT管理者によくある間違いです。 バックアップの結果を確認しないと、バックアップをまったく実行できません。結果は通常同じです。 バックアップが成功したことをメールで通知する必要があり、SMSで通知する必要があります。 さらに、通知の欠如は問題の兆候です！

そして、リーダーはどこで、この場所を読んだ注意深い読者に尋ねますか？ また、管理者は通常バックアップを設定しますが、通知が別のフォルダーにあるため、特に彼は通知をチェックするのが面倒なので、IT部門の責任者は定期的にすべてのバックアップのステータスに関する追加レポートを要求する必要があります。 これは、バックアップがあると思われる場合に誰を処罰するかという問題ですが、適切なタイミングでそこにいませんでした:)

！ ポイント2と組み合わせると、ベースとバックアップの両方が不足します。

推奨事項 ：成功したバックアップと失敗したバックアップを追跡し、問題についてユーザーに通知し、概要監視ツールを使用できるバックアップ自動化ツールを使用します（特に、異なるサーバーで数十および数百のバックアップを監視する必要がある場合に重要です）。



6.バックアップ検証の欠如

バックアップがどこかに配置されているという事実は、そこから読み取ることができるという意味ではありません。

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

推奨事項 ：誰でも、自分でさえも信用しないでください。 全員チェックする必要があります。



7.未検証のバックアップを使用する場合のヘルスチェックデータベースの欠如

通常、DBMSにはいくつかのタイプのバックアップがあります-ダンプ、単なるバックアップなど。 具体的に説明しなくても、検証済みバックアップと未検証バックアップの2つのカテゴリを区別できます。 Firebirdにはgbakとnbackupがあります。

Gbakは、レコードレベルでデータベース全体を読み取ってバックアップファイルを作成し、新しいデータベースにレコードを挿入してデータベースを作成し、バックアップを検証します（エラーがリトリーブされたコピーにリークする方法のオプションがありますが、これは別のタイプのデータベース管理者phakです不正な移行）、およびデータベース自体（最初から最後まで読み取ることができれば、高い確率で破損しません）。

Nbackup（別名増分バックアップ）-書き込みのために（一貫した状態で）メインデータベースファイルを一時的にブロックし、データベースファイルを（完全または部分的/増分的に）すばやくコピーできます。

大規模なFirebirdデータベース（500 GBを超える）の場合、ユーザーの作業を遅らせないようにnbackupを実行することをお勧めしますが、作成された未検証のバックアップはデータベースのページコピーであり、エラーがレコードレベルでネストする場合（これはエラーのために発生します） RAM）または論理レベルでは、未検証のバックアップには元のデータベースと同じ方法で含まれます。

これを行うには、ソースデータベースのオンライン検証を使用する必要があります（Firebirdのバージョン2.5.4以降、gfixを使用してオンライン検証を利用でき、 FBDataGuardツールはバージョン1.5-2.5のオンラインデータベース検証をサポートしています）。

また、未確認のバックアップに加えて、定期的に（たとえば、1週間に1回）確認済みのバックアップを作成することをお勧めします。

他のDBMSについては、適切なツールとチェックの組み合わせを使用する必要があります。



8.バックアップ用の空き領域を制御できない

一般に、これは古典的な間違いです。スペースが不足しているため、バックアップがすべての空きスペースを占有してクラッシュします。 データベースと一緒に単一のディスクにバックアップを配置すると、データベースの操作が停止し、システムディスクに配置すると、システム障害が発生する可能性があります。

データベースには空き領域も必要であり、バックアップのために終了したため、パラグラフ4と組み合わせて、せいぜいシステムの動作を停止させます。

また、ポイント5および2と組み合わせて、結果としてベースとバックアップの両方が存在しないことを確認します。

推奨事項 ：バックアップサイズを予測し、スペース不足の可能性を警告するバックアップツールを使用します。



9.バックアップ時間制御の欠如

文字通り半年前、バックアップは40分続きましたが、突然3時間になりました-なぜですか？ おそらくデータベースのサイズが大きくなったか、ディスクがRAIDアレイから脱落したために、書き込み速度が急激に低下し、すべてのバックアップがこの世を去ろうとしています。 または、優秀な同僚が別のバックアップシステムを同時にオンにした可能性があります（ところで、Firebirdでは一度に複数のバックアップを実行できますが、なぜこれが必要なのかは明確ではありません）。

バックアップの実行時間を制御しないと、問題を見落とし、大きくなる前に修正する機会を逃す可能性があります。

また、バックアップシステムがタスクのステータスを監視せず、スケジュールに従ってタスクを開始する場合、「朝のトロリー」に簡単にアクセスできます。これは、前のタスクがまだ終了していないときに新しいバックアップを開始できる場合です。

推奨事項 ：バックアッププロセスの期間を制御する手段を使用します。



10. OS更新アプリケーション中のデータベースバックアップの実行

非常に一般的な問題。特に、条項9と付属のWindows自動更新（デフォルトでは3泊で発生）との組み合わせで発生します。 最良の場合、プロセスの速度が低下し、OSが更新を使用するために過負荷になると、バックアップが破損します。 OSの更新が毎日行われないのは良いことです。

推奨事項 ：切断できない場合は、バックアップに干渉できないときにOSアップデートを割り当てます。



11.データベースサーバーをオンにして、ファイルバックアップまたは仮想マシン全体のバックアップによるデータベースバックアップ

多くの管理者は、DBMSには読み取りおよび書き込み可能なデータを含むアクティブで複雑なキャッシュがあり、データベースファイル自体はランダムアクセスモードで開くという事実を忘れています。

そのため、単純なファイルバックアップ（単純にデータベースファイルのコピーを含む）や仮想マシンのバックアップではなく、特別な種類のバックアップを使用する必要があります。 ファイルバックアップツールはデータベースをシーケンシャルに読み取ります。特に大規模なデータベースの場合は時間がかかるため、作成されたコピーの整合性を保証できません。

ファイルツールまたは仮想マシンのバックアップツールを使用してデータベースをバックアップする場合、次の2つの方法があります。

1. DBMSサービスとプロセスを完全にオフにして、キャッシュに何も入れないようにします。
2. 一貫した方法でデータベースファイルをコピーすることが安全な場合は、データベースを特殊モードに変換するエージェントやスクリプトを使用します。

Firebirdの場合、バックアップを開始する前にnbackupを使用してメインデータベースファイルをロックし、終了後にロックを解除する必要があります。他のDBMSでは、対応するモードを有効/無効にする同様の手段があります。



一部のDBA管理者は、DBMSにトランザクションログがある場合、そのようなDBは標準のファイル手段を使用して安全にバックアップできると確信しています。極端な場合、このログのみが破損します。 これは、DBMSメーカーによってサポートされていない危険な誤解です。



この誤解の原因は理解できます。通常、仮想マシンのメーカーやバックアップツールのメーカーからの積極的な広告は、データベースやその他のアクティブに変更可能なファイルに追加の設定が必要であるという事実について沈黙しています。 広告を信用しないでください-すべてのヨーグルトが同じように役立つわけではありません。

推奨事項 ：適切な自動化ツールなしでファイルバックアップツールとVMバックアップツールを使用しないでください。



12.バックアップ複製の代替

バックアップとデータ複製は、信頼性を高め、データ損失を防ぐのに役立ちますが、それでも大きく異なります。

誰もが最小限の遅延で別のサーバー上のデータを同期できるため、レプリケーションが大好きですが、バックアップには多くの否定できない利点があります。 たとえば、データを誤って（または意図的に）削除した場合、複製は変更を迅速かつ穏やかにレプリカに転送し、特に読み取り専用メディアのバックアップはそのような操作の影響を受けません。 適切なバックアップのように、正しい複製を設定することは努力する価値があり、エラーが発生する可能性もあります。

推奨事項 ：レプリケーションを構成している場合、バックアップを無視せずに、それらを一緒に使用してください。



結論

お気に入りのDBMSのバックアップを整理するのはそれほど簡単ではないため、通常、データを重視する組織のDBAは、上記のエラーを考慮して防止するために専門のバックアップツールを使用します。 Firebirdの場合（広告をお願いします） 、 FBDataGuardがあります。他のDBMSの場合は、DBArtisanまたは他のツールを使用できます。



まあ、そしてもちろん-あなたの管理者の妄想をグルーミングして大事にすることを忘れないでください、例えば、今すぐあなたのバックアップを取ってチェックしてください...今すぐ！





更新



紳士、データベースを使用するVMのVMWareでCBTを使用している人のPMに返信してください。