この記事では、Azure Files のバックアップについてよくある質問への回答を示します。 一部の回答は、より詳しい情報を扱った記事にリンクされています。 また、Microsoft Q&A の質問ページに Azure Backup サービスに関する質問を投稿してディスカッションすることもできます。
この記事の各セクションの内容をひととおり確認するには、右側の「
Azure Files のバックアップ ジョブの構成
有効な Azure ファイル共有を含む、保護したいストレージ アカウントの一部が表示されないのはなぜですか?
ストレージ アカウントがサポートされているストレージ アカウントの種類のいずれかに属していることを確実にするために、「
バックアップを構成しようとしているときに、ストレージ アカウントに Azure ファイル共有の一部が表示されないのはなぜですか。
その Azure ファイル共有が既に同じ Recovery Services コンテナー内で保護されているかどうかと、その Azure ファイル共有を最近削除したかどうかを確認してください。
ストレージ アカウントのロックを有効にすることが推奨されるのはなぜですか?
Azure Files の現在のバックアップ ソリューションでは、スナップショットはバックアップ対象のファイル共有と同じストレージ アカウントに保持されます。 ストレージ アカウントが削除されると、すべてのスナップショットが失われます。 誤って削除されないようにアカウントを保護するため、Azure Backup によってストレージ アカウントに削除ロックが設定されます。 つまり、許可されているユーザーはリソースを読んだり変更したりできますが、削除することはできません。 また、このロックにより、ストレージ アカウントの下にあるファイル共有の削除も制限されます。 そのため、ストレージ アカウントとファイル共有の両方が不注意による削除から保護されます。
Azure Files Sync で同期グループに接続されているファイル共有を保護することはできますか?
はい。 同期グループに接続されている Azure ファイル共有の保護は有効になっています。
ファイル共有をバックアップしようとして、ストレージ アカウント内のファイル共有を検出するために、そのストレージ アカウントを選択しました。 しかし、それらを保護することはしませんでした。 これらのファイル共有を他のコンテナーで保護するにはどうすればよいのですか?
バックアップを試みる際、ストレージ アカウントを選択して、その中からファイル共有を検出すると、これを行ったストレージ アカウントがコンテナーに登録されます。 別のコンテナーでファイル共有を保護する場合は、このコンテナーから選択したストレージ アカウントを
ファイル共有のバックアップを構成するためにコンテナーを変更できないのはなぜですか?
ストレージ アカウントが既にコンテナーに登録されているか、またはストレージ アカウント内の他のファイル共有がコンテナーを使用して保護されている場合、それを変更することはできません。 1 つのストレージ アカウントに存在するすべてのファイル共有は、必ず同じコンテナーで保護する必要があります。 コンテナーを変更する必要がある場合は、接続されているコンテナーから
自分のファイル共有のバックアップ先コンテナーを変更することはできますか?
はい。 しかし、接続されているコンテナーからの
同じストレージ アカウントにある 2 つの異なるファイル共有を別々のコンテナーで保護することはできますか?
いいえ。 1 つのストレージ アカウントに存在するすべてのファイル共有は、必ず同じコンテナーで保護する必要があります。
Backup
上限に達したエラーのためにバックアップが失敗し始めた場合はどうすればよいですか?
どの時点でも、ファイル共有のスナップショットを 200 個まで作成することができます。 この制限には、ポリシーの定義に従って Azure Backup により作成されたスナップショットの数も含まれます。 この制限に達した後でバックアップが失敗するようになったら、将来のバックアップを正常に実行できるよう、オンデマンド スナップショットを削除してください。
バックアップ ポリシー構成に相当するスナップショットの合計数はどのように計算されますか?
次の表では、バックアップ ポリシーの構成に従ったスナップショット数について説明します。
| バックアップ頻度 | 保持期間 | スナップショット数 |
|---|---|---|
| 毎日 | 日、週、月、年単位のバックアップ用に構成されたリテンション期間の値を追加します。 たとえば、次の値を使用してバックアップ ポリシーを構成します。 - 日単位のリテンション期間: 30 日 - 週単位のリテンション期間: 40 週 - 月単位のリテンション期間: 4 か月 - 年単位のリテンション期間: 6 年 |
これは、80 個のスナップショット (30+40+4+6) に相当します。 |
| 1 時間ごと | 期限切れのスナップショットの削除に遅延が発生した場合のために、バッファーが割り当てられます。 たとえば、次のようにバックアップ ポリシーを構成します。 - スケジュールに従った日単位のスナップショットの数: 6 - 日単位のリテンション期間: 30 日 - 月単位のリテンション期間: 11 か月 - 年単位のリテンション期間: 8 年 |
毎日のスナップショットごとに 1 日のバッファーを考慮すると、30 日間の日単位のリテンション期間は 6 日のスナップショットごとに 31 日と見なされます。 そのため、この構成は 205 [(6X31)+11+8] スナップショットに相当します。 |
復元
削除した Azure ファイル共有から復旧できますか。
ファイル共有が論理的に削除された状態にある場合、復元操作を実行するには、ファイル共有の削除を先に取り消しておく必要があります。 削除の取り消し操作によって、ファイル共有がアクティブ状態になり、任意の時点への復元を実行できるようになります。 ファイル共有の削除を取り消す方法については、こちらのリンクをクリックするか、またはファイル共有の削除を取り消すためのスクリプトを参照してください。 ファイル共有が完全に削除されると、コンテンツとスナップショットを復元することはできなくなります。
Azure ファイル共有の保護を停止した場合、バックアップから復元することはできますか。
はい。 保護を停止するときに
進行中の復元ジョブをキャンセルした場合、どうなりますか。
進行中の復元ジョブがキャンセルされると、復元プロセスが停止され、すべてのファイルがキャンセル前に復元されます。ロールバックされずに、構成された変換先 (元の場所または別の場所) は保持されます。
特定の復旧ポイントが表示されないのはなぜですか?
復旧ポイントが一覧にない場合は、有効期限が切れている必要があります。 バックアップポリシーで構成されている保持期間を確認して、バックアップされたファイル共有の復旧ポイントの保有期間を把握することをお勧めします。
バックアップの管理
PowerShell を使用して、Azure ファイル共有のバックアップを構成/管理/復元できますか。
はい。 詳細なドキュメントを
バックアップ ジョブで転送されたデータが MB 単位で 0 であるのはなぜですか。
Azure Files の現在のバックアップ ソリューションでは、データはコンテナーに転送されず、スナップショットはバックアップ ファイル共有と同じストレージ アカウント内に保持されます。 そのため、転送されたデータは MB 単位で 0 になります。
Azure Files のバックアップが、コンテナーの [ストレージ レプリケーションの種類] 設定に基づいてレプリケーションされないのはなぜですか。
コンテナーの [ストレージのレプリケーション] 設定は、Azure Files のバックアップには関係ありません。 これは、現在のソリューションがスナップショット ベースであり、コンテナーに転送されるデータがないためです。 スナップショットは、バックアップされたファイル共有と同じストレージ アカウントに格納されるため、ストレージ アカウントのレプリケーション設定に従ってレプリケートされます。
Azure Backup によって作成されたスナップショットにアクセスしてマウントできますか?
Azure Backup によって作成されたスナップショットはすべて、ポータル、PowerShell、または CLI でスナップショットを表示することでアクセスできます。 Azure Files 共有スナップショットの詳細については、「
バックアップされたファイル共有を別のサブスクリプションに移動した後はどうなりますか?
ファイル共有を別のサブスクリプションに移動すると、Azure Backup によって新しいファイル共有と見なされます。 推奨される手順を以下に示します。
シナリオ:ファイル共有
- 目的のストレージ アカウントとファイル共有 (FS1) を別のサブスクリプション (S2) に移動します。
- V1 コンテナーで、FS1 に対して "データを削除して保護を停止" 操作をトリガーします。
- FS1 をホストしているストレージ アカウントを V1 コンテナーから登録解除します。
- S2 サブスクリプションでコンテナー (V2) を使用して、先ほど S2 に移動した FS1 のバックアップを再構成します。
V2 を使用してバックアップを再構成した後、V1 で作成されたスナップショットは Azure Backup によって管理されなくなることに注意してください。 そのため、必要に応じて、これらのスナップショットを手動で削除する必要があります。
バックアップしたファイル共有を別のリソース グループに移動できますか?
はい、バックアップしたファイル共有を別のリソース グループに移動できます。 ただし、Azure Backup によって新しいリソースと見なされるため、そのファイル共有のバックアップを再構成する必要があります。 また、リソース グループの移動前に作成されたスナップショットは、Azure backup によって管理されなくなります。 そのため、必要に応じて、これらのスナップショットを手動で削除する必要があります。
バックアップについて構成できる保持期間の上限はどの位ですか?
最大保有期間の詳細については、
Azure ファイル共有のバックアップ ポリシーを "日単位のポリシー" から "GFS ポリシー" に変更すると、既存の復旧ポイントとスナップショットにどのような影響がありますか?
日単位のバックアップ ポリシーを GFS ポリシーに変更すると (週/月/年単位の保持期間を追加)、動作は次のようになります。
** 保持期間** :ポリシーを変更する際に週/月/年単位の保持期間を追加すると、スケジュールされたバックアップの一部として作成される将来のすべての復旧ポイントは、新しいポリシーに基づいてタグ付けされます。 既存のすべての復旧ポイントは、日単位の復旧ポイントと見なされるので、週/月/年単位としてタグ付けされません。** スナップショットと復旧ポイントのクリーンアップ** :- 日単位の保持期間が延長される場合、既存の復旧ポイントの有効期限が、新しいポリシーに構成された日単位の保持期間の値に応じて更新されます。
- 日単位の保持期間が短縮される場合、既存の復旧ポイントとスナップショットは、新しいポリシーに構成された日単位の保持期間の値に応じて次のクリーンアップ実行ジョブの削除対象としてマークされ、削除されます。
この動作の例を次に示します。
| リテンション期間の種類 | スケジュール | 保持 |
|---|---|---|
| 毎日 | 毎日午後 8 時 | 100 日間 |
| リテンション期間の種類 | スケジュール | 保持 |
|---|---|---|
| 毎日 | 毎日午後 9 時 | 50 日間 |
| 週単位 | 日曜日午後 9 時 | 3 週間 |
| 月単位 | 最終月曜日午後 9 時 | 1 か月 |
| 年単位 | 1 月第 3 日曜日午後 9 時 | 4 年間 |
影響
既存の復旧ポイントの有効期限は、新しいポリシーの日単位の保持期間の値 (50 日) に従って調整されます。 したがって、50 日よりも古い復旧ポイントは削除対象としてマークされます。
既存の復旧ポイントには、新しいポリシーに基づいた週/月/年単位のタグ付けはされません。
今後のすべてのバックアップは、新しいスケジュール (午後 9 時) に従ってトリガーされます。
今後のすべての復旧ポイントの有効期限は、新しいポリシーに合わせて調整されます。
Note
ポリシーの変更は、スケジュールされたバックアップ ジョブ実行の一部として作成された復旧ポイントにのみ影響します。 オンデマンド バックアップの場合、保持期間はバックアップ作成時に指定する
既存の GFS ポリシーを変更すると、既存の復旧ポイントにどのような影響がありますか?
ファイル共有に新しいポリシーが適用されると、今後スケジュールされているバックアップはすべて、変更されたポリシーで構成されているスケジュールに従って実行されます。 既存のすべての復旧ポイントの保持期間は、構成された新しい保持値に従って調整されます。 つまり、保持期間が延長された場合、既存の復旧ポイントは、新しいポリシーに従って保持されるようにマーキングされます。 保持期間が短縮された場合、それらは次回のクリーンアップ ジョブで排除対象としてマーキングされて、その後削除されます。
この動作の例を次に示します。
| リテンション期間の種類 | スケジュール | 保持 |
|---|---|---|
| 毎日 | 毎日午後 8 時 | 50 日間 |
| 週単位 | 月曜日午後 8 時 | 3 週間 |
| リテンション期間の種類 | スケジュール | 保持 |
|---|---|---|
| 毎日 | 毎日午後 9 時 | 10 日 |
| 週単位 | 月曜日午後 9 時 | 2 週間 |
| 月単位 | 最終月曜日午後 9 時 | 2 か月間 |
既存の日単位の復旧ポイントの有効期限は、新しい日単位のリテンション期間の値 (10 日間) に従って調整されます。 そのため、10 日よりも古い日単位の復旧ポイントは削除されます。
既存の週単位の復旧ポイントの有効期限は、新しい週単位のリテンション期間の値 (2 週間) に従って調整されます。 そのため、2 週間よりも古い週単位の復旧ポイントは削除されます。
月単位の復旧ポイントは、新しいポリシー構成に基づいた今後のバックアップの一部としてのみ作成されます。
今後のすべての復旧ポイントの有効期限は、新しいポリシーに合わせて調整されます。
Note
ポリシーの変更は、スケジュールされたバックアップの一部として作成された復旧ポイントにのみ影響します。 オンデマンド バックアップの場合、保持期間はバックアップ作成時に指定する
Azure Files バックアップ ポリシーの [期間] 属性は何を表しますか?
[期間] 属性は、その日の最後のバックアップのタイムスタンプを判別するのに役立ちます。
たとえば、[開始時刻] が "午前 x 時" で、[期間] が "y 時間" の場合、ポリシーで定義されている [スケジュール] 属性に基づいて、バックアップは "午前 x 時" から (午前 x 時 + y 時間) の間でスケジュールされます。 この属性を使用すると、ファイル共有コンテンツに更新操作が頻繁に行われる場合に、作業時間中にのみバックアップがトリガーされるようにできます。そのため、複数のスナップショットを取得することで、データを誤った変更から保護できます。
バックアップは、開始時刻、スケジュール、期間の各属性に基づいてどのようにスケジュールされますか?
たとえば、次の構成でポリシーを作成したとします。
- 開始時刻: 午前 9 時
- スケジュール: 4 時間ごと
- 期間: 12 時間
これらの値に基づいて、バックアップの時間枠は、午前 9 時から (午前 9 時 + 12 時間)、つまり午前 9 時から午後 9 時として計算されます。 そのため、すべてのバックアップは、この時間枠内でスケジュールされます。
1 日の最初のバックアップは、ポリシーに記載されている開始時刻 (午前 9 時) にトリガーされ、スケジュールにより、連続するバックアップの間の時間差 (つまり 4 時間) が決まります。 この計算によって、バックアップ スケジュールは、午前 9 時、午後 1 時 (午前 9 時 + 4 時間)、午後 5 時 (午後 1 時 + 4 時間)、午後 9 時 (午後 5 時 + 4 時間) になります。
計算したバックアップ時間枠の終了時刻は午後 9 時だったので、この時間以降、バックアップはトリガーされません。
"The selected configuration will trigger only 1 backup per day (選択した構成ではバックアップは 1 日 1 回のみトリガーされます)" というエラーが表示されるのはなぜですか?
このエラーは、期間を超えるスケジュールを指定した場合に発生します。 たとえば、[開始時刻] を午前 9 時、[スケジュール] を 6 時間、[期間] を 4 時間として構成したとします。 このシナリオでは、バックアップ ジョブでトリガーできる唯一の時間は午前 9 時です。その理由は、次回の午後 3 時 (午前 9 時 + 6 時間) はバックアップの時間枠の午前 9 時から午後 1 時 (午前 9 時 + 4 時間) を越えるためです。
これを修正するには、スケジュールまたは期間を調整するか、[毎時] の代わりに、 [毎日] を選択することをお勧めします。
"The selected configuration extends backup window to next day (選択した構成ではバックアップの時間枠が翌日に達します)" というエラーが表示されるのはなぜですか?
このエラーは、バックアップのスケジュールと期間に基づいて決定されたバックアップ時間枠の開始時刻と終了時刻が 2 つの異なる日になる場合に発生します。
たとえば、次のパラメーターを使用してポリシーを構成したとします。
- スケジュール: 4 時間ごと
- 開始時刻: 午後 12 時
- 期間: 15 時間
この構成に基づいて、バックアップの時間枠は午後 12 時から午前 3 時 (午後 12 時 + 15 時間) になります。 開始と終了の時刻は 2 つの異なる日になるので、開始時刻または期間を調整して、同じ日になるようにすることをお勧めします。
上記の構成の開始時刻を午前 6 時に変更するとします。 これで、バックアップの時間枠は午前 6 時から午後 9 時 (午前 6 時 + 15 時間) になります。 これは、サポートされている構成です。
頻度を [毎日] から [毎時] に切り替えると、既存の復旧ポイントにどのような影響がありますか?
[毎日] から [毎時] に切り替えると、動作は次のようになります。
** 保持期間** :ポリシーを変更する際に週/月/年単位の保持期間を追加すると、スケジュールされたバックアップの一部として作成される将来のすべての復旧ポイントは、新しいポリシーに基づいてタグ付けされます。 既存のすべての復旧ポイントは、引き続き日単位の復旧ポイントと見なされるので、週/月/年単位としてタグ付けされません。** スナップショットと復旧ポイントのクリーンアップ** :- 日単位の保持期間が延長される場合、既存の日単位復旧ポイントの有効期限が、新しいポリシーに構成された日単位の保持期間の値に応じて更新されます。
- 日単位の保持期間が短縮される場合、既存の日単位の復旧ポイントとスナップショットは、新しいポリシーに構成された日単位の保持期間の値に応じて次のクリーンアップ実行ジョブの削除対象としてマークされ、削除されます。
リース スナップショット
スナップショットにアクティブなリースがある場合、ストレージ アカウントの削除はブロックされますか。
いいえ。ストレージ アカウントの削除は、スナップショットのリースによってブロックされません。
スナップショットのリースを使用してバックアップされたファイル共有を削除するための推奨される方法は何ですか?
バックアップされたファイル共有に対して、データ削除による保護の停止操作を実行することをお勧めします。
この操作の後、Azure Backup はリースを解放し、すべてのスナップショットを削除します。 その後、ファイル共有を削除できます。
Azure Backup はリースをさかのぼって取得しますか?
いいえ。Azure Backup は、この機能のリリース後に作成されたスナップショットのリースのみを取得します。
ソフト削除状態からの削除が取り消されたファイル共有のスナップショットでリースは有効ですか。
いいえ。 リースされたスナップショットを含むファイル共有を削除した場合、ファイル共有の削除が取り消された場合、リースは適用されません。
ストレージ アカウント内のファイル共有に対して異なるバックアップ ポリシーを構成できますか?
はい。異なるバックアップ ポリシーを使用して、同じ Recovery Services コンテナー内のストレージ アカウント内のファイル共有を保護できます。
次のステップ
[ Azure ファイル共有のバックアップ中の問題のトラブルシューティング](troubleshoot-azure-files.md)