Azure App Service でアプリをバックアップおよび復元する
Azure App Service では、アプリのバックアップを簡単に復元できます。 オンデマンドでカスタム バックアップを作成することや、スケジュールされたカスタム バックアップを構成することもできます。 新しいアプリまたはスロットに復元して既存のアプリを上書きすることで、バックアップを復元できます。 この記事では、バックアップを復元する方法とカスタム バックアップを作成する方法について説明します。
バックアップと復元は、 Basic、 Standard、 Premium、 Isolated のレベルでサポートされています。 Basic レベルでは、運用スロットのみをバックアップおよび復元できます。 上位レベルを使用するための App Service プランの拡張の詳細については、 Azure でのアプリのスケールアップに関するページを参照してください。
注意
App Service 環境向け:
- 自動バックアップは、別の App Service 環境内ではなく、App Service 環境自体内でターゲット アプリに復元できます。
- カスタム バックアップは、App Service Environment v2 から App Service Environment v3 へなど、別の App Service 環境のターゲット アプリに復元できます。
- バックアップは、ソース アプリと同じ OS プラットフォームのターゲット アプリに復元できます。
& 復元とディザスター リカバリーのバックアップ
| プラットフォーム | & 復元のバックアップに関するガイダンス | ディザスター リカバリーの ガイダンス |
|---|---|---|
| App Service Web Apps (無料の & 共有価格レベル) |
Web アプリケーションが Free または Shared レベルにデプロイされていて、これらの Web アプリのバックアップと復元機能へのアクセスが必要な場合は、Basic レベル以上にスケールアップしてください。 | リージョンの障害発生時に、App Service リソースを別の Azure リージョンでオンラインに戻します。 2025 年 3 月 31 日から、リージョン全体の障害から復旧するに関する記事で説明されているように、Azure リージョンでの障害発生時に App Service アプリケーションがディザスター リカバリー モードになることはありません。 地域の障害時のダウンタイムとデータ損失を防ぐために、一般的に使用されるディザスター リカバリー手法を実装することをお勧めします。 |
| App Service Web Apps (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 では、オンデマンドのカスタム バックアップを作成したり、自動バックアップを利用したりできます。 自動バックアップは、同じ ASE 内のターゲット アプリに復元することができ、別の ASE には復元できません。 カスタム バックアップは、V2 ASE から V3 ASE へのように、別の ASE 内のターゲット アプリに復元できます。 バックアップは、ソース アプリと同じ OS プラットフォームのターゲット アプリに復元できます。 「Azure App Service でアプリをバックアップおよび復元する」で詳細について参照してください。 |
一般的に使用されるディザスター リカバリー手法を使用して、App Service Environment にデプロイされた Web アプリにディザスター リカバリー ガイダンスを実装することをお勧めします。 |
| Azure Functions (専用) | Azure Functions では、オンデマンドのカスタム バックアップを作成したり、自動バックアップを利用したりできます。 新しいアプリまたはスロットに復元して既存のアプリを上書きすることで、バックアップを復元できます。 詳細については、「Azure App Service でアプリをバックアップおよび復元する」を参照してください。 |
リージョンの障害発生時に Azure Functions アプリ (専用) リソースを別の Azure リージョンでオンラインに戻す方法に関する最新のガイダンスは、「リージョン全体の障害から復旧する - Azure App Service」を参照してください。 2025 年 3 月 31 日から、リージョン全体の障害から復旧するに関する記事で説明されているように、Azure リージョンでの障害発生時に App Service アプリケーションがディザスター リカバリー モードになることはありません。 代わりに、Azure Functions geo ディザスター リカバリーを実装します。 さらに、Azure Functions 専用の一般的に使用されるディザスター リカバリー手法を参照することもできます。 |
| Azure Functions 従量課金 & Premium | 従量課金および Premium プランにデプロイされた Azure Functions では、カスタム バックアップと自動バックアップへのアクセスが提供されません。 Function アプリのコンテンツは、Azure ストレージ アカウントにあります。 [Azure Storage の冗長性] オプションを使用して、障害発生時にストレージ アカウントが可用性と持続性の目標を満たすようにします。 Azure portal のエディターを使用して関数を作成した場合は、既存の関数アプリ プロジェクトを .zip ファイルとしてダウンロードすることもできます。 |
Azure Functions の geo ディザスター リカバリーと信頼性を実装することを強くお勧めします。 |
自動バックアップとカスタム バックアップ
App Service には、2 種類のバックアップがあります。 自動バックアップは、サポートされている価格レベルを使用している限り、アプリに対して定期的に実行されます。 カスタム バックアップは、初期構成が必要であり、オンデマンドで、またはスケジュールに基づき実行できます。 次の表は、2 つの種類の違いを示しています。
| 特徴量 | 自動バックアップ | カスタム バックアップ |
|---|---|---|
| 価格レベル | Basic、Standard、Premium、Isolated。 | Basic、Standard、Premium、Isolated。 |
| 構成が必要 | 不正解です。 | はい。 |
| バックアップ サイズ | 30 GB。 | 10 GB。このうちの 4 GB はリンクされたデータベースにすることができます。 |
| リンクされたデータベース | バックアップされません。 | 次のリンクされたデータベースをバックアップできます: SQL Database、Azure Database for MySQL、Azure Database for PostgreSQL、アプリ内 MySQL。 |
| ストレージ アカウントが必要かどうか | 不正解です。 | はい。 |
| バックアップ頻度 | 1 時間に 1 回 (構成不可)。 | 構成可能。 |
| 保持 | 30 日間 (構成不可)。 - 1～3 日目: 1 時間ごとのバックアップが保持されます。 - 4～14 日目: 3 時間ごとのバックアップが保持されます。 - 15～30 日目: 6 時間ごとのバックアップが保持されます。 |
0 から 30日間または無期限。 |
| ダウンロード可能 | いいえ。 | Azure Storage BLOB として可能。 |
| 部分バックアップ | サポートされていません。 | サポートしています。 |
| VNet 経由でバックアップする | サポートされていません。 | サポートしています。 |
バックアップを復元する
注意
App Service は、バックアップの復元中にターゲット アプリやターゲット スロットを停止します。 運用アプリのダウンタイムを最小限に抑えるために、最初にバックアップをデプロイ スロットに復元し、その後、運用に切り替えてください。
Azure portal のアプリ管理ページの左側のメニューで、[バックアップ] を選択します。 [バックアップ] ページに、アプリのすべての自動バックアップとカスタム バックアップ、およびそれぞれの状態が一覧表示されます。
[復元] リンクをクリックして、自動バックアップまたはカスタムで復元するバックアップを選びます。
[バックアップの詳細] セクションが自動的に設定されます。
[Choose a destination] (復元先の選択) で復元先を指定します。 新しいアプリに復元するには、[App Service] ボックスで [新規作成] を選択します。 新しいデプロイ スロットに復元するには、[デプロイ スロット] ボックスで [新規作成] を選択します。
既存のスロットを選択すると、そのファイル システム内の既存のすべてのデータが消去され、上書きされます。 運用スロットの名前はアプリ名と同じです。
[詳細オプション] で、サイト構成の復元を選択できます。
[復元] をクリックします。
カスタム バックアップを作成する
Azure portal のアプリ管理ページの左側のメニューで、[バックアップ] を選択します。
[バックアップ] ページの上部にある [カスタム バックアップの構成] を選択します。
[ストレージ アカウント] で、(同じサブスクリプション内の) 既存のストレージ アカウントを選択するか、[新規作成] を選択します。 [コンテナー] でも同じ操作を行います。
リンクされたデータベースをバックアップするには、[次: 詳細設定]>[データベースを含める] を選択し、バックアップするデータベースを選択します。
注意
サポートされるデータベースをこの一覧に表示するには、その接続文字列が、アプリの [構成] ページの [接続文字列] セクションに存在している必要があります。
アプリ内 MySQL データベースは、構成しなくても常にバックアップされます。 接続文字列を追加するなど、アプリ内 MySQL データベースを手動で設定すると、バックアップが正しく動作しない場合があります。
[構成] をクリックします。
ストレージ アカウントとコンテナーが構成された後、いつでもオンデマンド バックアップを開始できます。 オンデマンド バックアップは無期限に保持されます。
[バックアップ] ページの上部にある [今すぐバックアップ] を選択します。
カスタム バックアップは、進行状況インジケーターと共に一覧に表示されます。 エラーで失敗した場合は、行項目を選択してエラー メッセージを表示できます。
スケジュールされたカスタム バックアップを構成する
[カスタム バックアップの構成] ページで、[スケジュールの設定] を選択します。
必要に応じてバックアップのスケジュールを構成し、[構成] を選択します。
リンクされたデータベースのバックアップと復元する
カスタム バックアップには、リンクされたデータベースを含めることができます (Azure Virtual Network 経由でバックアップが構成されている場合を除く)。 バックアップにリンクされたデータベースが含まれていることを確認するには、次の操作を行います。
- リンクされたデータベースがサポートされていることを確認します。
- データベースを指す接続文字列を作成します。 データベースは、アプリの構成に有効な接続文字列がある場合、アプリに "リンクされている" と見なされます。
- 「カスタム バックアップを作成する」の手順に従って、[詳細設定] タブでリンクされたデータベースを選択します。
カスタム バックアップに含まれているデータベースを復元するには、次の手順に従います。
- 「バックアップの復元」の手順に従います。
- [詳細オプション] で、[データベースを含める] を選択します。
トラブルシューティング情報については、「リンクされたデータベースがバックアップされないのはなぜですか?」を参照してください。
Azure Virtual Network 経由でのバックアップと復元 (プレビュー)
カスタム バックアップを使用すると、次の要件が満たされている場合に、ファイアウォールで保護されたストレージ アカウントにアプリのファイルと構成データをバックアップできます。
- アプリは仮想ネットワークと統合されているか、アプリが v3 App Service 環境内にあります。
- ストレージ アカウントには、アプリが統合されているか、v3 App Service 環境が作成された仮想ネットワークからのアクセス権が付与されています。
Azure Virtual Network 経由でのバックアップと復元には:
- カスタム バックアップを構成するとき、[仮想ネットワーク統合経由のバックアップ/復元] を選択します。
- [構成] を選択して設定を保存します。
チェックボックスが表示されない場合、またはチェックボックスが無効になっている場合、前述の要件を満たしていることを確認します。
構成が保存されると、手動バックアップ、スケジュールされたバックアップ、復元が仮想ネットワーク経由で行われます。 アプリ、仮想ネットワーク、またはストレージ アカウントに変更を加え、アプリが仮想ネットワーク経由でストレージ アカウントにアクセスできないようにすると、バックアップ操作または復元操作に失敗します。
部分バックアップを構成する
部分バックアップは、(自動バックアップではなく) カスタム バックアップでサポートされます。 アプリのすべてをバックアップしたくない場合があります。 次に例をいくつか示します。
- 古いブログの投稿や画像などの、変更されることがない静的コンテンツを含むアプリを 毎週バックアップするように設定 している。
- アプリのコンテンツが 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 接続が必要です。 接続を試みるときに、SSLオプションを指定して再試行してください。 | Azure Database for MySQL と Azure Database for PostgreSQL への SSL 接続は、データベース バックアップではサポートされていません。 代わりに、それぞれのデータベースでネイティブのバックアップ機能を使用してください。 |
スクリプトで自動化する
Azure CLI または Azure PowerShell を使用すると、バックアップ管理をスクリプトで自動化できます。
サンプルについては、以下を参照してください。
よく寄せられる質問
- バックアップは増分更新ですか、または完全バックアップですか?
- Azure Functions は自動バックアップをサポートしていますか?
- 自動バックアップには何が含まれますか?
- カスタム バックアップには何が含まれますか?
- リンクされたデータベースがバックアップされないのはなぜですか?
- バックアップ サイズが許容最大値を超えた場合はどうなりますか?
- セキュリティ機能が有効になっているストレージ アカウントを使用できますか?
- 異なるサブスクリプションにアプリを復元するにはどうすればよいですか?
- 同じサブスクリプション内でも別のリージョンにあるアプリにどのように復元したらよいですか?
- 自動バックアップの保存場所
- 自動バックアップの停止方法
バックアップは増分更新ですか、または完全バックアップですか?
各バックアップは増分更新ではなく、アプリの完全なオフライン コピーです。
Azure Functions は自動バックアップをサポートしていますか?
自動バックアップは、専用 (App Service)Basic、Standard または Premium レベルの Azure Functions で利用できます。 自動バックアップでは、従量課金またはエラスティック Premium 価格レベルの Function App はサポートされません。
自動バックアップには何が含まれますか?
次の表は、自動バックアップでバックアップされるコンテンツを示しています。
| 設定 | 復元の可否 |
|---|---|
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 経由でのバックアップと復元 (プレビュー)」を参照してください。
異なるサブスクリプションにアプリを復元するにはどうすればよいですか?
- Azure Storage コンテナーへのカスタム バックアップを行います。
- ローカル コンピューターにバックアップ ZIP ファイルをダウンロードします。
- ターゲット アプリの [バックアップ] ページで、上部のメニューの [復元] を選択します。
- [バックアップの詳細] の [ソース] で、[ストレージ] を選択します。
- 任意のストレージ アカウントを選択します。
- [Zip ファイル] で、[ファイルのアップロード] を選択します。
- [名前] で [参照] を選択し、ダウンロードした ZIP ファイルを選択します。
- 「バックアップを復元する」で行ったように、残りのセクションを構成します。
同じサブスクリプション内でも別のリージョンにあるアプリにどのように復元したらよいですか?
手順は、「同じサブスクリプション内でも別のリージョンにあるアプリにどのように復元したらよいですか?」と同じです。
自動バックアップの保存場所
自動バックアップはシンプルで、App Service と同じデータセンターに保存されるため、ディザスター リカバリー プランとして依存しないでください。
自動バックアップの停止方法
自動バックアップは停止できません。 自動バックアップはプラットフォームに保存され、基になるアプリ インスタンスやそのストレージには影響がありません。