SQL Server(IaaS) on Azure におけるバックアップ（続編）

Microsoft Japan Data Platform Tech Sales Team

中川

前回の投稿では、Azure 上での IaaS 環境の SQL Server にてバックアップを取得する方法について、バックアップ先とバックアップ方式という観点で整理いたしました。その中で、バックアップ方式に関し、Azure BLOB Storage 内のデータベース ファイル のファイル スナップショット バックアップ方式(以下、スナップショット バックアップ方式と称す)をご紹介しましたが、今回の投稿ではそこにフォーカスを当てて深掘りをしていきます。

スナップショット バックアップ方式では SQL Server のバックアップ機能を Azure BLOB Storage のスナップショット機能と組み合わせることにより高速なバックアップ、リストアを実現しておりますが、そもそも Azure BLOB Storage のスナップショット機能とはどういったものかを先ずはご紹介し、その後に具体的なバックアップ、リストアの話に触れたいと思います。

[Azure BLOB Storage のスナップショットとは]

Azure BLOB Storage のスナップショットとは、ある時点で取得された BLOB の読み取り専用バージョンを作成する機能のことです。下図では、t1、および t3 の時点でスナップショットを作成しておりますが、その後の変更されたデータをページ (SQL Server のページではなく Azure BLOB Storage のページ) 単位で変更前イメージを保持することにより t1 時点、t3 時点の BLOB イメージを読み取り専用で参照することが可能となります。ポイントは t1 時点、t3 時点のイメージ全体をコピーして保持するのではなく、変更前ページのみを保持することにより、ベースとなる BLOB と変更前ページ分だけの課金で済む点と、スナップショット作成時に BLOB イメージ全体のコピーを別の場所に取得しているわけではないのでスナップショット作成には時間がかからない点です。

図1: スナップショット作成

図2: スナップショットの参照

ただ、スナップショットを作り続けると、当然変更前ページが累積されていることとなりその分の課金も増えていきます。そこで、古いスナップショットは削除したいというニーズが出てくるかと思いますが、一点ご注意いただきたいポイントがあります。例えば、下図の図3ではスナップショット:t1 を削除していますが、t1 と t3 の間に保持していた変更前ページ (図3 内の ➀) は必要なくなったために解放されます。それに対し図4 ではスナップショット:t3 を削除していますが、スナップショット:t1 は削除されていないためにスナップショット:t1 を参照するために必要な t1 以降で保持していた変更前イメージ (図4 内の ➀、および➁) は保持されたままで解放されません。このように、途中のスナップショットを削除するようなケースはあまりないかもしれませんが、間のスナップショットを削除しても累積された変更前ページは解放されないという点はご留意ください。

図:3 スナップショット:t1 を削除

図4: スナップショット:t3 を削除

[スナップショット バックアップ方式]

では本題に移ります。前回の投稿でも述べましたが、本方式は VHD ファイルを IaaS 環境にディスクとして接続した上にデータベースファイル ( データファイル、ログファイル ) を配置するのではなく、URL 指定にて Azure BLOB Storage に直接データベースファイルを配置した場合にのみ利用することができる方式ですが、Azure 上で SQL Server の高速なバックアップ・リストアを実現することができます。

バックアップについては、毎回データをバックアップ先に転送する必要がないために高速であることは前回お伝えしましたが、リストアについても高速です。従来の方式ではリストアにかかる時間は簡略化すると

１．完全バックアップで取得したバックアップセットからのリストア

２．(取得している場合には)差分バックアップで取得したバックアップセットからのリストア

３．トランザクションログバックアップで取得したトランザクションログのリストア

の 2 つ、あるいは 3 つのステップが必要でした。また、完全バックアップは定期的に取得する必要がありました。完全バックアップを定期的に取得せず、トランザクションログバックアップのみを取得しつづけると、リストア時間が累積されたトランザクションログの量に比例して長期化してしまうためです。

 

図5: 従来のバックアップ・リストア

しかしスナップショット バックアップ方式では、バックアップ チェーンの起点を設けるために最初は完全バックアップを取得する必要がありますが、その後はトランザクションログバックアップを取得し続けるだけでよくなります。なぜなら、本方式ではトランザクションログバックアップを取得する際にも、トランザクションログファイルだけでなく、データファイルに関してもその時点のスナップショットが取得されているためです。

図6: スナップショット バックアップ方式によるバックアップ・リストア

例えば図 6 の例で T4 の時点にリストアしたい場合、T4 時点のデータファイル、およびトランザクションログファイルのスナップショットが維持されているために T4 のスナップショットがあればリストア可能です。

 RESTORE DATABASE mydb01 FROM URL = 'https://sqlbackupstorage.blob.core.windows.net/mydb01/mydb01-tranbackup-T4.bak'WITH RECOVERY, REPLACE;GO

また、T3 時点 ( スナップショット トランザクションログバックアップを取得した T2 と T4 の間) にリストアしたい場合には、リストアの起点となる T2 時点のスナップショットでリストアを行った後、 T4 時点のスナップショットからトランザクションログを読み取って T3 時点にリストアすることが可能です。

 RESTORE DATABASE mydb01 FROM URL = 'https://sqlbackupstorage.blob.core.windows.net/mydb01/mydb01-tranbackup-T2.bak'WITH NORECOVERY,REPLACE;GORESTORE LOG mydb01 FROM URL = 'https://sqlbackupstorage.blob.core.windows.net/mydb01/mydb01-tranbackup-T4.bak'   WITH RECOVERY,STOPAT = T3;  GO

※ T3 部分は日時フォーマットで指定。

なお、このポイントインタイムのリストアを行う際には、必ず隣接する二つのスナップショットバックアップが必要となります。例えば図 6 でいうところの T2 のスナップショットを削除してしまった状態で T3 時点にリストアすべく T1 と T4 を使ってリストアを行おうとしてもできません。これはバックアップチェーンが分断されてしまっているためです。

以上のように、スナップショット バックアップ方式はバックアップ設計を簡素化できると共にバックアップ・リストアを高速化することにより運用も楽にしてくれるという特徴がございますので、是非ご利用いただければと思います。

関連記事

• SQL Server (IaaS) on Azure におけるバックアップ