次の方法で共有


Azure App Service でアプリをバックアップおよび復元する

Azure App Service では、アプリのバックアップを簡単に復元できます。 オンデマンドでカスタム バックアップを作成することや、スケジュールされたカスタム バックアップを構成することもできます。 既存のアプリを上書きするか、新しいアプリまたはスロットに復元することで、バックアップを復元できます。 この記事では、バックアップを復元する方法とカスタム バックアップを作成する方法について説明します。

バックアップと復元は、BasicStandardPremiumIsolated のレベルでサポートされています。 Basic レベルでは、運用スロットのみをバックアップおよび復元できます。 上位レベルを使用するための App Service プランの拡張の詳細については、 Azure でのアプリのスケールアップに関するページを参照してください。

注意

App Service 環境向け:

  • 自動バックアップは、別の App Service Environment ではなく、同じ App Service Environment 内のターゲット アプリに復元できます。
  • カスタム バックアップは、App Service Environment v2 から App Service Environment v3 へなど、別の App Service Environment 内のターゲット アプリに復元できます。
  • バックアップは、ソース アプリと同じ OS プラットフォームのターゲット アプリに復元できます。

バックアップと復元と、ディザスター リカバリーの比較

プラットフォーム バックアップと復元のガイダンス ディザスター リカバリーの ガイダンス
App Service Web アプリ
(Free および Shared 価格レベル)
Web アプリケーションが Free または Shared レベルにデプロイされていて、これらの Web アプリのバックアップと復元機能へのアクセスが必要な場合は、Basic レベル以上にスケールアップしてください。 リージョンの障害発生時に、App Service リソースを別の Azure リージョンでオンラインに戻します

2025 年 3 月 31 日から、リージョン全体の障害から復旧するに関する記事で説明されているように、Azure リージョンでの障害発生時に App Service アプリケーションがディザスター リカバリー モードになることはありません。 地域の障害時のダウンタイムとデータ損失を防ぐために、一般的に使用されるディザスター リカバリー手法を実装することをお勧めします。
App Service Web アプリ
(Basic、Standard、Premium の価格レベル)
Azure App Service では、オンデマンドのカスタム バックアップを作成したり、自動バックアップを利用したりできます。 既存のアプリを上書きするか、新しいアプリまたはスロットに復元することで、バックアップを復元できます。

詳細については、「Azure App Service でアプリをバックアップおよび復元する」を参照してください。
リージョンの障害発生時に App Service リソースを別の Azure リージョンでオンラインに戻す方法に関する最新のガイダンスは、「リージョン全体の障害から復旧する - Azure App Service」を参照してください。

2025 年 3 月 31 日から、リージョン全体の障害から復旧するに関する記事で説明されているように、Azure App Service の Web アプリケーションが Azure リージョンでの障害発生時にディザスター リカバリー モードになることはなくなります。 地域的な障害が発生した場合に Web アプリの機能やデータが失われるのを防ぐため、一般的に使用されるディザスター リカバリー手法 を実装することをお勧めします。
App Service Environment (V2 と V3) Azure App Service Environment では、オンデマンドのカスタム バックアップを作成したり、自動バックアップを使用したりできます。 自動バックアップは、別の App Service Environment ではなく、同じ App Service Environment 内のターゲット アプリに復元できます。 カスタム バックアップは、別の App Service Environment 内のターゲット アプリに復元できます (V2 App Service Environment から V3 App Service Environment へなど)。 バックアップは、ソース アプリと同じ OS プラットフォームのターゲット アプリに復元できます。

Azure App Service でアプリをバックアップおよび復元する」で詳細について参照してください。
一般的に使用されるディザスター リカバリー手法を使用して、App Service Environment にデプロイされた Web アプリにディザスター リカバリー ガイダンスを実装することをお勧めします。
Azure Functions:
専用プラン
専用 (App Service) プランで関数アプリを実行している場合、必要な関数アプリのコンテンツは組み込みのストレージを使用して維持されます。 専用プランでは、オンデマンドのカスタム バックアップを作成したり、自動バックアップを使用したりできます。 既存のアプリを上書きするか、新しいアプリまたはスロットに復元することで、バックアップを復元できます。

詳細については、「Azure App Service でアプリをバックアップおよび復元する」を参照してください。

Azure Files は専用プランでは使用されませんが、Azure Files 接続でアプリを誤って構成した場合、バックアップはサポートされません。
リージョンの障害発生時に専用プランの関数アプリ リソースを別の Azure リージョンでオンラインに戻す方法に関する最新のガイダンスは、「リージョン全体の障害から復旧する - Azure App Service」を参照してください。

2025 年 3 月 31 日から、リージョン全体の障害から復旧するに関する記事で説明されているように、Azure リージョンでの障害発生時に App Service アプリケーションがディザスター リカバリー モードになることはありません。 代わりに、関数アプリの信頼性を計画する必要があります。

また、専用プランの関数アプリに一般的に使用されるディザスター リカバリー手法を参照することもできます。
Azure Functions:
Flex 従量課金、
従量課金、Premium プラン
Flex 従量課金プラン従量課金プラン、または Premium プランで実行される関数アプリは、App Service でカスタムまたは自動バックアップ機能を使用することはできません。 これらの動的スケール プランでは、関数アプリのコンテンツは Azure Storage に保持されます。 [Azure Storage の冗長性] オプションを使用して、障害発生時にストレージ アカウントが可用性と持続性の目標を満たすようにします。

Azure portal から既存の関数アプリ プロジェクトを .zip ファイルとしてダウンロードすることもできます。
関数アプリで信頼性を計画することを強くお勧めします。

自動バックアップとカスタム バックアップ

App Service には、2 種類のバックアップがあります。 自動バックアップは、サポートされている価格レベルを使用している限り、アプリに対して定期的に作成されます。 カスタム バックアップは、初期構成が必要であり、オンデマンドで、またはスケジュールに基づいて実行できます。 次の表は、2 つの種類の違いを示しています。

特徴量 自動バックアップ カスタム バックアップ
価格レベル BasicStandardPremiumIsolated BasicStandardPremiumIsolated
構成が必要 いいえ はい。
バックアップ サイズ 30 GB。 10 GB。このうちの 4 GB はリンクされたデータベースにすることができます。
リンクされたデータベース バックアップされません。 次のリンクされたデータベースをバックアップできます: SQL DatabaseAzure Database for MySQLAzure Database for PostgreSQLアプリ内 MySQL
ストレージ アカウントが必要かどうか いいえ はい。
バックアップ頻度 1 時間に 1 回 (構成不可)。 構成可能。
保持 30 日間 (構成不可)。
- 1~3 日目: 1 時間ごとのバックアップが保持されます。
- 4 日から 14 日: 3 時間ごとにバックアップが保持されます。
- 15 日から 30 日: 6 時間ごとにバックアップが保持されます。
0 から 30日間または無期限。
ダウンロード可能 いいえ。 Azure Storage BLOB として可能。
部分バックアップ サポートされていません。 サポート対象。
仮想ネットワーク経由でバックアップする サポートされていません。 サポートしています。

バックアップを復元する

注意

App Service は、バックアップの復元中にターゲット アプリやターゲット スロットを停止します。 運用アプリのダウンタイムを最小限に抑えるために、最初にバックアップをデプロイ スロットに復元し、その後、運用に切り替えてください。

  1. Azure portal のアプリ管理ページの左側のメニューで、[バックアップ] を選択します。 [バックアップ] ページに、アプリのすべての自動バックアップとカスタム バックアップ、およびそれぞれの状態が一覧表示されます。

    バックアップ ページを開く方法を示すスクリーンショット。

  2. [復元] リンクを選んで、復元する自動バックアップまたはカスタム バックアップを選びます。

    復元リンクの選択方法を示すスクリーンショット。

  3. [バックアップの詳細] セクションが自動的に設定されます。

  4. [Choose a destination] (復元先の選択) で復元先を指定します。 新しいアプリに復元するには、[App Service] ボックスで [新規作成] を選択します。 新しいデプロイ スロットに復元するには、[デプロイ スロット] ボックスで [新規作成] を選択します。

    既存のスロットを選択すると、そのファイル システム内の既存のすべてのデータが消去され、上書きされます。 運用スロットの名前はアプリ名と同じです。

  5. [詳細オプション] で、サイト構成の復元を選択できます。

  6. [復元] を選択します。

カスタム バックアップを作成する

  1. Azure portal のアプリ管理ページの左側のメニューで、[バックアップ] を選択します。

    バックアップ ページを開く方法を示すスクリーンショット。

  2. [バックアップ] ページの上部にある [カスタム バックアップの構成] を選択します。

  3. [ストレージ アカウント] で、(同じサブスクリプション内の) 既存のストレージ アカウントを選択するか、[新規作成] を選択します。 [コンテナー] で同じことを行います。

    リンクされたデータベースをバックアップするには、[次: 詳細設定]>[データベースを含める] を選択し、バックアップするデータベースを選択します。

    注意

    サポートされるデータベースをこの一覧に表示するには、その接続文字列が、アプリの [構成] ページの [接続文字列] セクションに存在している必要があります。

    アプリ内 MySQL データベースは、構成しなくても常にバックアップされます。 接続文字列を追加するなど、アプリ内 MySQL データベースを手動で設定すると、バックアップが正しく動作しない場合があります。

  4. [構成] をクリックします。

    ストレージ アカウントとコンテナーが構成された後、いつでもオンデマンド バックアップを開始できます。 オンデマンド バックアップは無期限に保持されます。

  5. [バックアップ] ページの上部にある [今すぐバックアップ] を選択します。

    オンデマンド バックアップの作成方法を示すスクリーンショット。

    カスタム バックアップは、進行状況インジケーターと共に一覧に表示されます。 エラーで失敗した場合は、行項目を選択してエラー メッセージを表示できます。

スケジュールされたカスタム バックアップを構成する

  1. [カスタム バックアップの構成] ページで、[スケジュールの設定] を選択します。

  2. 必要に応じてバックアップのスケジュールを構成してから、[構成] を選択します。

リンクされたデータベースのバックアップと復元する

カスタム バックアップには、リンクされたデータベースを含めることができます (Azure Virtual Network 経由でバックアップが構成されている場合を除く)。 バックアップにリンクされたデータベースが含まれていることを確認するには、次の操作を行います。

  1. リンクされたデータベースがサポートされていることを確認します。
  2. データベースを指す接続文字列を作成します。 データベースは、アプリの構成に有効な接続文字列がある場合、アプリに "リンクされている" と見なされます。
  3. カスタム バックアップを作成する」の手順に従って、[詳細設定] タブでリンクされたデータベースを選択します。

カスタム バックアップに含まれているデータベースを復元するには、次の手順に従います。

  1. バックアップの復元」の手順に従います。
  2. [詳細オプション] で、[データベースを含める] を選択します。

トラブルシューティング情報については、「リンクされたデータベースがバックアップされないのはなぜですか?」を参照してください。

Azure Virtual Network 経由でのバックアップと復元

カスタム バックアップを使用すると、次の要件が満たされている場合に、ファイアウォールで保護されたストレージ アカウントにアプリのファイルと構成データをバックアップできます。

Azure Virtual Network 経由でのバックアップと復元には:

  1. カスタム バックアップを構成するとき、[仮想ネットワーク統合経由のバックアップ/復元] を選択します。
  2. [構成] を選択して設定を保存します。

チェックボックスが表示されない場合、またはチェックボックスが無効になっている場合は、リソースが要件を満たしていることを確認します。

構成が保存されると、手動バックアップ、スケジュールされたバックアップ、復元が仮想ネットワーク経由で行われます。 アプリ、仮想ネットワーク、またはストレージ アカウントを変更し、アプリが仮想ネットワーク経由でストレージ アカウントにアクセスできないようにすると、バックアップまたは復元の操作は失敗します。

部分バックアップを構成する

部分バックアップは、(自動バックアップではなく) カスタム バックアップでサポートされます。 アプリのすべてをバックアップしたくない場合があります。 次に例をいくつか示します。

  • 古いブログの投稿や画像などの、変更されることがない静的コンテンツを含むアプリを 毎週バックアップするように設定 している。
  • アプリには 10 GB を超えるコンテンツがあります (これは、一度にバックアップできる最大量です)。
  • ログ ファイルはバックアップしない。

今後のバックアップで保存する対象からフォルダーとファイルを除外するには、アプリの %HOME%\site\wwwroot フォルダー内に _backup.filter ファイルを作成します。 このファイルに、除外するファイルやフォルダーの一覧を指定します。

ヒント

ファイルにアクセスするには、https://<app-name>.scm.azurewebsites.net/DebugConsole に移動します。 メッセージに従って Azure アカウントにサインインします。

バックアップから除外するフォルダーを識別します。 たとえば、強調表示されたフォルダーおよびファイルを除外したいとします。

バックアップから除外するファイルとフォルダーを示すスクリーンショット。

_backup.filter という名前のファイルを作成し、前のリストをこのファイルに配置します。ただし、ルートの %HOME% は削除します。 1 つのディレクトリまたはファイルを 1 行に配置します。 ファイルの内容は次のようになります。

\site\wwwroot\Images\brand.png
\site\wwwroot\Images\2014
\site\wwwroot\Images\2013

この _backup.filter ファイルを、FTP やその他の方法を使用して、サイトの D:\home\site\wwwroot\ ディレクトリにアップロードします。 Kudu の DebugConsole を使用してファイルを直接作成し、そこにコンテンツを挿入することもできます。

通常と同じ方法、カスタム オンデマンド、またはカスタム スケジュールでバックアップを実行します。 _backup.filter に指定したファイルとフォルダーは、今後のバックアップから除外されます。

注意

_backup.filter により、復元の動作方法が変更されます。 _backup.filter がない場合、バックアップを復元すると、アプリ内の既存のすべてのファイルが削除され、それらのファイルがバックアップ内のファイルに置き換えられます。 _backup.filter がある場合、_backup.filter に含まれるアプリのファイル システム内のコンテンツはそのまま残されます (削除されません)。

バックアップの保存方法

アプリのバックアップを 1 つ以上作成すると、ストレージ アカウントとアプリの [コンテナー] ページにバックアップが表示されます。 ストレージ アカウントでは、各バックアップは、バックアップ データを含む .zip ファイルと、.zip ファイルの内容のマニフェストを含む .xml ファイルで構成されます。 バックアップにアクセスする場合は、これらのファイルを展開して参照できます。実際にアプリの復元を実行する必要はありません。

アプリのデータベースのバックアップは、.zip ファイルのルートに保存されます。 SQL Database の場合、これは BACPAC ファイルで (ファイル拡張子はありません)、インポートできます。 BACPAC のエクスポートに基づいて Azure SQL Database でデータベースを作成するには、Azure SQL Database でデータベースを作成するための BACPAC ファイルのインポートに関する記事を参照してください。

警告

websitebackups コンテナー内のファイルを変更すると、バックアップが無効になり、復元できなくなる可能性があります。

エラー メッセージ

[バックアップ] ページには、各バックアップの状態が表示されます。 失敗したバックアップに関するログの詳細を取得するには、一覧で行項目を選択します。 次の表を使用すると、バックアップのトラブルシューティングを行うのに役立ちます。 エラーが表に記載されていない場合は、サポート チケットを開いてください。

エラー 修正
ストレージ アクセスに失敗しました。 バックアップ スケジュールを削除して再構成します。 または、バックアップ ストレージを再構成します。
Web サイトとデータベースの合計サイズが、バックアップの {0} GB の制限を超えています。 お使いのコンテンツ サイズは {1} GB です。 バックアップから一部のファイルを除外するか、バックアップのデータベース部分を削除して、代わりに外部提供のバックアップを使用します。
サーバー {1} 上のデータベース {0} への接続中にエラーが発生しました: メソッド 'mysql_native_password' を使用した、ユーザー '<username>' のホスト '{1}' に対する認証が、不明なデータベース '<db-name>' というメッセージで失敗しました データベース接続文字列を更新します。
{0} を解決できません。 {1} (CannotResolveStorageAccount) バックアップ スケジュールを削除して再構成します。
ユーザー '{0}' はログインできませんでした。 データベース接続文字列を更新します。
{0} ({1}) のデータベース コピーの作成によって例外がスローされました。 データベース コピーを作成できませんでした。 接続文字列の中で管理ユーザーを使用します。
現在のセキュリティ コンテキストでは、サーバー プリンシパル "<name>" はデータベース "master" にアクセスできません。 このログインで要求されたデータベース "master" を開けません。 ログインに失敗しました。 ユーザー '<name>' はログインできませんでした。 接続文字列の中で管理ユーザーを使用します。
SQL Server への接続を確立しているときにネットワーク関連またはインスタンス固有のエラーが発生しました。 サーバーが見つからないかアクセスできません。 インスタンス名が正しいこと、および SQL Server がリモート接続を許可するように構成されていることを確認してください。 (プロバイダー:名前付きパイプ プロバイダー、エラー:40 - SQL Server への接続を開けませんでした)。 接続文字列が有効であることを確認します。 データベース サーバーの設定で、アプリの送信 IP を許可します。
"Cannot open server "<name>" requested by the login. (ログインにより要求されたサーバー "" を開くことができません。) ログインに失敗しました。 接続文字列が有効であることを確認します。
有効な Shared Access Signature で必須のパラメーターがありません。 バックアップ スケジュールを削除して再構成します。
SSL 接続が必要です。 Specify SSL options and retry when trying to connect. (接続を試みるときに、SSL オプションを指定して再試行してください。) Azure Database for MySQL と Azure Database for PostgreSQL への SSL 接続は、データベース バックアップではサポートされていません。 代わりに、それぞれのデータベースでネイティブのバックアップ機能を使用してください。

スクリプトで自動化する

Azure CLI または Azure PowerShell を使用すると、バックアップ管理をスクリプトで自動化できます。

サンプルについては、以下を参照してください。

よく寄せられる質問

バックアップは増分更新ですか、または完全バックアップですか?

各バックアップは増分更新ではなく、アプリの完全なオフライン コピーです。

Azure Functions は自動バックアップをサポートしていますか?

自動バックアップは、Dedicated (App Service) BasicStandardPremium レベルの Azure Functions に使用できます。 自動バックアップは、従量課金または Elastic Premium 価格レベルの関数アプリではサポートされません。

自動バックアップには何が含まれますか?

次の表は、自動バックアップでバックアップされるコンテンツを示しています。

コンテンツ 復元の可否
Windows アプリ: %HOME% ディレクトリ内のすべてのアプリ コンテンツ。
Linux アプリ: /home ディレクトリ内のすべてのアプリ コンテンツ。
カスタム コンテナー (Windows および Linux): 永続ストレージ内のコンテンツ。
はい
ZIP パッケージから実行したコンテンツ いいえ
Azure Files 共有など、マウントされたカスタム Azure ストレージのコンテンツ いいえ

次の表は、アプリ構成の復元を選択したときに復元されるアプリ構成を示しています。

設定 復元の可否
ネイティブ ログ設定 (Azure ストレージ アカウントとコンテナーの設定を含む) はい
Application Insights の構成 はい
正常性チェック はい
プライベート エンドポイントハイブリッド接続仮想ネットワーク統合などのネットワーク機能 いいえ
認証 いいえ
マネージド ID いいえ
カスタム ドメイン いいえ
TLS/SSL いいえ
スケールアウト いいえ
Azure Monitor を使用する診断 いいえ
アラートとメトリック いいえ
Backup いいえ
関連付けられたデプロイ スロット いいえ
カスタム バックアップでサポートされるリンクされたデータベース No

カスタム バックアップには何が含まれますか?

カスタム バックアップ (オンデマンド バックアップまたはスケジュールされたバックアップ) には、自動バックアップに含まれるすべてのコンテンツと構成、およびリンクされたデータベースが、許容最大サイズまで含まれます。

Azure Virtual Network 経由でバックアップするとき、リンクされたデータベースはバックアップできません。

リンクされたデータベースがバックアップされないのはなぜですか?

リンクされたデータベースは、カスタム バックアップでのみバックアップされ、許容最大サイズまでバックアップされます。 最大バックアップ サイズ (10 GB) または最大データベース サイズ (4 GB) を超えた場合、バックアップは失敗します。 リンクされたデータベースがバックアップされない一般的な理由を次に示します。

  • TLS が有効になっている Azure Database for MySQL のバックアップはサポートされていません。 バックアップが構成されている場合、バックアップ エラーが発生します。
  • TLS が有効になっている Azure Database for PostgreSQL のバックアップはサポートされていません。 バックアップが構成されている場合、バックアップ エラーが発生します。
  • アプリ内 MySQL データベースは、構成しなくても自動的にバックアップされます。 接続文字列を追加するなど、アプリ内 MySQL データベースを手動で設定すると、バックアップが正しく動作しない場合があります。

バックアップ サイズが許容最大値を超えた場合はどうなりますか?

バックアップ サイズが最大サイズを超えた場合、自動バックアップは復元できません。 同様に、最大バックアップ サイズまたは最大データベース サイズを超えると、カスタム バックアップは失敗します。 ストレージ サイズを削減するために、ログ、画像、オーディオ、ビデオなどのファイルを、たとえば Azure Storage に移動することを検討してください。

セキュリティ機能が有効になっているストレージ アカウントを使用できますか?

アプリと同じ仮想ネットワーク トポロジに含まれている場合、ファイアウォールで保護されているストレージ アカウントにバックアップできます。 「Azure Virtual Network 経由でのバックアップと復元」をご覧ください。

異なるサブスクリプションにアプリを復元するにはどうすればよいですか?

  1. Azure Storage コンテナーへのカスタム バックアップを行います。
  2. ローカル コンピューターにバックアップ ZIP ファイルをダウンロードします。
  3. ターゲット アプリの [バックアップ] ページで、上部のメニューの [復元] を選択します。
  4. [バックアップの詳細][ソース] で、[ストレージ] を選択します。
  5. 任意のストレージ アカウントを選択します。
  6. [Zip ファイル] で、[ファイルのアップロード] を選択します。
  7. [名前][参照] を選択し、ダウンロードした ZIP ファイルを選択します。
  8. バックアップを復元する」の説明に従って、残りのセクションを構成します。

同じサブスクリプション内でも別のリージョンにあるアプリにどのように復元したらよいですか?

手順は、「同じサブスクリプション内でも別のリージョンにあるアプリにどのように復元したらよいですか?」と同じです。

自動バックアップの保存場所

自動バックアップは、App Service と同じデータセンターに格納されます。 ディザスター リカバリー計画としては、これらに頼らないようにしてください。

自動バックアップの停止方法

自動バックアップは停止できません。 自動バックアップはプラットフォームに保存され、基になるアプリ インスタンスやそのストレージには影響がありません。

次のステップ

Azure Blob Storage のドキュメント