web-dev-qa-db-ja.com

SQL Always Onコピーのみのバックアップ-これらのバックアップからAGを復元できない場合のポイントは何ですか?

私はこれに対する答えをすでに知っていると思いますが、とにかく尋ねます。

状況は次のとおりです。

  • SQL 2012 Always On-2つの同期レプリカ。
  • 7 TB 1 AGに相当するSharepoint DBの価値。
  • パッチ適用前-フルDBバックアップが必要です。
  • バックアップ共有はセカンダリサーバーBにあります。
  • サーバーAからサーバーBのバックアップ共有へのバックアップ= 12時間。
  • サーバーBからサーバーBのバックアップ共有へのバックアップ= 6時間、ただしバックアップはコピーのみである必要があります。

これらを復元してAGを作成しようとすると、失敗します。 AGを再作成する前に、別の完全Dbバックアップ=さらに6時間かかる必要があります。

したがって、コピーのみのバックアップは役に立ちません。私が何かを逃していない限り?これらのポイントは何ですか?

5
user188616

コピーのみのバックアップは、通常、現在のバックアップチェーンを中断せずに、異常な理由でデータを復元する必要がある場合に使用されます(存在する場合)。一般的な理由は、コードをテストしたり、データの不規則性を確認したりするための開発ボックスへの復元です。あなたはアイデアを得ます。

補足として、AGのセカンダリからバックアップを取ることは、ロバの一種です。 AGがまったく遅れている場合は、バックアップが遅れています。セカンダリを読み取り可能なレプリカとしてまだ使用していない場合は、完全にライセンスを取得する必要があるため(ソフトウェアアシュアランスなどを想定しているため)、セカンダリはバックアップデバイスとして高価になります。

8
Erik Darling

データベースは、可用性グループに追加する前に完全バックアップが必要であり、データベースの作成方法はこの要件に影響を与えません。

データベースを可用性グループに追加する前に、データベースの完全バックアップを実行する必要があります。

  • 新しいデータベースを作成する
  • 完全バックアップ(差分とログの任意の組み合わせを含む)から復元する
  • コピーのみのバックアップから復元する
  • つけて

そのため、データベースを復元する必要がある場合は、復元されたバックアップの種類に関係なく、完全バックアップが完了するまで、可用性グループへのデータベースの追加を遅らせる必要があります。 Backup to NUL によると、この要件を満たすためにNULデバイスにバックアップできます。これは、データベースを可用性グループに戻す最速の方法です。私はそれをテストしていないので、それが機能することを確認できません。

7
Tony Hinkle