SQL Azureは、SQL Serverをベースに開発されました。しかし、バックアップ周りはSQL Serverと異なる点が多く、SQL Serverのバックアップ設計ノウハウを活用することができません。

SQL Serverでは、フルバックアップ、差分バックアップ、トランザクションログバックアップを組み合わせて、障害発生時のダウンタイムを短くしつつ、データロストを最小限にとどめるように設計してきました。

SQL Azureでは、ユーザがフルバックアップ、差分バックアップ、トランザクションログバックアップを取得することはできません。フルバックアップは、SQL Azureデータセンター内部で取得され、必要に応じてデータセンター内部で実行されるものです。ユーザにはフルバックアップ機能へのアクセスは提供されていません。

今回は、SQL Azureのバックアップ設計を検討する際に、参考になる情報を提供したいと思います。バックアップを取得する目的を整理し、目的に応じたバックアップ方法を提示します。

バックアップの目的

データベースをバックアップする目的には、次の4つがあります。

データファイル破損からの復旧

データベースを運用していると、何らかの理由でデータファイルやトランザクションログが破損することがあります。ファイルが破損するとデータベースの動作が停止する障害が発生します。この障害発生に備えておくためにバックアップをとっておきます。アプリケーションの要件に左右されますが、障害直前にまでデータを復旧させられる必要があります。

大災害復旧対策

大災害によりデータセンターが、破壊されたり、ネットワーク不通になったり、電源消失したりし、データベースが使用できなくなる可能性があります。このような事態になった場合でも、事業継続（アプリケーション継続）できるようにするために、遠隔地にバックアップをとっておきます。大災害が発生してもデータが完全に喪失しないことが優先事項となるため、データの最新性は問われない傾向にあります。

アプリケーションバグによるデータ不整合からの復旧

アプリケーションバグやヒューマンエラーにより、データの不整合が発生することがあります。予期できないタイミングで発生するため、定期的にバックアップを自動で取り続ける必要があります。数日前から1、2週間前のバックアップデータが必要になることがあります。

開発環境や評価環境の構築

開発・テストのためのデータベース複製や、テスト後にデータを元に戻せるようにバックアップをすることがあります。この場合、直近のデータを手動でバックアップをすることが多いです。

データファイル破損からの復旧

第1回「SQL Azureとは何か」の「プロビジョニング」で紹介したように、SQL Azureはデータを自動的に三重化しています。プライマリレプリカとセカンダリレプリカは、コミット同期されているため最新の状態に保たれています。

SQL Azureデータベースはオンライン状況を監視しています。データベースファイル破損などで、データベースが使用できない状態になった場合、プライマリレプリカがシャットダウンされ、セカンダリレプリカがプライマリレプリカに昇格します。

つまり、データファイル破損による障害から復旧を目的としたデータバックアップは必要が無いことがわかります。

SQL Azureで提供されているバックアップ手法では、障害が発生した直前の段階のデータをバックアップすることができません。SQL Azureの仕組みとして必要が無く、SQL Azureの仕組みとして実現する方法が無いため、設計から除外できます。

大災害復旧対策

データセンター全体または一部が使用できなくなる大災害対策として、遠く離れた別のデータセンターにデータをバックアップする対応が考えられます。

Windows Azureストレージは、すでに自動的にジオ・レプリケーションが実施されています。同じリージョン内にある別のDCに自動的にデータが複製され多重化されています。SQL Azureは、今のところジオ・レプリケーションは実施されていないため、ユーザ側で対応を検討する必要があります。

データベースを作成したデータセンターと異なるデータセンターに、データを同期し複製する対応が考えられます。コーディングすることなくデータベースの同期をとれるSQL Azure Data Sync[1]を使用することで実現できます。

たとえば、本番運用のために作成した東アジアのDCのデータベースをSQL Azure Data Syncの同期グループのハブ・データベースに設定します。大災害復旧対応のために、離れた場所にあるヨーロッパのデータセンターのSQL Azureデータベースと、日本のオンプレミスのSQL Serverをメンバー・データベースとして同期設定します。すると別々の場所にあるデータセンターにデータを複製でき、災害復旧対策となります。ただし、災害発生時にはアプリケーションの設定変更が必要になってしまいます。

アプリケーションバグによるデータ不整合からの復旧

定期的にデータをバックアップする必要がありますが、現時点で最も対応が面倒なパターンです。定期的なジョブを実行するSQL Server Agentに相当するサービスは、今のところSQL Azureでは提供されていません。そのため、定期的にデータをバックアップするためにDAC Frameworkなどを活用してWorkerロールに自分で実装する必要があります。

SQL Azureでは、定期的にバックアップをとる必要が無くなる対応が実施される予定です。Tech ED 2011 North Americaにて、発表されたPoint in time restoreが発表されました。Point in time restoreは、過去二週間以内の指定した日時の状態のデータベースをリストアすることができる機能です。二週間が要件に合致する場合は、本機能リリース後は定期的なバックアップの必要性が無くなります。今のところ機能提供の開始時期は発表されていません。

開発環境や評価環境の構築

本用途の場合、データベースの複製が必要になった段階で手動で作業ができれば問題ありません。SQL Azureで提供されているバックアップ方法は、本用途に適した方法です。SQL Azureで提供されているバックアップ方法は、Database Copyと「インポートとエクスポート⁠」⁠、「⁠ExtractとDeploy」の3種類です[2]⁠。

Database Copyは、T-SQLを発行して、同じSQL Azureサーバ内、もしくは同じデータセンター内の別のSQL Azureサーバにデータベースの複製を作成することができる機能です。評価環境の作成や、開発環境の作成に適しています。

Windows Azure管理ポータルで提供されている「インポートとエクスポート」は、データベース定義とデータをSQL AzureとWindows AzureストレージのBlob間で出し入れできる機能です。SQL Azure管理ポータルで提供されている「ExtractとDeploy」は、データベース定義とデータをSQL Azureとローカル間で出し入れできる機能です。

また、SQL Server 2012で提供されるSQL Server Management Studioでも「インポートとエクスポート⁠」⁠、「⁠ExtractとDeploy」に相当する機能がウィザード形式で提供されます。

まとめ

SQL Azureでは、データファイル破損からの復旧については対応する必要がありません。しかし、大災害復旧対策の場合はSQL Azure Data Syncなどを使用して別のDCにデータを同期しておく必要があります。開発環境や評価環境の構築目的の場合、SQL Azureでは選択肢が充実しつつあります。

アプリケーションバグによるデータ不整合への対応の場合、活用できるソリューションが無いので、ユーザ側で実装が必要になります。