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

  • [アーティクル]

重要

Azure Database for MariaDB は、提供終了予定です。 Azure Database for MySQL に移行することを強くお勧めします。 Azure Database for MySQL への移行の詳細については、「Azure Database for MariaDB の動作」を参照してください。

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

バックアップ

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

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

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

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

Basic ストレージ サーバー

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

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

最大 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 からサポート チケットを開いてください。

最大 16 TB のストレージを持つ汎用ストレージ サーバー

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

差分スナップショット バックアップは、少なくとも 1 日実行されます。 差分スナップショット バックアップは、固定のスケジュールでは実行されません。 差分スナップショット バックアップは 24 時間ごとに実行されます。ただし、前回の差分バックアップ以降、トランザクション ログ (MariaDB の binlog) が 50 GB を超える場合は除きます。 1 日に最大 6 個の差分スナップショットを生成できます。

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

バックアップ保有期間

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

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

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

バックアップの長期保有

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

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

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

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

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

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

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

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

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

復元

Azure Database for MariaDB で復元を実行すると、元のサーバーのバックアップから新しいサーバーが作成され、そのサーバーに含まれているすべてのデータベースが復元されます。

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

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

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

重要

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

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

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

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

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

geo リストア

geo 冗長バックアップ用にサーバーを構成した場合は、サービスを使用できる別の Azure リージョンにサーバーを復元できます。 最大 4 TB のストレージをサポートするサーバーは、geo ペアリージョンに、または 最大 16 TB のストレージをサポートする任意のリージョンに、復元することができます。 最大 16 TB のストレージをサポートするサーバーでは、16 TB のサーバーをサポートするリージョンにも、geo バックアップを復元できます。 サポートされているリージョンの一覧については、「Azure Database for MariaDB の価格レベル」をご覧ください。

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

重要

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

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

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

復元後のタスクの実行

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

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

次のステップ