こんにちは、友達。 この記事では、データベースバックアップシステムをセットアップする前に、あなたが考えるべきことについてお話したいと思います。 最初の考慮事項はMS SQL Serverでのこのアプローチの使用であるという事実にもかかわらず、ここで説明する原則は他の技術に容易に投影されます。 さあ、行きましょう。
最初のステップ
データベースとSQLサーバーの中断のない機能を維持する責任がある場合、最初に考えるのはバックアップです。これは、データベースで何かが発生した場合によくあることです。 -トラブルはありませんが、バックアップはありません。最も快適な未来は見つかりません。 しかし、バックアップの必要性という明るい考えとともに、何百万もの最も多様な質問があります。 すべての拠点を一緒に予約するのですか、それともそれぞれ別々にした方が良いですか？ 完全バックアップを行いますか？ または、ログのみを予約する方が良いでしょうか？ さて、それを理解してみましょう。
まず、2つの基本的な質問を決定する必要があります。
- 会社の個々のデータベースの役割はどれくらいですか？ そして
- どの期間のデータ損失は許容できると考えられますか？
最初の質問は多かれ少なかれ明確です-グローバル戦略を決定するために必要です。 明らかに、特定のデータベースの重要性が高いほど、そのデータベースのバックアップをより早く、より頻繁に作成する必要があります。 会社がすべてのデータベースをほぼ同程度の強度で使用している場合、単一のバックアップ計画を作成するのが最も適切なオプションである可能性が高くなります。 一方、頻繁に使用され、他のデータベースよりもはるかに高い負荷がかかるデータベースがある場合は、バックアップを個別に計画することを検討する価値があります。
しかし、2番目の質問では、すべてがそれほどスムーズではありません。 応答であるという理由だけで、マネージャーの大多数は、任意の期間のデータ損失の容認できないことについてあなたに話します。 一方、データ損失の可能性がゼロのフェイルセーフインフラストラクチャを編成することは、中小企業にとって複雑でコストがかかり、不適切なビジネスであることを皆が理解しています。 あなたの立場を説明し、ある種のより明確な答えを達成するようにしてください-1日、1時間、30分、5分、またはあなたが働くことができる他の数字。
これらの質問に対する具体的かつ明確な回答がある場合にのみ、バックアップ作成のさまざまなアプローチの長所と短所を正しく評価できます。
完全バックアップ
完全バックアップは、バックアップシステム全体がサポートされる基盤です。 概して、これはデータベースのコピーであり、テーブル、データ、インデックス、トリガー、統計、ストアドプロシージャなど、すべてが含まれています。 さらに、動的バックアップのオプションを選択すると（つまり、データバックアップ中に、ユーザーは保存されたデータベースを完全に操作できます）、バックアップの作成中にユーザーが行ったすべての変更も保存されます。 その時点で完全バックアップを作成していれば、データベースを特定の瞬間の状態に簡単に戻すことができます。
完全バックアップに関連する主な質問は、どのくらいの頻度で実行する必要があるかということです。 普遍的な答えはありません。 完全な予約は、少なくとも週に1回は行う必要があることを理解しています。 データベースが大きすぎず、バックアップの場所に特別な問題がない場合は、おそらく1日1回のバックアップがより適切なオプションです。 一方、頻繁にフルバックアップを行うと、サーバーに負荷がかかり、バックアップを保存するために不当に多くのディスク容量が必要になります。 正確な数は、データベースのサイズ、サーバーのパフォーマンスと負荷、「基本的な質問2」に対する答え、およびログバックアップや差分バックアップなど、他の種類のバックアップを作成する頻度によって異なります。
ログバックアップ
ログのバックアップは、最後のバックアップの瞬間からのデータベースの変更（つまり、INSERT、UPDATE、およびDELETE操作）のみを含むという点で、ログの完全バックアップ、差別化、または以前のバックアップであるという点で、完全バックアップとは異なります。 格納されるデータの量は非常に少ないため、このタイプのバックアップははるかに高速であり、必要なリソースが少なくて済み、ディスク容量も少なくて済みます。 残念ながら、欠点も十分です。 まず、少なくとも1つの完全バックアップがない場合、ログバックアップは役に立ちません。 これは、テーブル、インデックス、ストアドプロシージャなどに関する情報がそのようなログに格納されないという事実によって説明されます。 2番目の重大な欠点は、最後の完全バックアップの瞬間からログの100個のバックアップを作成し、トラブルが発生した場合、大切な100分の1を復元する前に、ログの完全バックアップだけでなく、以前の99個のバックアップも復元する必要があることです。また、正しい順序で。 同意します、この観点ではあまり快適ではありません。 もう1つの重要な機能は、バックアップログがFULLまたはBULK LOGGEDリカバリモードを持つデータベースでのみ使用できることです。
ログバックアップを作成できるようにするには、このログのメンテナンスを有効にする必要があります。 このオプションはデフォルトで機能し、多くの優れた機能を提供しますが、使用を拒否する方が合理的である場合があります。 まず、データベースに大量のデータを追加したり変更したりする場合は、ロギングを無効にすることをお勧めします。 このような操作には1時間以上かかる場合がありますが、ロギングを無効にすると、はるかに高速に実行されます。 データを追加したら、データベースの完全バックアップを安全に作成し、ログモードを有効にすることができます。 2番目の重要な点は、ログを厳密に監視する必要があることです。ロギングに使用できるメモリがなくなると、システムはメモリが解放されるまで進行中のトランザクションをすべて停止します。 このような悲しい状況を回避するには、ログのバックアップをできる限り頻繁に作成する必要があります。その後、より最近のバックアップを作成するとすぐに、システムはログの保存された部分を上書き可能としてマークし、占有されたディスク容量を復元します。
ログバックアップはどのくらいの頻度で行われますか？ 繰り返しますが、普遍的な答えはありません。 一方では、ログのバックアップを頻繁に作成するほど、復元時の柔軟性が高まり、インシデントが発生した場合に失われるデータが少なくなります。 一方、1日に1回完全バックアップを作成し、1分間に1回ログをバックアップする場合、最悪のシナリオでは、ベースが最後に機能していると見なされる状態に戻る前に、ほぼ1.5万のバックアップを復元する必要があります。 この見通しだけでエクスプロイトが引き起こされるわけではありませんが、現時点では、リーダー、ディレクター、怠け者ではない人すべてに直面し、すべてがいつ準備ができているのか、なぜそんなに長く続くのかを尋ねます。 5分に1回よりも頻繁にログをバックアップすることは、ほとんど常に悪い考えだと思います。 1時間に1回未満の頻度でログをバックアップすることも理にかなっていないという意見がありますが、この記述は私には多少議論の余地があるようです。 いずれにせよ、これらの制限内に留まる場合、ほとんどの場合、これは良い解決策になります。
差分バックアップ
差分バックアップは、完全バックアップとログバックアップの間にあります。 最後の完全バックアップ以降に行われた変更を現在に保存します。 ログバックアップと比較した場合の主な利点は、データベースを完全に回復するために、完全なバックアップと
最後に区別されたバックアップのみを復元する必要があることです。 欠点は、ある時点でデータベースの中間状態を復元できないことです。差分バックアップのデータベース変更の履歴は保存されません。 ログバックアップのように、データベースの完全なコピーがない場合、このようなバックアップは役に立ちません。
追記の代わりに
結論として、主な物語の中に場所を見つけられなかったが、あまりにも重要であり、黙ってはならないいくつかのアドバイスをしたいと思います。
- DBCC CHECKDBを使用して、コピーする前に各データベースをチェックします。これにより、差し迫った問題についてタイムリーに警告されます。
- BACKUP WITH CHECKSUMオプションを使用して、すべてがうまくいったことを確認します。 このソリューションの欠点は、大規模なデータベースの場合、チェックサム検証によってシステムに深刻な負荷がかかる可能性があることです。
- バックアップの保存に使用できるディスク領域に問題がある場合は、BACKUP WITH COMPRESSIONオプションを使用します。 圧縮により、バックアップファイルの合計サイズを数回、通常は3〜5回減らすことができます。 チェックサム検証と同様に、この操作は、特に大規模なデータベースの場合、パフォーマンスに非常に重大な影響を及ぼします。 圧縮オプションは、EnterpriseバージョンのSQL Server 2008と、EnterpriseバージョンおよびStandartバージョン2008R2でのみ使用できることに注意してください。 開発バージョンを含む他のすべてのバージョンは、バックアップ中にバックアップを圧縮したり、リカバリ中に「リリース」することはできません。
- バックアップごとに個別のファイルを作成します。すべてのバックアップを1つのファイルに保存しないでください。 この場合、このファイルに何かが発生すると、すべてではなく1つのバックアップが失われます。
- 当然、データベースが保存されているのと同じドライブにバックアップを保存しないでください。
- 他の誰かがバックアップにアクセスできるという脅威がある場合は、パスワード保護または暗号化を使用してください。
- バックアップの作成プロセスを自動化します。 それは簡単であり、データベースの新しいコピーを常に持っていることを確認します。
- バックアップは、使用できない場合は役に立ちません。 したがって、必要に応じて、ストレスの多い状況ですべてを迅速かつ正確に実行できるように、データベースの復元を定期的に訓練してください。
おそらくそれだけです。 この記事のフレームワークでは、ファイルのバックアップ、ログをクリアせずにバックアップするなどの問題を意図的に考慮しなかったことにすぐに注意します。 次回は、より「実用的な」記事を作成して、バックアップの作成を自動化するさまざまな方法について説明し、コード例を示します。 あなた自身のために新しくて有用な何かを学んだことを願っています。 良い一日を。