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

Microsoft Japan Data Platform Tech Sales Team

中川

データベースを運用していく上で DBA の方々が注力するポイントは、安定した性能運用とバックアップ運用が挙がるかと思います。今回の投稿では後者に関し、Azure 上での IaaS 環境の SQL Server にてバックアップを取得する方法について、バックアップ先とバックアップ方式という観点で整理いたします。

バックアップ先について

Azure 上でバックアップを取得する先は大きく 3 つあります。

  1. IaaS に接続したディスク上のファイルシステムにバックアップファイルを格納
    Azure BLOB Storage 上に VHD ファイルを作成して IaaS 環境にディスクとして接続し、ファイルシステム上にバックアップ ファイルを格納する方法です。

  2. Azure File Storage の領域にバックアップファイルを格納
    Azure File Storage は SMB 対応の NAS やファイルサーバーをたてることなく Azure Storage 領域を直接 SMB 共有し、IaaS から SMB マウントすることでバックアップファイルを格納することができます。 なお、Azure File Storage はファイルサイズ 1TB が上限であり、ファイル共有ひとつ当たりの合計容量は 5TB が上限となります。

  3. Azure BLOB Storage に直接バックアップファイルを格納
    SQL Server Backup to URL と呼んでいるもので、Azure BLOB Storage に直接バックアップファイルを格納する方法です。この機能は、SQL Server 2012 SP1 CU2 以降で使用できます。但し、以下のような制限事項があります。

    • Premium Storage へのバックアップはサポートされていません。
    • ページ BLOB を使用する場合、サポートされるバックアップの最大サイズは 1 つのページ BLOB の最大サイズ (1 TB) に制限されます。
    • ブロック BLOB は 1 ファイルにつき最大サイズ (200 GB) の制限がありますが、複数ファイルへのストライピングがサポートされていますので最大 64 ファイル(合計 12.8TB) までのバックアップがサポートされます。但し、Shared Access Signature (SAS) トークンを使用する場合にのみに限られます。

    その他の制限事項についてはこちらをご参照ください。

バックアップ方式について

Azure 上でバックアップを取得する方式は大きく 3 つあります。

  1. 従来のバックアップ方式
    本方式はオンプレ環境でのこれまでの方法と変わらないために、本投稿では説明を割愛させていただきます。なおバックアップ先は上記の 1,2,3 を選択可能です。

  2. Microsoft Azure への SQL Server マネージ バックアップ方式
    通常、バックアップの自動化についてはバックアップ方式の設計や、カスタム コードの記述、スケジューリングが必要となります。しかし、本機能を利用することにより保有期間と保存場所を指定するだけで Azure BLOB Storage へのバックアップの自動化が実装できます。この機能は、SQL Server 2014 以降で使用できます。( なお、本機能は SQL Server 2016 にてプロシージャなどが変更されているため、今回は SQL Server 2016 での情報をお伝えします。)
    例えば “MYDB01” というデータベースを Azure BLOB Storage のストレージアカウント “sqlbackupstorage” の “mydb01” コンテナに保持期間 30 日でバックアップを取得するように設定するには以下を実行するだけです。(※ バックアップ領域にアクセスできるように事前に資格情報を登録しておく必要があります。)

     Use msdb; 
    GO 
    EXEC msdb.managed_backup.sp_backup_config_basic     
      @enable_backup = 1, 
      @database_name = 'MYDB01', 
      @container_url = 'https://sqlbackupstorage.blob.core.windows.net/mydb01', 
      @retention_days = 30 
    GO
    

    これにより、以下の条件に合致する際に自動的にバックアップが実行されます。

    [データベースの完全バックアップ]

    • データベースで Microsoft Azure への SQL Server マネージ バックアップ を初めて有効にしたとき、またはインスタンス レベルで既定の設定を使用して Microsoft Azure への SQL Server マネージド バックアップ を有効化したとき。
    • 前回のデータベースの完全バックアップ以降にログが 1 GB 以上に拡張されている。
    • 前回のデータベースの完全バックアップ以降に 1 週間という最大期間が経過している。
    • ログ チェーンが分断されている。

    [トランザクション ログ バックアップ]

    • ログ バックアップの履歴が見つからない。 通常、これは Microsoft Azure への SQL Server マネージ バックアップ を初めて有効にしたときに当てはまります。
    • 使用されているトランザクション ログ領域が 5 MB 以上になった。
    • 前回のログ バックアップの後に 2 時間という最大期間に達している。
    • トランザクション ログのバックアップがデータベースの完全バックアップより遅れている。 目標は、ログ チェーンが完全バックアップより進んだ状態にしておくことです。

    なお、マネージド バックアップ を有効にしている状態でオンデマンドでバックアップを取得する場合に、通常のバックアップ ( backup コマンド使用 ) を行うとログチェーンが分断されたと SQL Server が判断してしまうため、その際には ”managed_backup.sp_backup_on_demand” を使ってオンデマンドでのバックアップを取得するようにしてください。

  3. Azure BLOB Storage 内のデータベース ファイル のファイル スナップショット バックアップ方式

    VHD ファイルを IaaS 環境にディスクとして接続した上にデータベースファイル等を配置(下図左)するのではなく、URL 指定にて Azure BLOB Storage に直接データファイル等を配置(下図右)し Azure BLOB Storage のスナップショット機能を併用することで高速なバックアップ、リストアを実現できます。この機能は、SQL Server 2016 以降で使用できます。

    image

    1 や 2 のバックアップ方式では、バックアップ対象のデータを SQL Server が吸い上げてバックアップ先に書き込むという処理が行われます。そのためデータベースが巨大化すればするほどバックアップ時のデータ転送量等が増えるためにバックアップ時間が延びてしまいます。その点、3 の方式ではデータを転送する必要がないため、非常に高速なバックアップを実現できます。
    例えば “MYDB01” というデータベースの完全バックアップを Azure BLOB Storage のストレージアカウント “sqlbackupstorage” の “mydb01” コンテナに取得する際には以下コマンドを実行します。

     BACKUP DATABASE mydb01 
      TO URL = 'https://sqlbackupstorage.blob.core.windows.net/mydb01/mydb01-full.bak' 
      WITH FILE_SNAPSHOT; 
    GO
    

    "FILE_SNAPSHOT" オプション付でバックアップを行っており、バックアップ先に格納されるバックアップファイル(この場合 mydb01-full.bak) にはスナップショットに関するメタデータのみが格納され、バックアップデータ自体は格納されずに Azure BLOB Storage にスナップショットファイルが生成されます。具体的には以下が内部的に実行されています。

    1. メタデータ(スナップショット ファイルへのポインタ情報など)を保持するバックアップファイルを作成
    2. チェックポイントの実行
    3. ストレージへの IO をフリーズ
    4. スナップショットファイルを作成
    5. ストレージ IO を再開

    VSS(Volume Shadow Copy Service) と連携した SQL Server のバックアップの仕組みをご存知の方は、非常に似た動きであることがご理解いただけると思います。
    この方式では最初に完全バックアップを取得した後は、トランザクションログのバックアップを行っていくだけで済みます。なぜなら、トランザクションログのバックアップを "FILE_SNAPSHOT" オプション付で取得する際に、トランザクションログファイルだけでなくデータファイルについてもスナップショットが作成されるためです。
    このバックアップ方式でのデータベースの復元方法やバックアップファイルの運用(不要バックアップファイルのパージなど)については、次回の投稿でご説明したいと思います。
    (2017/2/16 追記)
    本機能を使用する際の制限事項は Azure でのデータベース ファイルのファイル スナップショット バックアップ の [注意点と制限事項]部分をご参照ください。 Premium Storage を使用する際には以下の制限事項も把握しておく必要がございます。

    • バックアップ ファイル自体は、Premium Storage を使用して格納できません。
    • バックアップの間隔は、10 分よりも短くすることはできません。
    • レポートに格納できるスナップショットの最大数は 100 個です。
    • RESTORE WITH MOVE が必須です。

    なお、スナップショットを取得するとその後の変更された差分ページを Azure Storage が内部で保持することになり、その使用領域についても課金されます。Standard Storage と同じく Premium Storage においても、スナップショットに関してはその差分の使用領域分が課金され、例えば東日本リージョンの Premium Storage についてはその料金は \15.50/GB/月(2017/2/16 時点)となっています。
    https://azure.microsoft.com/ja-jp/pricing/details/storage/unmanaged-disks/

 

クラウドならではの利便性を高めるために SQL Server は Azure との親和性を高めており、今回ご紹介しましたバックアップ機能もそのうちの一つとなります。Azure 上での SQL Server バックアップを検討される際の参考にしていただければ幸いです。

 

関連記事

 

関連リンク

Microsoft Azure BLOB ストレージ サービスを使用した SQL Server のバックアップと復元