Data Boxを使ってネットワーク接続ストレージ(NAS)からAzureファイル共有へ移行してください

✔️ 適用対象: Microsoft.Storage リソース プロバイダーで作成された従来の SMB ファイル共有

✖️ 適用対象外: Microsoft.FileShares リソース プロバイダーで作成されたファイル共有、または Microsoft.Storage リソース プロバイダーで作成されたクラシック ファイル共有を含む、すべての NFS ファイル共有

この移行記事は、NASとAzure Data Boxというキーワードを含むいくつかの記事の一つです。 この記事がご使用のシナリオに当てはまるかどうかを確認してください。

自分のシナリオが異なる場合は、移行ガイドの表を参照してください。

この記事では、NAS アプライアンスから機能している Azure ファイル共有に移行するために必要な計画、デプロイ、およびネットワークの構成について詳しく説明します。 このガイドでは、Azure Data Boxを一括データトランスポート(オフラインデータトランスポート)に使用しています。

移行の目標

目標は、お使いの NAS アプライアンス上の共有を Azure に移行し、ネイティブの Azure ファイル共有にすることです。 Windows Server を必要とせずに、ネイティブの Azure ファイル共有を使用できます。 この移行は、運用データの整合性と、移行中の可用性が保証される方法で行う必要があります。 後者については、ダウンタイムを最小限に抑えて、通常のメンテナンス期間に収まるか、わずかに超えるだけで済むようにする必要があります。

移行の概要

移行プロセスは、いくつかのフェーズで構成されます。 まず、Azureストレージアカウントとファイル共有を展開し、ネットワーク設定を行います。 その後、Azure Data BoxやRoboCopyを使ってファイルを移行し、変更を追いかけましょう。 最後に、ユーザーやアプリを新たに作成したAzureファイル共有に切り替えます。 以下のセクションでは、移行プロセスの各フェーズについて詳しく説明します。

フェーズ 1:必要な Azure ファイル共有の数を特定する

必要なAzureファイル共有の数を決めてください。 現在、SMB 共有としてユーザーとアプリに対してローカルに共有しているボリュームには、さらに多くのフォルダーが存在する場合があります。 クラウドに移行したいファイル共有数に応じて、1対1のマッピングかシェアグループのいずれかを選択してください。

1 対 1 のマッピングを使用する

シェア数が少ない場合は、1対1のマッピングを使いましょう。 このシナリオを最も簡単に思い描くには、オンプレミスの共有が Azure ファイル共有に 1 対 1 で対応している様子を想像するとよいでしょう。

共有のグループ化を使用する

ファイル共有の数が多い場合は、共有のグループ化を検討してください。 たとえば、人事 (HR) 部門に 15 個の共有がある場合、すべての HR データを 1 つの Azure ファイル共有に格納することを検討できます。 そうすることで、このオンプレミスの共有グループに必要なのは、クラウド内の 1 つの Azure ファイル共有のみとなります。

フェーズ 2: Azure ストレージ リソースをデプロイする

この段階では、Azureストレージアカウントとその中のファイル共有をプロビジョニングします。

Azure ファイル共有は、Azure ストレージ アカウントのクラウドにデプロイされることに注意してください。 HDD (標準) ファイル共有の場合、この配置により、ストレージ アカウントは IOPS やスループットなどのパフォーマンス数値のスケール ターゲットになります。 単一のストレージ アカウントに複数のファイル共有を配置すると、これらの共有について IOPS とスループットの共有プールを作成することになります。

原則として、アーカイブ共有がある場合、またはそれらの中での日常のアクティビティが少ないことが予想される場合は、複数の Azure ファイル共有を同じストレージ アカウントにプールすることができます。 ただし、多くのユーザーやアプリケーションで使う非常にアクティブな共有がある場合は、ストレージアカウントごとに1つのファイル共有を展開してください。 これらの制限は FileStorage (SSD) ストレージ アカウントには適用されません。このストレージ アカウントでは、各共有のパフォーマンスが明示的にプロビジョニングされ、保証されます。

ストレージ アカウントをデプロイする際のもう 1 つの考慮事項は冗長性です。 「Azure Files の冗長性」を参照してください。

共有の一覧を作成する場合は、各共有を、それを作成するストレージ アカウントに対応付けてください。

ご利用のリソースの名前も重要です。 例えば、人事部門の複数の共有をAzureストレージアカウントにまとめた場合、そのストレージアカウントに適切な名前を付けます。 同様に、Azureのファイル共有に名前を付ける際は、オンプレミスのファイル共有に使われている名前に似たものを使ってください。

次に、「SMB ファイル共有を作成する」の手順に従って、適切な数の Azure ファイル共有を含む適切な数の Azure ストレージ アカウントをデプロイします。 ほとんどの場合、各ストレージアカウントの地域が同じであることを確認しましょう。

フェーズ 3: 必要な Azure Data Box アプライアンスの数を決定する

このステップは前の段階を終えた後に始めてください。 この時点で、ストレージアカウントやファイル共有を含むAzureストレージリソースを作成しているはずです。 Data Boxの注文時に、Data Boxがデータを移動するストレージアカウントを指定する必要があります。

この段階では、前の段階の移行計画の結果を利用可能なデータボックスオプションの限界にマッピングします。 これらの考慮事項は、どのData Boxオプションを選び、NAS共有をAzureファイル共有に移行させるために何個必要かの計画を立てるのに役立ちます。

必要なデバイスの種類と数を決定する際、次の重要な制限事項を考慮してください。

• どのAzure Data Boxでも最大10個のストレージアカウントにデータを移動できます。
• 各データボックスのオプションにはそれぞれ固有の容量があります。 Data Box のオプションを参照してください。

作成したストレージアカウントの数や各アカウントのシェアについては、移行計画を確認してください。 次に、NAS 上でそれぞれの共有のサイズを確認します。 これらの情報を組み合わせることで、どのアプライアンスがどのストレージアカウントにデータを送信すべきかを判断できます。 2台のData Boxデバイスで同じストレージアカウントにファイルを移動させることはできますが、単一のファイル共有の内容を2台のData Boxアプライアンスに分割しないでください。

Data Box のオプション

標準的な移行では、以下の2つのデータボックスオプションのいずれかまたは組み合わせを選択してください:

• データボックス このオプションが最も一般的な選択肢です。 これは堅牢なData Boxアプライアンスで、NASに似た仕組みです。 使用可能な容量は80 TiBで送られます。 詳細については、 Data Box のドキュメントを参照してください。
• Data Box Heavy このオプションでは、NASのように動作する、容量 1 PiB の車輪付き堅牢型 Data Box アプライアンスを採用しています。 暗号化とファイル システムのオーバーヘッドにより、使用可能な容量は約 20% 少なくなります。 詳細については、 Data Box Heavy のドキュメントを参照してください。

フェーズ 4: 一時的な Windows Server をプロビジョニングする

Azure Data Boxのアプライアンスが届くまでの間に、RoboCopyジョブを実行するために必要なWindowsサーバーを1台以上展開できます。 OSのバージョン要件については、 RoboCopyセクションの重要な注記をご覧ください。

• これらのサーバーを使ってファイルをデータボックスにコピーします。
• これらのサーバーを使って、データボックスが転送中にNASアプライアンスで発生した変更を追いつくことができます。 この方法では、ソース側のダウンタイムが最小限に抑えられます。

RoboCopyの作業速度は主に以下の要因に依存します。

• ソース ストレージとターゲット ストレージの IOPS
• それらの間で使用可能なネットワーク帯域幅
  詳細を確認する: IOPS と帯域幅に関する考慮事項
• 名前空間内のファイルやフォルダーをすばやく処理する機能
  詳細を見つける: 処理速度
• RoboCopy の実行間の変更の数
  詳細を見つける: 不要な作業を避ける

一時的なWindows Serverに提供するRAMやスレッド数を決める際は、参照した詳細を念頭に置いてください。

フェーズ 5: Azure ファイル共有を使用するための準備

時間を節約するために、データボックスの到着を待つ間にこのフェーズを進めてください。 この段階の情報をもとに、サーバーやユーザーがAzureファイル共有をどのように利用するかを決定できます。 最も重要な決定事項は次のとおりです。

• ネットワーク: ネットワークで SMB トラフィックをルーティングできるようにします。
• 認証: Kerberos 認証用に Azure ストレージ アカウントを構成します。 Microsoft Entra Connectとストレージアカウントのドメイン参加により、アプリやユーザーは認証にADのIDを使えます。
• 承認:各Azureファイル共有の共有レベルACLは、ADユーザーやグループが特定の共有にアクセスできるようにし、Azureファイル共有内ではネイティブのNTFS ACLが引き継ぎます。 ファイルとフォルダーの ACL に基づく承認は、オンプレミスの SMB 共有の場合と同様に機能します。
• 事業継続性:Azureファイル共有を既存環境に統合するには、既存の共有アドレスを保持することが多いです。 DFS 名前空間をまだ使用していない場合は、環境内で確立することを検討してください。 ユーザーやスクリプトが使う共有アドレスは変更せずに維持できます。 移行後に DFS 名前空間ターゲットを Azure ファイル共有にリダイレクトすることによって、SMB の名前空間ルーティングサービスとして DFS-N を使用します。

フェーズ6:ファイルをデータボックスにコピーする

データボックスが届いたら、NASアプライアンスへのネットワーク接続が妨げられないように設定してください。 注文したデータボックスの種類のセットアップドキュメントに従ってください。

• Data Box を設定する
• Data Box Disk を設定する
• Data Box Heavy を設定する

データボックスの種類によっては、コピーツールにアクセスできるかもしれません。 現時点では、Azureファイル共有への移行には使わないでください。ファイルを完全にデータボックスにコピーしないからです。 代わりに RoboCopy を使用してください。

データボックスが届くと、注文時に指定した各ストレージアカウントに対して事前プロビジョニング済みのSMBシェアが用意されています。

• ファイルがSSDのAzureファイル共有に入っている場合、SSDの「ファイルストレージ」ストレージアカウントごとにSMB共有が1つあります。
• ファイルの保存先が HDD ストレージ アカウントである場合、HDD の従量課金制ストレージ アカウントごとに 3 つの SMB 共有があります。 移行に関しては、 _AzFile で終わるファイル共有のみが関係します。 すべてのブロックおよびページの BLOB 共有を無視します。

Data BoxがフォルダをAzureファイル共有にマッピングする方法

<storage-account-name>_AzFile デバイス共有では、各第1レベル フォルダーが、ターゲット ストレージ アカウント上の Azure ファイル共有に対応します:

• 1階層のフォルダ名は取り込み時にAzureのファイル共有名になります。 もしその名前の共有がターゲットストレージアカウントにまだ存在しなければ、Data Boxが作成します。 もし存在する場合でも、Data Boxはそのデータを既存の共有にコピーします。

• ファイルを _AzFile 共有のルートに直接コピーしないでください。 すべてのデータは1レベルのフォルダ内に収めなければなりません。

• ソースSMB共有と1対1のマッピングを行うには、各ソース共有に対して1つ目の1レベルフォルダ(希望のAzureファイル共有名を使用)を作成し、それぞれのソース共有を対応するフォルダにコピーします。 例えば次が挙げられます。

  \\<DataBox-IP>\<storage-account-name>_AzFile\Share1
  \\<DataBox-IP>\<storage-account-name>_AzFile\Share2
  \\<DataBox-IP>\<storage-account-name>_AzFile\Share3
  

詳細は 「データボックスに接続」をご覧ください。

Azure Data Box のドキュメントの手順に従ってください。

1. Data Box に接続する
2. Data Box にデータをコピーする
3. RoboCopyのログファイルでエラーを確認し、すべてのファイルが正常にコピーされているか確認してください。
4. Azureへの出発に備えたデータボックスの準備をしてください

リンク先のData BoxのドキュメントにはRoboCopyコマンドが指定されています。 しかし、このコマンドはファイルとフォルダ全体の忠実度を保つには適していません。 このコマンド /MT:32 は、ローカルLANからデータボックスへのコピーであり、遅延がほとんどないため、フェーズ7のWANベースのキャッチアップコピーよりもスレッド数が多いため、ここで適切なスレッド数が適切です。

Robocopy /MT:32 /NP /NFL /NDL /B /MIR /IT /COPY:DATSO /DCOPY:DAT /UNILOG:<FilePathAndName> <SourcePath> <Dest.Path> 

• 個々の RoboCopy フラグの詳細については、後の RoboCopy セクションの表をご覧ください。
• スレッド数 /MT:n を適切にサイズ変更する方法、RoboCopy 速度を最適化する方法、および RoboCopy をデータ センターの良好な近傍にする方法の詳細については、RoboCopy のトラブルシューティング セクションをご覧ください。

フェーズ 7: NAS からのキャッチアップ RoboCopy を実行する

Data Boxがすべてのファイルとフォルダを予定されているAzureファイル共有に移したと報告したら、このフェーズを続けてください。 データボックスのコピー開始以降、NASのデータが変わっている可能性がある場合のみ、追いつきRoboCopyが必要です。 アーカイブの目的で共有を使用する特定のシナリオでは、移行が完了するまで、NAS での共有の変更を停止することができます。 移行中に NAS 共有を読み取り専用に設定することによって、ビジネス要件に対応することもできます。

移行中に共有を読み書きする必要がある場合、そして短いダウンタイムウィンドウしか吸収できない場合、このキャッチアップRoboCopyステップは、ユーザーがAzureファイル共有に直接アクセスするフェイルオーバー前に完了することが重要です。

このステップでは、RoboCopy ジョブを実行して、共有を Data Box にコピーした時点以降に NAS 上で行われた最新の変更にクラウド共有を同期させます。 このキャッチアップ RoboCopy は、NAS 共有で発生したチャーンの量によって、短時間で終了したり、しばらく時間がかかったりすることがあります。

Windows Server ターゲット フォルダーへの最初のローカル コピーを実行します。

1. NAS アプライアンス上で最初の場所を特定します。
2. 一致する Azure ファイル共有を特定します。
3. Azure ファイル共有をローカル ネットワーク ドライブとして一時 Windows Server にマウントします。
4. 説明に従って RoboCopy を使用してコピーを開始します。

Azure ファイル共有のマウント

RoboCopy を使用する前に、Azure ファイル共有に SMB 経由でアクセスできるようにする必要があります。 最も簡単な方法は、ローカル ネットワーク ドライブとして、RoboCopy に使用する予定の Windows Server に共有をマウントすることです。

準備ができたら、「WindowsでAzureファイル共有を使う」というハウツー記事を確認し、NASの追いつきRoboCopyを始めたいAzureのファイル共有をマウントしてください。

RoboCopy

以下のRoboCopyコマンドは、NASストレージからAzure ファイル共有に差分（更新されたファイルとフォルダー）のみをコピーします。

robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName> 

ユーザーのカットオーバー

RoboCopy コマンドを初めて実行するときは、ユーザーとアプリケーションがまだ NAS 上のファイルにアクセスしていて、それを変更する可能性があります。 あるディレクトリが RoboCopy によって処理され、処理が次のディレクトリに移動した後、ソースの場所 (NAS) のユーザーが、現在のこの RoboCopy の実行では処理されなくなったファイルの追加、変更、削除を行う可能性があります。 これは正しい動作です。

最初の実行では、チャーンされたデータの大部分を Azure ファイル共有に移動します。 この最初のコピーには、時間がかかることがあります。 RoboCopy の速度に影響する可能性のある点の詳細については、トラブルシューティング セクションをご覧ください。

最初の実行が完了したら、再度コマンドを実行します。

同じシェアで2回目にRoboCopyを実行すると、前回の実行以降に起きた変更だけを転送すれば済むため、より早く完了します。 同じ共有に対してジョブを繰り返し実行できます。

ダウンタイムを許容できる場合は、NAS ベースの共有へのユーザー アクセスを削除する必要があります。 これは、ユーザーがファイルとフォルダー構造およびコンテンツを変更できないようにするいずれの手順でも行えます。 たとえば、自分の DFS 名前空間を存在しない場所に指定したり、共有のルート ACL を変更します。

最後に 1 回 RoboCopy ラウンドを実行します。 見落としがちな変更点も拾います。 この最後の手順にかかる時間は、RoboCopy のスキャンの速度に依存します。 前回の実行にかかった時間を測定することで、(ダウンタイムに相当する) 時間を見積もることができます。

Windows Server フォルダーに共有を作成し、必要に応じて、その共有を指すように DFS-N のデプロイを調整します。 NAS SMB 共有と同じ共有レベルのアクセス許可を設定してください。 エンタープライズ クラスのドメイン参加 NAS を使用していた場合、ユーザーの SID は Active Directory に存在するユーザーと自動的に一致し、RoboCopy によってファイルとメタデータが完全に忠実にコピーされます。 NAS でローカル ユーザーを使用していた場合は、これらのユーザーを Windows Server のローカル ユーザーとして作成し直し、RoboCopy によって Windows Server に移動された既存の SID を、新しい Windows Server ローカル ユーザーの SID にマップする必要があります。

共有または複数の共有を共通のルートまたはボリュームに移行する作業が完了しました。

これらの複数のコピーを並行して実行することができます。 一度に1つのAzureファイル共有の範囲を処理します。

トラブルシューティング

RoboCopyの速度と成功率は、いくつかの要因によって異なります。

• ソース ストレージとターゲット ストレージの IOPS
• ソースとターゲットの間で使用可能なネットワーク帯域幅
• 名前空間内のファイルとフォルダーを迅速に処理する機能
• RoboCopy 実行間の変更の数
• コピーする必要があるファイルのサイズと数

IOPS と帯域幅に関する考慮事項

このカテゴリでは、ソース ストレージ、ターゲット ストレージ、およびそれらを接続するネットワークの能力を考慮する必要があります。 達成可能な最大スループットは、これら 3 つのコンポーネントのうち、最も低速なものによって決まります。 最大能力に応じた最適な転送速度をサポートするようにネットワーク インフラストラクチャが構成されていることを確認してください。

可能な限り高速にコピーすることは、移行によって使用可能なリソースを独占するリスクがある場合には望ましくない可能性があります。

• ご使用の環境において移行を実行する最適なタイミングを考慮します (日中、時間外、または週末)。
• また、RoboCopy の速度を調整するための Windows Server のネットワーク QoS も考慮してください。
• 移行ツールのための不要な作業を行わないようにします。

RoboCopy では、/IPG:n スイッチを指定することでパケット間の遅延を挿入できます。ここで n は、RoboCopy パケット間の間隔をミリ秒単位で測定します。 このスイッチを使用することで、I/O制約のあるデバイスや混雑したネットワークリンクの両方でのリソースの独占を防ぐことができます。

/IPG:n は、ネットワーク帯域幅を特定の Mbps に正確に調整するためには使用できません。 代わりに Windows Server のネットワーク QoS を使用してください。 RoboCopy では、すべてのネットワーク ニーズに関して SMB プロトコルに完全に依存します。 SMB を使用する理由は、RoboCopy がネットワーク スループット自体に影響を与えることができないためですが、使用速度が低下する可能性はあります。

同様の考えが、NAS で観察される IOPS にも当てはまります。 NAS ボリュームのクラスター サイズ、パケット サイズ、およびその他のさまざまな要因が、観察される IOPS に影響します。 多くの場合、パケット間の遅延を導入することが、NAS の負荷を制御する最も簡単な方法です。 約20ミリ秒(n=20)からその倍数まで、複数の値をテストします。 遅延を導入した後、他のアプリが期待通りに動作しているか評価できます。 この最適化戦略は、環境内で最適なRoboCopy速度を見つけるのに役立ちます。

処理速度

RoboCopyは指定した名前空間を経由し、各ファイルやフォルダをコピーのために評価します。 すべてのファイルを初期コピーおよび追いつきコピーの際に評価します。 例えば、同じソースとターゲットのストレージ場所に対して繰り返し RoboCopy /MIR を実行する場合などです。 これらの繰り返し実行はユーザーやアプリのダウンタイムを最小限に抑え、移行したファイルの成功率を向上させます。

帯域幅は移行において最も制約となる要素と考えられがちですが、それは事実です。 ただし、名前空間を列挙する機能により、小さなファイルを含む大規模な名前空間の場合は、コピーの合計時間に与える影響がはるかに大きくなる可能性があります。 小さなファイルに1 TiBコピーするよりも、より少ないが大きなファイルの1 TiBをコピーするよりもかなり時間がかかることを考えてみてください。ただし、他の変数はすべて同じであると仮定します。 そのため、多数の小さなファイルを移行する場合は、転送に時間がかかる可能性があります。 この違いが予想されます。

この違いの原因は、名前空間内を通過するために必要な処理能力です。 RoboCopy では、/MT:n パラメーターを使用したマルチスレッド コピーがサポートされます。ここで n は、使用するスレッドの数を表します。 そのため、RoboCopy 専用のマシンをプロビジョニングする場合は、プロセッサ コアの数と、それらが提供するスレッド数との関係を考慮します。 最も一般的なのは、コアあたり 2 つのスレッドです。 マシンのコア数とスレッド数は、指定する必要のあるマルチスレッド値 /MT:n を決定するための重要なデータ ポイントです。 また、特定のマシンで並列実行する予定の RoboCopy ジョブの数も考慮します。

スレッド数が少ないスレッドよりも、1 TiBの小さなファイルの例をかなり速くコピーします。 同時に、1 TiB分のより大きなファイルに対する追加のリソース投入は、それに見合う効果をもたらさない可能性があります。 スレッド数が多い場合は、ネットワーク上で同時に多くの大きなファイルをコピーしようとします。 この追加のネットワーク アクティビティによって、スループットまたはストレージ IOPS による制約を受ける可能性が高くなります。

空のターゲットへの最初の RoboCopy または多数の変更されたファイルによる差分コピーを実行する際には、ネットワーク スループットによって制約される可能性があります。 最初の実行では、スレッド数を多くしてください。 スレッド数が多いと、コンピューター上で現在使用可能なスレッドを超えても、使用可能なネットワーク帯域幅が飽和状態になります。 後続の/MIR の実行は、アイテムを処理することによって徐々に影響を受けます。 差分実行の変更が少ないほど、ネットワーク経由でのデータ転送が減少します。 ネットワークリンクを介してデータを移動する能力より、名前空間項目を処理する能力への依存度が高くなったため、あなたの速度はその処理能力に依存しています。 後続の実行では、スレッド数の値をプロセッサのコア数およびコアあたりのスレッド数と一致させます。 実稼働サーバーに存在する可能性のある他のタスク用にコアを予約する必要があるかどうかを検討してください。

不要な作業の回避

名前空間の大規模な変更は避けてください。 ディレクトリ間でのファイルの移動、プロパティの大規模な変更、アクセス許可 (NTFS ACL) の変更などです。 特に ACL の変更は、フォルダー階層の下位にあるファイルに対して変更が連鎖的に影響することが多いため、大きな影響を及ぼす可能性があります。 次のような影響が考えられます。

• ACL の変更によって影響を受けた各ファイルおよびフォルダーを更新する必要があるため、RoboCopy ジョブの実行時間が長くなる
• 以前に移動したデータを再利用する場合は、再コピーが必要になるかもしれません。 例えば、ファイルのコピー後にフォルダ構造が変わると、より多くのデータをコピーする必要があります。 RoboCopy ジョブでは、名前空間の変更を "再生" できません。 次のジョブで、古いフォルダー構造へ以前に転送されたファイルを削除し、新しいフォルダー構造でファイルを再度アップロードする必要があります。

もう 1 つの重要な側面は、RoboCopy ツールを効果的に使用することです。 推奨されているRoboCopyスクリプトを使うことで、エラー用のログファイルを作成・保存できます。 コピー エラーが発生する可能性があり、これは正常です。 多くの場合、これらのエラーによって、RoboCopy などのコピー ツールを複数ラウンド実行することが必要になります。 例えば、NASからData BoxやサーバーからAzureファイル共有への最初の実行と、/MIRスイッチでコピーされなかったファイルをキャッチして再試行するために1回以上の追加実行を行うことなどです。

特定の名前空間のスコープに対して複数回のRoboCopyを実行できる準備をしてください。 連続した実行はコピーする量が少ないためより早く完了しますが、名前空間の処理速度によって制約が増します。 複数ラウンドを実行する場合は、RoboCopy の特定の実行で非合理的にすべてをコピーしようとしないようにすることで、各ラウンドを高速化できます。 これらの RoboCopy スイッチにより、大きな違いがもたらされる可能性があります。

• /R:n n = 失敗したファイルのコピーを再試行する頻度
• /W:n n = 再試行を待機する秒数

/R:5 /W:5 が合理的な設定ですが、自由に調整できます。 この例では、失敗したファイルは 5 回再試行され、再試行間の待機時間は 5 秒です。 それでもファイルのコピーに失敗した場合は、次の RoboCopy ジョブで再試行されます。 多くの場合、使用中またはタイムアウトの問題のために失敗したファイルは、最終的にこの方法で正常にコピーされる可能性があります。

こちらも参照ください

• 移行の概要
• 直接アクセスに関するネットワークの考慮事項
• Azure ファイル共有スナップショット