SQL Server on Azure VM (IaaS) の環境を Azure Backup でバックアップしようとした場合に、今はどのようになっているのかを把握することができていなかったので、軽くまとめてみました。
以前、Azure Backup で SQL Server がインストールされている仮想マシンをバックアップする際に意識しておきたいこと という投稿を書いたのですが、4 年前ですので自分の頭の中の整理もかねて。
今回のターゲットは Windows 環境で実行している SQL Server の単一ノードでの構成となり、Always On 可用性グループ / FCI はターゲットにはしていません。。
Contents
SQL Server で取得が必要となるバックアップ
Windows 環境で動作している SQL Server で必要となるバックアップは次の 2 種類となります。
- システムバックアップ
- データベースバックアップ
システムバックアップ
システムバックアップの定義としては「バックアップ取得タイミングのサーバーの状態」にリストアを実施することを目的としたものとします。(OS 部分のみをリストアできれば良いとするケースもありますが、今回はサーバー全体を指すことにします)
主な用途としては「更新プログラム適用前の状態に戻したい」「サーバーが起動しなくなった」というケースの場合に利用することになり、サーバーを特定タイミングの状態に戻して起動をするという用途での利用となります。
SQL Server をインストールしている環境では「更新プログラム」は 2 種類を意識する必要があります。
- OS の更新プログラム
- SQL Server の更新プログラム (Cumulative Update)
更新プログラムの自動適用を有効化している環境では、OS ならびに SQL Server のパッチ適用の両適用に備えたシステムバックアップが必要となります。
データベースサイズが大きい環境では、システムバックアップからデータベース部分を除外したいものなのですが、SQL Server のシステムが起動する状態として考えた場合、最低限、次の内容が必要となります。
- OS ディスク
- SQL Server のバイナリ
- SQL Server のシステムデータベース (master / model / msdb)
ディスクがうまく構成できている場合は、ユーザーデータベースのディスクのみを除外してシステムバックアップを取得することで、SQL Server が起動する状態までリストアできるバックアップを高速に取得することができますが、そのような構成になっていない場合は、バックアップ時間を犠牲にして全体を取得するのがシンプルではないでしょうか。
定期的に取得するか (できるか) どうかについては、サーバー全体のサイズによりますが、OS / SQL Server のバイナリに変更が発生する場合には、事前に取得を行います。
SQL Server 向けの更新プログラムについて
「OS の更新プログラム」については、Windows Update が実行されたタイミングで導入が行われますので、制御の方法は一般的かと思います。
「SQL Server の更新プログラム」(Cumulative Update) の適用については、少し注意が必要となります。
Windows Update の初期設定であれば、Windows Update を実行しても、SQL Server の更新プログラムは対象外となっているはずです。
しかし「SQL Server IaaS Agent 拡張機能」の「修正プログラムの適用」が「有効」になっている場合は「その他の Microsoft プロダクトの Windows Update 経由での適用」が有効になります。
これについては、Azure 仮想マシンでの SQL Server の自動修正 (Resource Manager) にも記載されており、ポータルにも表記がある内容です。
この設定になっている場合、Windows Update を実行すると SQL Server の更新プログラムについても検知が行われます。
簡単な検知用のスクリプトしては次のような内容となります。
$updateSession = New-Object -com Microsoft.Update.Session
$searcher = $updateSession.CreateUpdateSearcher()
$searcher.Online = $true
$results = $searcher.search("IsInstalled=0 and Type='Software'")
$results.Updates | % {Write-Host ("{0} : {1}" -f $_.Title,$_.MsrcSeverity)}
実行をすると、Important となっている更新プログラムとして「KB4583458」が認識されています。
SQL Server の更新プログラムについては Microsoft SQL Server の最新の更新プログラム で情報が公開されており、更新プログラムの種別として「GDR (General distribution release)」という種別の更新プログラムがあります。
GDR はセキュリティ的なインパクトが高く「重要」としてマークされているものとなりますので IaaS Agent 拡張機能の「修正プログラムの自動適用」が有効になっている環境では、自動的に適用が行われます。
データベースバックアップ
データベースバックアップは、SQL Server を運用している環境では日常的に取得する必要のあるバックアップとなり、ユーザーデータベース / システムデータベースに対して次の内容を定期的に取得します。
- 定期的な完全バックアップ
- 定期的な差分バックアップ
- DB サイズが小さい場合は、定期的な完全バックアップでカバーできる
- 定期的なトランザクションログバックアップ
どのような間隔で取得すればよいかについては、Azure SQL Database の考え方 が参考になると思います。
Azure SQL Database では、次のような間隔でバックアップが取得されていますので、これに近いバックアップが取得できるようにすると、良いのではないでしょうか。
- 毎週のフルバックアップ
- 12～24 時間ごとの差分バックアップ
- 5～10分ごとのトランザクションバックアップ
SQL Server on Azure VM を使用する場合、データベースバックアップの簡単な取得方法としては次の 2 種類の機能を活用でき、これらを使用する場合は、どちらを使用するかを決めておく必要があります。
これらの機能で取得されるバックアップは「COPY_ONLY を使用しないバックアップ」となるため、原則としてどちらか一方でバックアップの取得を検討します。
Azure Backup を使用した SQL Server 環境のバックアップ
それでは、上記のバックアップを Azure Backup を使用して取得します。
Azure Backup で SQL Server 環境のバックアップを取得する場合には、次の二つの機能を使用することができます。
システムバックアップの取得
システムバックアップの取得については Azure VM バックアップ を使用して、VM 全体のバックアップを取得するのがシンプルな方法となります。
Azure VM バックアップを設定することで、VM 全体をバックアップすることができますので、バックアップタイミングの VM に戻すことができるバックアップを取得することができます。
- OS ディスク / SQL Server バイナリ / master, model , msdb
- ユーザーデータベース
のディスクが分離されている場合は、Azure 仮想マシンの選択的なディスク バックアップと復元 を使用し、一部のディスクのみバックアップ対象とすることで「SQL Server のベース部分が起動する最小限のバックアップ」を取得することもできるのではないでしょうか。
SQL Server を実行している環境では、Azure VM バックアップによるバックアップは「VSS COPY バックアップ」を使用することで、SQL Server 向けの機能で取得しているバックアップの連続性を保つことができます。
これについては VM スナップショットに関する問題のトラブルシューティング に記載されていますが、SQL Server 向けのバックアップを取得する環境では、レジストリの「HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\BCDRAGENT」の「USEVSSCOPYBACKUP」が「TRUE」になっているかは確認したほうが良いかと思います。
「Azure VMでの SQL Server Backup」の設定を行っている環境では、TRUE が設定された状態になっていると思います。
今回は一通りのバックアップを Azure Backup で完結させる想定ですが「Azure Backup によるシステムバックアップ + SQL Server IaaS Agent 拡張機能によるデータベースバックアップ」でバックアップを取得する場合は、上記のレジストリの設定値がどのようになっているのか (USEVSSCOPYBACKUP = TRUE になっているか) は確認をしたほうが良いかと思います。
Ultra Disk を使用している場合の注意点
SQL Server を実行している環境では、シンプルな構成で高速なディスクスループットを実現するため、Azure Ultra ディスク を使用するケースもあるかと思いますが、Ultra Disk を使用している場合は、Azure Backup との相互運用性については注意する必要があります。
GA の範囲と制限事項 に記載されていますが、Ultra Disk を使用している仮想マシンは「Azure VM バックアップ」がサポートされておらず、バックアップ対象として選択することができません。
そのため、Ultra Disk を使用している仮想マシンは Azure Backup を使用したシステムバックアップは取得することができません。
Ultra Disk を使用している環境では、Azure マネージド ディスクのバックアップとディザスター リカバリー の内容を参考にして、OS 部分の Managed Disk のコピーや、スナップショットの活用を検討する必要があるのではないでしょうか。
Ultra Disk を使用している環境でも「Azure VM での SQL Server Backup」については使用することができます。
データベースバックアップの取得
データベースバックアップの取得については、Azure VM での SQL Server Backup で取得を行います。
「AUTOPROTECT (自動保護)」を「ON」にしておくことで、設定後に追加された DB も自動的に取得対象となりますので DB の増減に対しても柔軟に対応できます。
SQL Server Backup 向けのバックアップについては、「完全バックアップ」「差分バックアップ」「トランザクションログバックアップ」を組み合わせて指定することができ、「完全バックアップ」「差分バックアップ」については、1 日 1 回、トランザクションログバックアップについては、最小で 15 分間隔で取得をすることができます。
SQL Server Backup を設定した VM では、「AzureBackupWindowsWorkload」という拡張機能が有効になり、この拡張機能と連動して SQL Server のバックアップが行われます。
取得されるバックアップについては「BACKUP DATABASE」ステートメントで実行されますので、クエリのトレースを取得することでどのようなバックアップが取られるかを確認することができます。
取得されるバックアップは一般的な SQL Server のデータベースバックアップ (.bak) となりますので、通常の SQL Server 運用と同様の感覚で使用することができるかと思います。(現在プレビューですがスナップショットベースの DB バックアップも提供されています)
取得されているバックアップについては、「上書き」「別の DB」「バックアップファイルをローカルにファイルとして復元」を選択することができます。
master データベースについては上書きリストアができないので、Restore the master Database (Transact-SQL) のように、シングルユーザーモードでインスタンスを起動して、「バックアップファイルをローカルにファイルとして復元」した「.bak」ファイルを使用してリストアするということになると思いますが、取得されているバックアップを使い慣れた SQL Server のバックアップとして活用することができます。
SQL Server IaaS Agent 拡張機能の自動バックアップでもバックアップは取得できますが、Azure Backup のほうがポータルからのリストアや、細かな設定ができますので、「Azure ストレージにバックアップを保持しておく必要がある」という要件がないのであれば、Azure Backup の SQL Server Backup を使用したほうが良い気がします。
VM スナップショットに関する問題のトラブルシューティング の USEVSSCOPYBACKUP の設定が行われていれば、Azure VM バックアップと Azure VM での SQL Server Backup の併用ができます。
まとめ
SQL Server on Azure VM のバックアップには Azure Backup を活用することができます。
- IaaS Agent 拡張機能の自動更新の有効化によるシステムバックアップ取得タイミングの影響
- Ultra Disk を使用した場合のシステムバックアップ取得についての考慮
は気を付ける必要がありそうですが、Azure Backup を活用することができると、SQL Server のバックアップ運用も効率的に実行することができるのではないでしょうか。