10〜50 GBのサイズの10〜20個のSQL Server 2008 R2データベースをオンラインでバックアップし、単一のエンタープライズアプリで同時に使用する必要があります。また、すべてのデータベースでほぼ同期された状態にそれらを復元する必要があります（データベース間で最大数秒の非同期が可能です）。目的は、QA / DEV環境の実稼働データをキャプチャすることです。

データベースを完全復旧で実行することを要求せず、QA環境のデータをキャプチャするための専用のバックアップ方法を考え、私の制御下にないメインのバックアッププロセスに依存しないことを強く望みます。

私の顧客の場合、それぞれ最大30 GBで20の完全バックアップをキャプチャするのに1〜2時間かかります。これにより、単純なリカバリで実行する場合にデータベースの同期がとれすぎるため、フルバックアップを連続して取得することは受け入れられなくなります。

私はこれらよりも良いアイデアを探しています：

アイデア1：VMディスクのSANレベルのスナップショット。スナップショットからMDF / LDFをxcopyします。

コピーされたファイルが別のサーバーインスタンスにアタッチされると、その回復プロセスにより、ほぼ同時にスナップショットである一貫性のあるデータベースが作成されます。
少なくとも私がmaster / msdb / etcに対してdesyncを取得する可能性があるため、グーグルでこれが悪い考えだと確信しました。

アイデア2：複雑なバックアップを調整し、すべてのデータベースで同期復元

これには、データベースを完全復旧で実行する必要がありますが、これは望ましくありません。期限（T0）のかなり前に、すべてのデータベースの並列バックアップを開始します。T0に達したら、すべてのログをバックアップします（最大で数分かかります）。結果として得られる無数のバックアップを取り、それらを復元し、ログをロールバック/ロールバックして、T0に対してデータベース全体である程度一貫した状態を取得します。
これを確実に使用するには多くの計画とスクリプトが必要なので、それを避けるためにかなりの時間を費やします。

他の解決策がありませんか？

PS1：db snapshotsを使用できるようになりたいと思っていました。アイデアは、各データベースでスナップショットを開始し（数秒で終了する必要があります）、その後、次の分/時間にわたって順番に完全にバックアップします。次に、それらすべてを別のサーバーに復元し、それぞれをスナップショットに戻します。スナップショットはデータベースと一緒にバックアップできないため、このシナリオは不可能です。それらは、作成されたサーバー上の所定の場所にのみロールバックできます。さらに、これらにはEnterprise Editionが必要ですが、これは私がすべての顧客に提供しているわけではありません。

PS2：クロスデータベース同期バックアップを作成できるサードパーティのソリューションをご存知の場合は、そのことをお知らせください。

単一のエンタープライズアプリで同時に使用される10〜20個のSQL Server dbをオンラインでバックアップする必要があります。これらのデータベースは、すべてのdbでほぼ同期された状態に復元するようにしてください。

探しているのは、すべての顧客データベースにわたる一貫したバックアップです。完全バックアップと一緒に使用する必要があります Marked Transactions（太字の強調を追加）。

2つ以上のデータベース（関連データベース）に関連する更新を行う場合、トランザクションマークを使用して、それらを論理的に一貫したポイントに回復できます。ただし、この復旧では、復旧ポイントとして使用されたマークの後にコミットされたトランザクションが失われます。トランザクションのマーク付けは、関連するデータベースをテストしている場合、または最近コミットされたトランザクションを失おうとする場合にのみ適しています。

を使用してアドホックトランザクションログのバックアップを作成してCOPY_ONLYください。そうしないCOPY_ONLYと、アドホックトランザクションログのバックアップがログチェーンを切断するため、リカバリが苦痛になります。予防策として、バックアップのみを使用するようにユーザーを制限できます。 COPY_ONLY。

SQL Serverバージョン2008 R2以降のソリューションが必要です。Dbサイズはdbあたり最大50 GBであり、すべてをバックアップするのに1〜2時間かかります。

マークされたトランザクションは、状況に応じて機能します。並列バックアップを作成する唯一の方法はSTRIPEそれらに対する ものですが、その後、バックアップのストライプが失われないことを確認することになります。それらをより速くするために、あなたはと遊ぶことができますBUFFERCOUNTとMAXTRANSFERSIZE。

バックアップ圧縮を使用し、インスタントファイルの初期化を有効にする必要があります。

参照する

• マークされたトランザクションの使用（完全復旧モデル）
• 圧縮およびソリッドステートディスクを使用してSQLデータベースの完全バックアップ速度を上げる方法

完全バックアップとトランザクションログバックアップを実行している場合（およびこのデータが重要であると考える場合は必要です）、バックアップとトランザクションログバックアップをテストシステムにコピーし、特定の時点の復元を実行してデータベースを復元できます。 +-同じ時間。

すべてのデータベースが同じSQL Serverマシンにあるかどうか、またはサーバーのクロックがどれだけ同期されているかに応じて、「秒の非同期化のカップル」ターゲットを一致させることができるはずです。

それはちょっとしたバンドエイドソリューションかもしれませんが、要件を満たし、かなりシンプルで安価です。

重要なデータベース（完全復旧中）からの完全バックアップとトランザクションログバックアップがない場合、バックアップ戦略を実際に修正する必要があります。SANレベルのスナップショットは、とにかく特定の時点での復元を行うことができないため、データベースを完全復旧モードにするというポイントを実際に無効にします。

MrDennyがそれについて言っていることを読んでください

あなたが示した状況下で、サードパーティまたはMicrosoftベースのVSSプロバイダーを介してVSSバックアップを見ましたか？COPY_ONLYバックアップを実行できます。これにより、本番復旧チェーンが中断されることはなく、すべてのデータベースのバックアップが作成され、妥当なマージン内で他の場所に復元できます。VSSバックアップには、使用されているスパースファイルが原因で非常にアクティブなデータベースがディスク領域の問題を引き起こす可能性があるという点で、データベーススナップショットと同じメカニズムと機能停止があります。SQLライターサービスのTechNetのリソースをご覧くださいこことSQL ServerのVSSバックアップここを。

Windows Serverバックアップを使用してこれを行うには、ウィザードの手順に従って手動バックアップを行い、VSS設定のカスタム構成設定でVSSコピーバックアップを選択します。これにより、Windows Serverバックアップが、サーバー上で実行される他のバックアップを妨げないようになります。詳細については、Windows Serverバックアップリファレンスを参照してください。

@ Kin'sを答えとして投票します。これは、質問が尋ねたものと一致する最初のものだったからです。最終的に追加の答えを見つけたので、以下で説明します。

単純復旧モデルを使用しているお客様の場合、ハイパーバイザーまたはSANレベルでT0に取得された一時ディスクスナップショットから抽出されたMDFおよびLDFのコピーが必要です。これらを使用して、T0からの状態でdbを回復できます。

完全復旧モデルを使用しているお客様には、次のいずれかが必要です。

• T0の前に完了した最新の完全バックアップのメインバックアッププロセスからのコピー+ T0をカバーする後続のトランザクションログバックアップの最小チェーン。その後、T0へのポイントインタイムリカバリを実行できます。

• 独自の補助COPY_ONLYバックアップを実行するためのアクセス。T0でそれらをすべて並行して開始します。これには数秒しかかからず、私の最大の懸念事項ではありませんでした。次に、復元時に、各バックアップからFirstLSNへのポイントインタイムリカバリを実行します。この利点は、メインバックアッププロセスとの対話をまったく必要としないことです。メインバックアッププロセスは、COPY_ONLY一貫性に影響を与えずにバックアップの実行中にログを切り捨てることもできます。

私は年に数回、QAおよび本番のコピーである他の環境に対してこれを行います。復元には、完全復旧モードが本当に必要であり、特定の時点への復元はうまく機能します。また、多くのレプリケーションがあり、特定の時点に復元した後に「行が見つかりません」というエラーが発生することはまれです。また、地理的に離れた本番環境のコピーにはSANクローン/スナップショット方式を使用します。これは、データベースの同期にも適しています。