web-dev-qa-db-ja.com

SQL Serverの高可用性によるセカンダリレプリカからのcopy_onlyバックアップの復元の問題

AlwaysOn高可用性を備えた12インスタンスのファーム全体にOla Hallengrenバックアップソリューションを実装しました。毎週の完全バックアップ、毎日の差分バックアップ、および4時間ごとのトランザクションログバックアップの一般的なセットアップ。

プライマリのパフォーマンスを活用するために、これらのバックアップをセカンダリにオフロードしました。これにより、セカンダリで完全バックアップがcopy_onlyになります。理論的には、差分バックアップは行われるべきではありませんが、ジョブはプライマリでのみ実行され、差分バックアップもcopy_onlyとしてマークされます。ログバックアップはセカンダリで実行されます。

復元プロセスをテストした方がいいと思いました。 copy_onlyフルバックアップWITH RESTOREおよびMOVEをテストデータベースに復元しましたが、問題ありませんでした。テストデータベースを削除し、copy_onlyフルバックアップWITH NORESTOREおよびMOVEをテストデータベースに復元した後、次のcopy_only差分バックアップを復元しました。これは失敗しました

「データベースが以前の状態を修正するために復元されていないため、差分バックアップを復元できません。」

sys.database_filesを見ると、2017-02-15のdifferential_base_timeと467000002068600193のdifferential_base_LSNが表示されています。このファイルはありません！

RESTORE HEADERONLY my copy_onlyの使用完全バックアップには

FirstLSN = 743000000530200000、

LastLSN = 743000000569700000、

CheckpointLSN = 743000000530200000、DatabaseBackupLSN = 467000002068600000

私のcopy_only差分バックアップには

FirstLSN = 788000000036000000

LastLSN = 792000000047100000、

CheckpointLSN = 792000000040600000、DatabaseBackupLSN = 467000002068600000

DifferentialBaseLSN = 467000002068600000

LSN 467000002068600193（または467000002068600000 ...）をカバーするフルバックアップがないという潜在的な災害に関係なく、copy_onlyフルバックアップのLastLSNとFirstLSN of my copy_only差分バックアップ。これはないようです。誰かが私の理解のギャップを説明できますか？

そして、誰かが私のバックアップ戦略を元に戻すための最も痛くない方法を勧めることができますか？

バックアップをセカンダリレプリカにオフロードすると、すべてのフルバックアップがcopy_onlyになり、DifferentialBaseLSNをキャプチャできず、差分バックアップがまったく許可されない場合（おそらく）、そのようなオフロードの重要な利点について誰かが説明できますか？ ？

sql-serverbackuprestoreavailability-groups
2
DiamondBeezer

まず最初に、差分バックアップを削除します。フルバックアップを実行している場合は、セカンダリからバックアップのみをコピーしてください。これらは何もしません。

差分バックアップは、フルバックアップからの変更をバックアップするために機能します（コピーのみではありません）。通常の完全バックアップを実行すると、データベース内のすべてのページがバックアップされるように設定されます。その時点から先に進むと、ページへの変更がマークされ、差分が表示され、変更済みとしてマークされたページがバックアップされます。時間が経つにつれ、差はますます大きくなります。コピーのみのバックアップではこれらのフラグはリセットされないため、状況はさらに悪化します。

この時点で、バックアップ戦略をどのように進めるかを決定します。差分バックアップを続行する場合は、プライマリでも完全バックアップを実行してください。 AGにあるデータベースの差分を取る必要がなくなった場合は、Olaスクリプトでcopy_onlyフラグをNに設定します。これにより、差分ジョブを実行してAGにないデータベースのバックアップを取得できますが、AGにあるデータベースは無視されます（バックアップ設定がセカンダリレプリカをバックアップ元のマシンとしてマークしている限り）。

バックアップをセカンダリにオフロードすることの利点に関しては、これにより、ほとんどのトラフィックが存在する可能性があるプライマリレプリカのリソース競合を減らすことができます。また、セカンダリレプリカが1つまたは2つあるDRサイトでデータベースバックアップを行う方法としても役立ちます。

1
Nic