機能としては知っていたのですが、あまり触っていなかったので情報収集としてまとめてみました。
現状の最新は SQL Server 2016 RC1 ですが、環境をまだ作っていなかったので CTP 3.3 で確認をしています。
基本的な情報としては、File-Snapshot Backups for Database Files in Azure を。
ファイルスナップショットバックアップは、SQL Server 2016 の機能となりますが、前提としては、SQL Server 2014 で追加された、BLOB に直接データベースのファイルを配置する方法を使用している必要があります。
Windows Azure 内の SQL Server データ ファイル
データベースのすべてのファイルが BLOB に直接配置されていない場合は、ファイルスナップショットバックアップを取ろうとすると以下のエラーが発生します。
メッセージ 3073、レベル 16、状態 1、行 31
オプション WITH FILE_SNAPSHOT は、すべてのデータベース ファイルが Azure Storage にある場合にのみ許可されます。
メッセージ 3013、レベル 16、状態 1、行 31
BACKUP DATABASE が異常終了しています。
ファイルスナップショットバックアップを使用するための流れとしては、最初に BLOB に配置したデータベースを作成します。
CREATE CREDENTIAL [https://<ストレージアカウント>.blob.core.windows.net/<コンテナー>] WITH IDENTITY='SHARED ACCESS SIGNATURE', SECRET = '<sas 署名>' GO CREATE DATABASE StandardDB ON ( NAME = StandardDB_Data, FILENAME = 'https://<ストレージアカウント>.blob.core.windows.net/<コンテナー>/StandardDB.mdf' ) LOG ON ( NAME = StandardDB_Log, FILENAME = 'https://<ストレージアカウント>.blob.core.windows.net/<コンテナー>/StandardDB.ldf') GO
これで、ファイルスナップショットを使用できる、データベースが作成できましたので、あとはバックアップの取得を行います。
バックアップの取得先にも BLOB の URL を指定するのですが、取得先はデータベースが配置されているのとは異なるストレージアカウント / コンテナーを使用することができます。
# 同一のコンテナーも使用できます。
今回はバックアップ用のストレージアカウントを作成して取得しています。
CREATE CREDENTIAL [https://<バックアップ用ストレージアカウント>.blob.core.windows.net/backup] WITH IDENTITY='SHARED ACCESS SIGNATURE', SECRET = '<sas 署名>' GO BACKUP DATABASE StandardDB TO URL = 'https://<バックアップ用ストレージアカウント>.blob.core.windows.net/backup/StandardDB01.bak' WITH FILE_SNAPSHOT; GO
バックアップの取得が行われたら、ストレージアカウントの情報を確認します。
今回は Azure Storage Explorer ではなく、CloudXplorer を使用しています。
バックアップの取得先には、以下のようにバックアップ時に指定したファイルが作成されるのですが、このファイルはデータベースサイズに関わらず 512KB 程度になっているかと思います。
# 今回は 3GB 程度のデータベースを使用していますがバックアップファイルのサイズは 512KB となっています。
ファイルスナップショットバックアップは BLOB のスナップショット機能を使用しているため、データベースのファイルの各ファイルのスナップショットが取得されます。
# CloudXplorer を使用しているのは、スナップショットを表示するためです。
バックアップ取得先として指定したファイルについては、実体ではなく、スナップショットを使用して取得されているということが確認できますね。
リストアについては、バックアップを取得した際に指定したファイルを使用することで実施することができます。
バックアップファイルの削除や、スナップショットの削除については、
sp_delete_backup_file_snapshot (Transact-SQL)
sp_delete_backup (Transact-SQL)
で実行できますので、バックアップファイル管理はこれらを利用すると良いかと。
# スナップショットが残っている状態では、データベースの削除を行った後の、データベースファイルの実ファイルが削除できなかったりしますので、スナップショットの存在は意識しておくとよいかと。
プレミアムストレージにもデータベースのファイルを直接配置することができるのですが、その際には、以下のような制約があります。
Premium storage: When using premium storage, the following limitations apply:
The backup file itself cannot be stored using premium storage.
The frequency of backups can be no shorter than 10 minutes.
The maximum number of snapshots that you can store is 100.
RESTORE WITH MOVE is required.
For additional information about premium storage, see Premium Storage: High-Performance Storage for Azure Virtual Machine Workloads
Premium Storage: Azure 仮想マシン ワークロード向けの高パフォーマンス ストレージ にプレミアムストレージの情報が記載されていますが、以下の制約ファイルスナップショットバックアップにも適用されています。
単一の BLOB のスナップショットの数は 100 に制限されています。スナップショットは最大で 10 分間隔で取得できます。
プレミアムストレージの場合、スナップショットの取得間隔と取得数が制限されていますので、取得のタクトについては注意する必要があります。
また、プレミアムストレージを使用する場合、「バックアップの取得先はスタンダートストレージを使用する」という点が注意点かと。
取得時のバックアップファイルは実体ではく、リンク的な扱いとなり、実際にはファイルのスナップショットが取得されています。
このリンクのファイルについては、プレミアムストレージではなくスタンダートストレージに配置する必要があります。
# 数 KB のファイルの取得のためにプレミアムストレージの最小容量の課金が発生するのを抑えるためかと。
スナップショットのファイルの作成状況を確認すると、この機能の動作がイメージしやすいのでは思いました。