SQL Server 2017の可用性グループでデータベースバックアップを取得する際の備忘録
■はじめに
SQL Server 2017の3つのノードからなる可用性グループに対してデータベースのバックアップを試みました。メンテナンスプランのレポートログ上は成功したみたいなのですが、実際はバックアップファイルができながらなかったので四苦八苦しながら解消するまでの流れを記載します。原因なども推測の域をでていないため、今後いろんなパターンで検証してみたいと思います。
■取得できていなかった時の状況と対応策
筆者が作成したメンテナンスプランのモードは下記となります。
データベースのバックアップ（完全）
- ローカルサーバー接続のデータベースのバックアップ
- 種類：完全
- バックアップ先：ディスク
- バックアップの圧縮(Default)
データベースのバックアップ（トランザクション ログ）
- ローカルサーバ接続のデータベースのバックアップ
- 種類：トランザクションログ
- バックアップ先：ディスク
- バックアップの圧縮(Default)
また、可用性グループのバックアップ設定は下記のようにしていました。
- バックアップを行う場所：セカンダリ優先(S)
レプリカのバックアップ優先度(I)
| サーバインスタンス | バックアップ優先度(最小=1、最高=100) | レプリカの除外 |
|---|---|---|
| WIN2016N01 | 50 | |
| WIN2016N02 | 50 | |
| WIN2016N03 | 50 |
これで何度もバックアップを行っていましたが失敗しました。失敗していた原因はいくつか複合していました。
原因1: セカンダリレプリカでメンテナンスプランを実行していたこと
バックアップのテストを行う時にメンテナンスプランは、可用性グループのバックアップ設定で「セカンダリ優先(S)」としていたので、セカンダリレプリカでメンテナンスプランを実行していました。
何度実行してもメンテナンスプランのレポートは成功しているのに、バックアップファイルができないなと悩んでいました。ここでまず1つ誤りを犯していることがわかり、それは完全バックアップはセカンダリレプリカでは取得できないということでした。
そのため、プライマリレプリカでバックアップを行うようにしました。
原因2:バックアップを行う場所が「セカンダリ優先(S)」となっていこと
原因1でプライマリレプリカでバックアップを取得していましたが、やはり完全バックアップは取得できませんでした。理由については、バックアップを行う場所が「セカンダリ優先(S)」となっていることと、優先度の値がすべて均一になっていたからだと思います。
そこで、バックアップを行う場所を「プライマリ(R)」に変更したところバックアップを無事に取得することができました。
■終わりに
完全バックアップはプライマリじゃないと取れなさそうでしたが、差分バックアップならばセカンダリからとることができそうでした。もう少しパターンを網羅して検証をしてみたいと思います。
■参考
下記サイトが参考になりました。
