データベースバックアップ/リストアプロセス

Question

大規模なデータベースまたはデータベースのコレクションをSQLサーバー上にバックアップおよびリストアするプロセスは、惨事復旧のために非常に重要です（&）。しかし、私は、すべてのプロセスが可能な限り効率的で、100％信頼性が高く、複数のサーバーにわたり容易に保守可能で構成可能であることを保証する堅牢なソリューションは見つけていません。

Microsftの保守計画では十分ではないようです。私が使用した最善の解決策は、ソースサーバー（バックアップ）とターゲットサーバー（復元）で実行されているデータベースごとに多くのステップを含む多くのジョブを使用して手動で作成したソリューションです。ジョブは、バックアップを実行するためにストアドプロシージャを使用して、&を復元します。これは、1日に1回（フルバックアップ/リストア）、5日ごとにイントラデー（トランザクションログの配送）を実行します。

私の現在のプロセスは動作し、電子メールによるジョブの失敗を報告しますが、プロセス全体が非常に信頼できるものではなく、DBA以外の者によってすべてのサーバーで簡単に保守/構成できないことがわかります。プロセス。

私は他の人がこの同じバックアップ/リストアプロセスを持っているか、他の人がこの問題を克服しているかどうかを知りたいと思います。

Answer 1

このプロセスでも、私は正確に同じことをしており、さまざまな問題を定期的に受けています。

トランザクションバックアップが通常よりも大きくなると時間がかかるしながら、どのようにあなたがすべて一度でサーバーBにサーバーAからファイルをコピーし、サーバーB

にトランザクションバックアップの復元の間の間隔を処理しませんコピーする。復元ジョブは、ファイルが使用されているオペレーティングシステムエラーを取得します。

次回以降にファイルが自動的に適用されるため、これはあまり重要ではありませんが、一般的にはより洗練された解決策があり、特にこの問題を修正するものがより良いでしょう。

Answer 2

開発者とQA担当者が夜間にdev/test/QAデータベースをゼロステップに保つために同様の手順を使用しました。

Scott Hanselmanが「バス要因」と呼んでいるもの（システムの作成者がバスに当たってすべてが吸い込まれる危険性）を取り除く場合は、ドキュメントが鍵です。

つまり、通常のデータベースバックアップと災害復旧計画では、SQL Server Maintenance Plansがうまく機能していることがわかりました。あなたが含まれている限り： 1）適切な文書 2）ルーチンテスト。
SQL Server Backup Best Practices (Free Tutorial/Video)

Answer 3

キーパーツ：

私は（誰のための災害復旧計画を作成に取り掛かる方法の例を探して、この質問に描かれた）ことをやって行くための方法のいくつかを概説しましたあなたの質問のバックアップソリューションが非DBAによって管理される能力です。バックアップスクリプトはT-SQLの知識を必要とするため、バックアップスクリプトのようなネイティブSQL Serverのすべての回答は、その必要性を満たしません。

そのため、Mitch Wheatのようなサードパーティのソリューションを検討したいと考えています。私はQuest（LiteSpeedのメーカー）のために働いています。もちろん、私はそれを部分的に扱っています。DBA以外の人に見せても簡単です。最後の会社を退社する前に、システム管理者と開発者にLiteSpeedコンソールの仕組みを示す10分のセッションがありました。彼らは以来呼ばれていない。

もう1つの方法は、残りのショップで使用するのと同じバックアップソフトウェアを使用することです。 TSM、Veritas、Backup Exec、およびMicrosoft DPMにはすべて、Windows管理者が様々な使いやすさでバックアッププロセスを管理できるSQL Serverエージェントがあります。 DBA以外のDBAが管理したい場合は、SQL固有のバックアップツールが提供する多くのパフォーマンスを犠牲にしますが、これはおそらく最も簡単な方法です。