前回は、SQL Data Warehouseを起動して、接続の確認を行いました。テンプレートとして、架空の会社「Adventure Works」のDWH用データベースが提供されていることを確認いただけたのではないでしょうか。テーブルの作成方法やアーキテクチャのもう少し詳しい説明は次回以降に譲るとして、今回はSQL Data Warehouseのバックアップに関して詳しく解説していきます。

SQL Data Warehouseのバックアップ

SQL Data Warehouseのバックアップは自動で取得されています。4～8時間おきに自動で取得する仕組みとなっており、ユーザー側での変更は現時点（2017年6月時点）ではできません。このため、オンプレDWHではよくある、「日次バッチが終了したタイミングでバックアップを取得しよう」とか、「バックアップは週に１回だけ取得しよう」といったことはできません。

自動で取得されたバックアップは7日間保存されます。この7日間の保存期間を延ばすことや短くすることも現時点ではできません。どうしても7日以上の保存期間を必要とする場合は、バックアップから別のSQL Data Warehouseを起動させて、SQL Data Warehouseを停止させておくなどの工夫が必要になります(SQL Data Warehouseを停止させておけば、かかる料金はディスク分だけとなります)。

このバックアップを使ってリストアできるポイントは、バックアップが取得されたポイントになります。つまり、7日間のバックアップ保存期間中いくつもバックアップは取得されますが、この保存期間内であれば、任意のバックアップ時点に復旧できます。

では、ここでバックアップからの復元を試してみたいと思います。前回作成したSQL Data WarehouseにMicrosoft SQL Server Management Studio（SSMS）からログインし、「AdventureWorksDWbuildVersion」というテーブルを削除します。

「AdventureWorksDWbuildVersion」のテーブルを右クリックし、「削除（D）」選択

「OK」を押すと、削除が実行される

削除が完了すると、SSMSのオブジェクトエクスプローラーから「AdventureWorksDWbuildVersion」がなくなっていることが確認できると思います。

ここでAzure Portalより、対象となるSQL Data Warehouseを確認し、バックアップから復元してみたいと思います。

Azure Portalの対象のSQL Data Warehouseのページへ移動したら「復元」を選択

次に「データベース名」や「復元ポイント」を選択し「OK」を押すと、バックアップから、対象のSQL Data Warehouseが復元されます。この際に注意が必要なのは、データベース名は現在起動中のデータベース名を使用できない点です。

今回は「sqldwh-test」というデータベース名のバックアップから復元しようとしているため「sqldwh-test」は使えないので、「sqldwh-test2」というデータベース名で起動させます。データベースが起動した後、もう1度SSMSで接続すると「sqldwh-test2」の作成を確認でき、また「AdventureWorksDWbuildVersion」テーブルの復元も確認できます。

データウェアハウスシステムでは、大規模なデータを取り扱うことが多いので、バックアップの運用やそれらのリストアは、運用上の負荷が高く管理者の頭を悩ませるポイントでした。しかし、PaaS型のSQL Data Warehouseであれば、自動でバックアップを取得してくれますし、また取得したバックアップからのリストアも簡単に行えます。このように運用管理が楽になる点はSQL Data Warehouseの大きな魅力の1つです。

地理冗長バックアップ

SQL Data Warehouseでは地理冗長バックアップ（geoバックアップ）という機能がデフォルトで有効になっています。この機能は地理的に100km以上離れた別のリージョンへ、バックアップが24時間に1回レプリケーションされる機能です。SQL Data Warehouseが稼働しているリージョンで地域的な停電や復旧できない災害が発生した場合も、バックアップデータを保持できます。

日本のユーザーがよく使うリージョンは東日本リージョンあるいは西日本リージョンとなるかと思いますが、東日本リージョンでSQL Data Warehouseを起動させた場合は西日本リージョンへ、逆に西日本リージョンでSQL Data Warehouseを起動させた場合は東日本リージョンへ地理冗長化バックアップの設定がなされ、これを変更することはできません。

万が一、東日本に大規模な災害が発生しAzureの東日本リージョンが復旧できないレベルのダメージを受けたとしても、この地理冗長バックアップの設定がなされていれば、SQL Data Warehouseは西日本リージョンで復旧可能です。地理冗長バックアップ機能を設定しておくことにより、簡単にBCP(事業継続計画)対策を行うことができるのです。

バックアップの使い分け

そもそも、SQL Data Warehouseに格納されるデータは、ローカル冗長（LRS）のAzure Premium Storageにデータが格納されて保護されています。ローカル冗長ストレージではデータは3つに同期された状態で同一リージョン内に保持されています。

ローカルストレージに何か障害が発生したとしても、利用者からは透過的な状態でデータは保護されている状態となっているので、例えばディスク障害などのインフラストラクチャの問題でデータが失われる心配は基本的にありません。ただし、火災、洪水などによるデータセンターレベルでの障害が発生した場合は、3つの冗長化データすべてが失われるおそれがあります。

このような事態に備えるため、地理冗長のバックアップを活用するとよいと思います。一方、自動で取得されるバックアップについては、ユーザーの操作ミスなどによってデータが削除されてしまったなどのいわゆる「ユーザー障害」に対して有効な場面が多くあるように感じます。

山口 正寛


1984年生まれ。大阪府出身、東京都在住。データベースエンジニア。SQL Server、Oracle、MySQL、PostgreSQLなどのデータベースで、小規模から大規模な案件まで数多く経験。現在ではクラウドの流れに逆らうことなく、「データベース×クラウド」をキーワードに案件対応、セミナー活動、執筆活動など幅広く活動中。株式会社システムサポート所属。