Azure Database for MySQL でのバックアップと復元

適用対象: Azure Database for MySQL - 単一サーバー

重要

Azure Database for MySQL シングル サーバーは廃止パスにあります。 Azure Database for MySQL フレキシブル サーバーにアップグレードすることを強くお勧めします。 Azure Database for MySQL フレキシブル サーバーへの移行の詳細については、Azure Database for MySQL シングル サーバーの現状に関するページを参照してください

Azure Database for MySQL は、サーバーのバックアップを自動的に作成し、ユーザーが構成したローカル冗長または geo 冗長ストレージに保存します。 バックアップを使用すると、サーバーを特定の時点に復元できます。 不慮の破損または削除からデータを保護するバックアップと復元は、ビジネス継続性戦略の最も重要な部分です。

バックアップ

Azure Database for MySQL では、データ ファイルとトランザクション ログのバックアップが作成されます。 これらのバックアップを使用すると、サーバーを、バックアップの構成済みリテンション期間内の任意の時点に復元できます。 バックアップの既定のリテンション期間は 7 日です。 必要に応じて最大 35 日に設定できます。 すべてのバックアップが、AES 256 ビット暗号化を使用して暗号化されます。

これらのバックアップ ファイルはユーザーに公開されておらず、エクスポートできません。 これらのバックアップは、Azure Database for MySQL の復元操作にのみ使用できます。 mysqldump を使用して、データベースをコピーできます。

バックアップの種類と頻度は、サーバーのバックエンド ストレージによって異なります。

バックアップの種類と頻度

Basic ストレージ サーバー

Basic ストレージは、Basic レベルのサーバーをサポートするバックエンド ストレージです。 Basic ストレージ サーバー上のバックアップは、スナップショットベースです。 完全なデータベース スナップショットは毎日実行されます。 Basic ストレージ サーバーでは差分バックアップは実行されず、すべてのスナップショット バックアップはデータベースの完全バックアップのみです。

トランザクション ログ バックアップは 5 分ごとに実行されます。

General Purpose ストレージ v1 サーバー (最大 4 TB のストレージをサポート)

汎用ストレージは、General Purpose および Memory Optimized レベルのサーバーをサポートするバックエンド ストレージです。 最大 4 TB までの汎用ストレージを持つサーバーでは、完全バックアップは毎週 1 回実行されます。 差分バックアップは 1 日に 2 回実行されます。 トランザクション ログ バックアップは 5 分ごとに実行されます。 最大 4 TB のストレージを持つ汎用ストレージのバックアップは、スナップショット ベースではなく、バックアップ時に IO 帯域幅を消費します。 4 TB のストレージ上にある大規模なデータベース (> 1 TB) の場合は、以下を行うことを検討してください

• バックアップ IO のために、より多くの IOP をプロビジョニングする
• または、任意の Azure リージョンで基となるストレージ インフラストラクチャが利用可能な場合は、最大 16 TB のストレージがサポートされる汎用ストレージに移行することもできます。 最大 16 TB のストレージがサポートされる汎用ストレージの場合、追加料金は発生しません。 16 TB のストレージへの移行については、Azure portal からサポート チケットを開いてください。

General Purpose ストレージ v2 サーバー (最大 16 TB のストレージをサポート)

Azure リージョンのサブセットでは、新しくプロビジョニングされたすべてのサーバーで最大 16 TB のストレージを持つ汎用ストレージがサポートされます。 つまり、最大 16 TB のストレージは、それがサポートされているすべてのリージョンのデフォルトの汎用ストレージです。 これらの最大 16 TB のストレージ サーバー上のバックアップは、スナップショット ベースです。 初回のスナップショット バックアップは、サーバーの作成直後にスケジュールされます。 スナップショット バックアップは、毎日 1 回作成されます。 トランザクション ログ バックアップは 5 分ごとに実行されます。

Basic および General Purpose ストレージの詳細については、ストレージに関するドキュメントを参照してください。

バックアップ保有期間

バックアップは、サーバーのバックアップ保有期間の設定に基づいて保持されます。 7 日間から 35 日間までの保有期間を選択できます。 既定の保有期間は 7 日です。 Azure portal または Azure CLI を使用してバックアップ構成を更新することで、サーバーの作成中またはその後で保有期間を設定することができます。

バックアップのリテンション期間によって、現在からどのくらい遡ってポイントインタイム リストアを取得できるかが管理されます。ポイントインタイム リストアは使用可能なバックアップに基づいているためです。 バックアップの保有期間は、復元の観点から回復期間として扱うこともできます。 バックアップ保有期間内の特定の時点に復旧するために必要なすべてのバックアップは、バックアップ ストレージに保持されます。 たとえば、バックアップの保有期間が 7 日間に設定されている場合、回復期間は過去 7 日間と見なされます。 このシナリオでは、過去 7 日間のサーバーを復元するために必要なすべてのバックアップが保持されます。 バックアップ保有期間が 7 日間である場合:

• General Purpose ストレージ v1 サーバー (最大 4 TB のストレージをサポート) では、最大 2 件までのデータベースの完全バックアップ、すべての差分バックアップ、およびデータベースの最初の完全バックアップからのトランザクション ログ バックアップが保持されます。
• General Purpose ストレージ v2 サーバー (最大 16 TB のストレージをサポート) では、完全なデータベース スナップショットと、過去 8 日間のトランザクション ログ バックアップが保持されます。

長期保存

35 日を超えるバックアップの長期的な保有期間は、現在サービスによってネイティブでサポートされていません。 mysqldump を使用してバックアップを作成し、長期保存のために保存することはできます。 サポート チームでは、これを実現する方法を共有するために、手順のブログ記事を作成しています。

バックアップ冗長オプション

Azure Database for MySQL では、汎用レベルとメモリ最適化レベルで、ローカル冗長バックアップ ストレージまたは geo 冗長バックアップ ストレージのいずれかを柔軟に選択できます。 geo 冗長バックアップ ストレージにバックアップが格納されるとき、そのバックアップは、サーバーがホストされているリージョンに格納されるだけでなく、ペアになっているデータ センターにもレプリケートされます。 この Geo 冗長性により、災害発生時に、より適切な保護が提供され、別のリージョンにサーバーを復元することができます。 Basic レベルでは、ローカル冗長バックアップ ストレージのみが提供されます。

注意

インド中部、フランス中部、アラブ首長国連邦北部、南アフリカ北部の各リージョンでは、General Purpose ストレージ v2 ストレージはパブリック プレビューの段階です。 これらのリージョンで General Purpose ストレージ v2 (最大 16 TB のストレージをサポート) にソース サーバーを作成する場合、geo 冗長バックアップの有効化はサポートされていません。

ローカル冗長から geo 冗長のバックアップ ストレージへの移動

バックアップに対してローカル冗長ストレージまたは geo 冗長ストレージを構成できるのは、サーバーの作成時だけです。 一度サーバーがプロビジョニングされると、バックアップ ストレージ冗長オプションを変更することはできません。 バックアップ ストレージをローカル冗長ストレージから geo 冗長ストレージに移動するには、新しいサーバーを作成し、ダンプと復元を使用してデータを移行することが、サポートされている唯一のオプションです。

バックアップ ストレージのコスト

Azure Database for MySQL は、プロビジョニングされているサーバー ストレージの 100% までをバックアップ ストレージとして追加コストなしで提供します。 バックアップ ストレージを追加で使用した場合は、1 か月ごとに GB 単位で請求されます。 たとえば、サーバーを 250 GB のストレージでプロビジョニングした場合は、サーバーのバックアップに 250 GB の追加のストレージを追加料金なしで利用できます。 250 GB を超えてバックアップに使用されているストレージについては、価格モデルに従って請求されます。

Azure portal で使用可能な Azure Monitor の使用されたバックアップ ストレージ メトリックを使用して、サーバーによって使用されるバックアップ ストレージを監視できます。 このバックアップ ストレージの使用量のメトリックは、サーバーに設定されているバックアップ保持間に基づいて保持されているすべてのデータベースの完全バックアップ、差分バックアップ、ログ バックアップによって使用されるストレージの合計を表します。 バックアップの頻度はサービスによって管理され、前に説明されています。 サーバーで大量のトランザクション アクティビティが発生すると、データベースの合計サイズに関係なく、バックアップ ストレージの使用量が増加する可能性があります。 geo 冗長ストレージの場合、バックアップ ストレージの使用量は、ローカル冗長ストレージの 2 倍になります。

バックアップ ストレージ コストを制御する主な方法は、適切なバックアップ保有期間を設定し、目的の回復目標を達成するための適切なバックアップ冗長オプションを選択することです。 7 日間から 35 日間までの保持期間を選択できます。 汎用サーバーとメモリ最適化サーバーでは、バックアップに geo 冗長ストレージを使用することを選択できます。

復元

Azure Database for MySQL で復元を実行すると、元のサーバーのバックアップから新しいサーバーが作成され、そのサーバーに含まれているすべてのデータベースが復元されます。 元のサーバーが停止状態の場合、復元は現在サポートされていません。

使用できる復元には 2 つの種類があります。

• ポイントインタイム リストアは、いずれのバックアップ冗長オプションでも使用でき、完全バックアップとトランザクション ログ バックアップの組み合わせを利用して、元のサーバーと同じリージョンに新しいサーバーを作成します。
• geo リストアは、サーバーを geo 冗長ストレージ用に構成した場合にのみ使用でき、最も最近作成されたバックアップを利用してサーバーを別のリージョンに復元できます。

サーバーの復旧にかかる推定時間は、次のいくつかの要因によって異なります。

• データベースのサイズ
• 関連するトランザクション ログ数
• 復元時点に復旧するために再生の必要があるアクティビティ量
• 別のリージョンへの復元の場合は、ネットワーク帯域幅
• ターゲット リージョンで処理される、同時実行される復元要求の数
• データベース内のテーブルに主キーが存在するかどうか。 高速復旧を行うには、データベース内のすべてのテーブルに主キーを追加することを検討してください。 テーブルに主キーがあるかどうかを確認するには、次のクエリを使用します。

select tab.table_schema as database_name, tab.table_name from information_schema.tables tab left join information_schema.table_constraints tco on tab.table_schema = tco.table_schema and tab.table_name = tco.table_name and tco.constraint_type = 'PRIMARY KEY' where tco.constraint_type is null and tab.table_schema not in('mysql', 'information_schema', 'performance_schema', 'sys') and tab.table_type = 'BASE TABLE' order by tab.table_schema, tab.table_name;

大規模なデータベースや、非常に活動の激しいデータベースの場合、復元に数時間かかることがあります。 リージョン内で長時間にわたる障害が発生した場合は、ディザスター リカバリーのために、多数の geo リストア要求が開始される可能性があります。 多数の要求がある場合、個々のデータベースでの復旧時間が長くなる可能性があります。 ほとんどのデータベースの復元は、12 時間未満で完了します。

重要

削除されたサーバーを復元できるのは、削除から 5 日以内のみです。その後、バックアップが削除されます。 データベースのバックアップは、サーバーをホストしている Azure サブスクリプションからのみアクセスおよび復元できます。 削除されたサーバーを復元するには、文書化されている手順を参照してください。 管理者は、デプロイ後の誤削除や予期せぬ変更からサーバーのリソースを保護するために、管理ロックを利用できます。

ポイントインタイム リストア

バックアップ冗長オプションに関係なく、バックアップのリテンション期間内の任意の時点への復元を実行できます。 新しいサーバーは、元のサーバーと同じ Azure リージョンに作成されます。 価格レベル、コンピューティング世代、仮想コア数、ストレージ サイズ、バックアップのリテンション期間、およびバックアップ冗長オプションについては、元のサーバーの構成を使用して作成されます。

Note

復元操作の後で既定値にリセットされる (そして、プライマリ サーバーからコピーで上書きされない) サーバー パラメーターが 2 つあります

• time_zone - この値は、既定値 SYSTEM に設定されます
• event_scheduler - event_scheduler は、復元されたサーバーで OFF に設定されます

サーバー パラメーターを再構成して、これらのサーバー パラメーターを設定する必要があります。

ポイントインタイム リストアは複数のシナリオで役に立ちます。 たとえば、ユーザーが誤ってデータを削除したとき、重要なテーブルやデータベースを削除したとき、またはアプリケーションの不具合が原因で、適切なデータが不適切なデータで誤って上書きされた場合などです。

現時点から遡って 5 分前より後の時点に復元するには、次のトランザクション ログのバックアップが作成されるのを待たなければならない可能性があります。

geo リストア

geo 冗長バックアップ用にサーバーを構成した場合は、サービスを使用できる別の Azure リージョンにサーバーを復元できます。

• 汎用ストレージ v1 サーバー (最大 4 TB のストレージをサポート) は、geo ペア リージョンに、または Azure Database for MySQL - 単一サーバー サービスをサポートする任意の Azure リージョンに復元できます。
• General Purpose ストレージ v2 サーバー (最大 16 TB のストレージをサポート) は、General Purpose ストレージ v2 サーバー インフラストラクチャをサポートする Azure リージョンにしか復元できません。 サポートされているリージョンの一覧については、Azure Database for MySQL の価格レベルに関するページをご覧ください。

geo リストアは、サーバーがホストされているリージョンでのインシデントが原因でサーバーが利用できない場合の既定の復旧オプションです。 リージョン内の大規模なインシデントにより、データベース アプリケーションが使用できなくなった場合、geo 冗長バックアップから他の任意のリージョン内のサーバーに、サーバーを復元できます。 geo リストアでは、サーバーの最新のバックアップが利用されます。 バックアップが取得される時刻と、別のリージョンにそのバックアップがレプリケートされる時刻には時間差があります。 この時間差は最大 1 時間なので、障害が発生した場合、最大 1 時間分のデータが損失する可能性があります。

重要

新しく作成されたサーバーに対して geo リストアを実行する場合、初期の完全スナップショット バックアップのコピー時間が大幅に長くなるため、データ サイズによっては初期バックアップの同期が 24 時間より長くかかることがあります。 その後のスナップショット バックアップは増分コピーであるため、サーバーを作成してから 24 時間後には復元がより高速になります。 RTO を定義するために geo リストアを評価している場合は、より適切な評価にするために、サーバーを作成してから 24 時間経過してから geo リストアを評価することをお勧めします。

geo リストア中に変更できるサーバー構成は、コンピューティング世代、仮想コア、バックアップの保有期間、バックアップ冗長オプションなどです。 geo リストア中の、価格レベル (Basic、汎用、またはメモリ最適化) とストレージのサイズの変更はいずれもできません。

復旧の推定所要時間は、データベースのサイズ、トランザクション ログのサイズ、ネットワーク帯域幅、同じリージョン内で同時に復旧するデータベースの合計数など、複数の要因によって異なります。 通常は 12 時間もかかりません。

復元後のタスクの実行

いずれかの復旧メカニズムで復元した後、ユーザーとアプリケーションを元に戻して実行するには、次のタスクを実行する必要があります。

• 元のサーバーを新しいサーバーで置き換える場合は、クライアントとクライアント アプリケーションを新しいサーバーにリダイレクトする
• ユーザーが接続できるように、適切な VNet 規則が適用されていることを確認する。 これらのルールは配信元のサーバーからはコピーされません。
• 適切なログインとデータベース レベルのアクセス許可が適切に指定されていることを確認する
• 必要に応じて、アラートを構成する

次のステップ

• ビジネス継続性の詳細については、ビジネス継続性の概要に関するページを参照してください。
• Azure portal を使って特定の時点に復元するには、Azure portal を使った特定の時点へのサーバーの復元に関するページを参照してください。
• Azure CLI を使って特定の時点に復元するには、CLI を使った特定の時点へのサーバーの復元に関するページを参照してください。