RoboCopy を使用して Azure ファイル共有に移行する

[アーティクル]
10/23/2023

この移行に関する記事では、RoboCopy を使用してファイルを SMB Azure ファイル共有に移動または移行する方法について説明します。 RoboCopy は、移行に適した機能セットを備えた、信頼できるよく知られているファイルコピーユーティリティです。これには SMB プロトコルが使用されます。そのため、SMB をサポートする任意のソースとターゲットの組み合わせに幅広く適用できます。

データソース: SMB プロトコルをサポートする任意のソース。ネットワーク接続ストレージ (NAS)、Windows または Linux サーバー、別の Azure ファイル共有、その他多数
移行経路: ソースストレージ ⇒ Windows マシン (RoboCopy 使用) ⇒ Azure ファイル共有
オンプレミスでファイルをキャッシュしない: 最終目標はクラウドで Azure ファイル共有を直接使用することであるため、Azure File Sync を使用する予定はありません。

ソースとデプロイのさまざまな組み合わせに応じて、異なる多数の移行経路があります。移行ガイドの表を参照して、ご自身のニーズに最適な移行を見つけてください。

適用対象

ファイル共有の種類	SMB	NFS
Standard ファイル共有 (GPv2)、LRS/ZRS
Standard ファイル共有 (GPv2)、GRS/GZRS
Premium ファイル共有 (FileStorage)、LRS/ZRS

AzCopy と RoboCopy

AzCopy と RoboCopy の 2 つは、基本的に異なるファイルコピーツールです。 RoboCopy には、任意のバージョンの SMB プロトコルが使用されます。 AzCopy は、ターゲットが Azure Storage 内にある場合に限ってデータの移動に使用できる "クラウド内で生まれた" ツールです。 AzCopy は REST プロトコルに依存します。

RoboCopy は、信頼できる Windows ベースのコピーツールとして、完全な忠実性を維持してファイルをコピーすることについては優れた優位性があります。 RoboCopy を使用すると、豊富な機能セットがあってファイルとフォルダーを完全な忠実性を維持してコピーできるため、多くの移行シナリオがサポートされます。可能な最大限の忠実性を維持してファイルをコピーすることの重要性について詳細は、移行の概要に関する記事にあるファイルの忠実性に関するセクションを参照してください。

一方、AzCopy は最近になって、一定の忠実性を維持したファイルコピーをサポートするように拡張され、移行ツールとして検討対象になるために必要な最初の機能が追加されたばかりです。ただし、まだ差があり、AzCopy フラグと RoboCopy フラグを比較するときに機能について誤解が生じやすいと言えます。

たとえば、RoboCopy /MIR を使用すると、ソースがターゲットにミラー化されます。つまり、追加、変更、削除されたファイルが考慮されます。 AzCopy -sync の使用との重要な違いは、ソース上で削除されたファイルはターゲット上で削除されないという点です。これにより、不完全な差分コピー機能セットが作成されます。 AzCopy は常に進化しています。 Azure ファイル共有をターゲットとする移行シナリオの場合、現時点では、AzCopy は推奨されません。

移行の目標

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

移行の概要

移行プロセスは、いくつかのフェーズで構成されます。最初に、Azure ストレージアカウントとファイル共有をデプロイする必要があります。次に、ネットワークを構成したり、DFS 名前空間のデプロイ (DFS-N) を検討したり、既存のものを更新したりします。実際にデータをコピーするときになったら、ダウンタイムを最小限に抑えるために、差分 RoboCopy を繰り返し実行することを検討する必要があります。最後に、新しく作成された Azure ファイル共有にユーザーをカットオーバーします。以下のセクションでは、移行プロセスの各フェーズについて詳しく説明します。

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

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

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

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

Note

1 つの Azure リージョンにつき、1 サブスクリプションあたりのストレージアカウント数は 250 に制限されています。クォータの引き上げにより、リージョンごとに最大 500 個のストレージアカウントを作成できます。詳細については、「Azure Storage アカウントのクォータを増やす」を参照してください。

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

既定では、標準の Azure ファイル共有は 5 TiB の上限で作成されます。さらに容量が必要な場合は、大きなファイル共有 (最大 100 TiB) を作成できます。しかし、その共有で使用できるのは、ローカル冗長ストレージまたはゾーン冗長ストレージ冗長オプションのみとなります。 100 TiB のファイル共有を使用する場合は、事前にご自分のストレージ冗長のニーズを検討してください。

共有のリストを作成してある場合は、各共有を、それが作成されるストレージアカウントにマップする必要があります。

ご利用のリソースの名前も重要です。たとえば、人事部の複数の共有を Azure ストレージアカウントにグループ化する場合は、そのストレージアカウントに適切な名前を指定する必要があります。同様に、使用する Azure ファイル共有に名前を付けるときは、オンプレミスの対応するものに使用したのと同じような名前を使用する必要があります。

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

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

このフェーズの情報を使用すると、Azure のサーバーとユーザーが Azure ファイル共有を利用できるようにする方法を決めることができます。最も重要な決定事項は次のとおりです。

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

このビデオは、簡単な 5 つのステップでインフォメーションワーカーやアプリに直接 Azure ファイル共有を安全に公開する方法についてのガイドとデモです。
このビデオでは、次のトピックに関する専用のドキュメントが参照されています。 Azure Active Directory は Microsoft Entra ID になりましたので注意してください。詳細については、「Azure AD の新しい名前」を参照してください。

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

重要

ストレージアカウントのアクセスキーを使って Azure ファイル共有をマウントしてください。ドメイン ID は使わないでください。 Azure ファイル共有をローカル Windows Server に正常にマウントする前に、「フェーズ 2: Azure ファイル共有の使用を準備する」を完了しておく必要があります。

準備ができたら、「Windows で Azure ファイル共有を使用する」を確認してください。それから、RoboCopy を開始する Azure ファイル共有をマウントします。

フェーズ 3: RoboCopy

次の RoboCopy コマンドを実行すると、ソースストレージから 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>

Switch	説明
`/MT:n`	Robocopy をマルチスレッドを実行できるようにします。 `n` の既定値は 8 です。スレッドの最大数は 128 です。スレッド数が多いと使用可能な帯域幅を飽和させるのに役立ちますが、スレッド数が多ければ必ず移行が速くなるというわけではありません。 Azure Files を使ったテストでは、8 から 20 の間で、最初のコピー実行のパフォーマンスのバランスが取れていることが示されています。後続 `/MIR` の実行は、使用可能なコンピューティングと使用可能なネットワーク帯域幅の影響を徐々に受けます。後続の実行では、スレッド数の値をプロセッサのコア数およびコアあたりのスレッド数とより厳密に一致させます。実稼働サーバーに存在する可能性のある他のタスク用にコアを予約する必要があるかどうかを検討してください。 Azure Files を使ったテストでは、最大 64 スレッドで良好なパフォーマンスが得られますが、プロセッサがそれらを同時に維持できる場合のみです。
`/R:n`	最初の試行でコピーに失敗したファイルの最大再試行回数です。 Robocopy では、実行中にファイルが完全にコピーに失敗するまで `n` 回試行します。実行のパフォーマンスを最適化することができます。過去にタイムアウトの問題で失敗したと思われる場合は、2 または 3 の値を選んでください。これは、WAN リンク上でより一般的である可能性があります。ファイルが使用中であったためにコピーに失敗したと思われる場合は、[再試行しない] または 1 の値を選びます。数秒後に再試行しても、ファイルの使用中の状態が変更されるのに十分な時間がない場合があります。ファイルを開いているユーザーまたはアプリには、さらに時間がかかることがあります。このような場合、ファイルがコピーされていないことを受け入れ、その後に予定されている Robocopy の実行のいずれかで試行すれば、最終的にファイルを正常にコピーするのに成功する可能性があります。これにより、再試行のタイムアウトを過ぎてもファイルが開いているために、最終的にコピー失敗の大部分を占めることになる多数の再試行で長引かせることなく、現在の実行をより短時間で完了することができます。
`/W:n`	前の試行時に正常にコピーされなかったファイルのコピーを試行する前に、RoboCopy が待機する時間を指定します。 `n` は再試行の間の待機時間 (秒数) です。 `/W:n` は、多くの場合、`/R:n` と共に使用されます。
`/B`	バックアップアプリケーションが使用するのと同じモードで Robocopy を実行します。このスイッチを使用すると、現在のユーザーがアクセス許可を持っていないファイルを、Robocopy によって移動できます。バックアップのスイッチは、管理者特権のコンソールまたは PowerShell ウィンドウで Robocopy コマンドを実行する場合によって異なります。 Azure Files に Robocopy を使用する場合は、ストレージアカウントのアクセスキーとドメイン ID のどちらを使用して Azure ファイル共有をマウントするかを確認します。そうしないと、エラーメッセージが直感的でなくなり、問題解決につながらないことがあります。
`/MIR`	(ソースをターゲットにミラーリング。) RoboCopy でソースとターゲット間の差分のみをコピーします。空のサブディレクトリがコピーされます。変更された、またはターゲットに存在しない項目 (ファイルまたはフォルダー) がコピーされます。ターゲットに存在する一方でソースには存在しない項目は、ターゲットから消去 (削除) されます。このスイッチを使用する場合は、ソースとターゲットのフォルダー構造を正確に一致させます。 "一致" とは、正しいソースおよびフォルダーレベルから、コピー先の一致するフォルダーレベルにコピーすることを意味します。その場合にのみ、"キャッチアップ" コピーを正常に実行することができます。ソースとターゲットが一致しない場合に `/MIR` を使用すると、大規模な削除と再コピーが行われます。
`/IT`	特定のミラーシナリオで、忠実性が維持されることを保証します。たとえば、Robocopy を 2 回実行する間に、ファイルで ACL の変更と属性の更新があった場合、非表示とマークされます。 `/IT` を使用しない場合、ACL の変更が Robocopy で見逃されて、ターゲットの場所に転送されない可能性があります。
`/COPY:[copyflags]`	ファイルコピーの忠実性。既定値:`/COPY:DAT`。コピーフラグ: `D` = データ、`A` = 属性 `T` = タイムスタンプ、`S` = セキュリティ = NTFS ACL `O` = 所有者情報、`U`= `D`監査情報。監査情報を Azure ファイル共有に格納することはできません。
`/DCOPY:[copyflags]`	ディレクトリのコピーの忠実性。既定値:`/DCOPY:DA`。コピーフラグ: `D` = データ `A` = 属性、`T` = タイムスタンプ。
`/NP`	各ファイルとフォルダーのコピーの進行状況を表示しないよう指定します。進行状況を表示すると、コピーのパフォーマンスが大幅に低下します。
`/NFL`	ファイル名をログに記録しないことを指定します。コピーのパフォーマンスを向上させます。
`/NDL`	ディレクトリ名をログに記録しないことを指定します。コピーのパフォーマンスを向上させます。
`/XD`	除外するディレクトリを指定します。ボリュームのルートで Robocopy を実行する場合、隠しフォルダー `System Volume Information` を除外することを検討してください。設計どおりに使用した場合、そこにあるすべての情報は、この正確なシステム上の正確なボリュームに固有であり、オンデマンドで再構築することができます。この情報をコピーしても、クラウドや、データを別の Windows ボリュームにコピーバックするときには役に立ちません。この内容を放置しておくことは、データ損失と見なさないようにする必要があります。
`/UNILOG:<file name>`	状態を Unicode 形式でログファイルに書き込みます。 (既存のログを上書きします)。
`/L`	テスト実行の場合のみファイルは一覧表示されるだけです。コピーも削除もされず、タイムスタンプも付きません。コンソール出力には `/TEE` とよく使用されます。テスト結果を適切に文書化するには、サンプルスクリプトのフラグ (`/NP`、`/NFL`、`/NDL` など) の削除が必要になる場合があります。
`/Z`	慎重に使用する再起動モードでファイルをコピーします。このスイッチは、ネットワーク環境が不安定な場合にのみ、使用することをお勧めします。追加のログ記録が原因で、コピーのパフォーマンスが大幅に低下します。
`/ZB`	慎重に使用する再起動モードを使用します。アクセスが拒否された場合、このオプションではバックアップモードが使用されます。このオプションでは、チェックポイント処理が原因で、コピーのパフォーマンスが大幅に低下します。

重要

Windows Server 2022 の使用をお勧めします。 Windows Server 2019 を使う場合、最新のパッチレベルまたは少なくとも OS 更新プログラム KB5005103 がインストールされていることを確認してください。特定の RoboCopy シナリオに対する重要な修正プログラムが含まれています。

ヒント

RoboCopy が運用環境に影響を与えたり、多くのエラーを報告したり、予想どおりの速度で進行していない場合、トラブルシューティングのセクションを確認してください。

フェーズ 4: ユーザーのカットオーバー

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

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

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

同じ同期に対して RoboCopy を 2 回目に実行したときは、前回の実行以降に発生した変更のみを転送すればよいため、処理は短時間で完了します。同じ共有に対してジョブを繰り返し実行できます。

許容可能なダウンタイムの長さを検討したら、ソースの共有にユーザーがアクセスできないようにする必要があります。これは、ユーザーがファイルとフォルダー構造およびコンテンツを変更できないようにするいずれの手順でも行えます。たとえば、DFS-Namespace を存在しない場所に指定したり、各共有の ACL を変更したりすることなどです。

最後に 1 回 RoboCopy ラウンドを実行します。それにより、見過ごされた可能性があるすべての変更が取得されます。この最後の手順にかかる時間は、RoboCopy のスキャンの速度に依存します。前回の実行にかかった時間を測定することで、(ダウンタイムに相当する) 時間を見積もることができます。

フェーズ 2 では、ユーザーが自分の ID で共有にアクセスするように構成し、また、ユーザーが新しい Azure ファイル共有 (DFS-N) への確立されたパスを使用するための戦略を確立しました。

異なるソースとターゲット共有の間でこれらのコピーのいくつかを並行して実行することができます。これを行う場合は、システムに過剰に負荷がかからないようなネットワークスループットおよびコアとスレッドの数の比率を維持してください。

トラブルシューティングと最適化

指定された RoboCopy 実行の速度と成功率は、複数の要因によって決まります。

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

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

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

注意事項

多くの場合、可能な限り高速にコピーすることが望ましいですが、他のビジネスクリティカルなタスクに使用されることの多いローカルネットワークと NAS アプライアンスの使用状況を考慮してください。

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

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

RoboCopy では、/IPG:n スイッチを指定することでパケット間の遅延を挿入できます。ここで n は、RoboCopy パケット間の間隔をミリ秒単位で測定します。このスイッチを使用すると、IO が制限されたデバイスと過密したネットワークリンクの両方でリソースの独占を回避できます。

/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 の実行は、アイテムを処理することによって徐々に影響を受けます。差分実行の変更が少ないほど、ネットワーク経由でのデータ転送が減少します。ネットワークリンク上で移動する機能よりも、名前空間項目を処理する機能によって速度が向上するようになりました。後続の実行では、スレッド数の値をプロセッサのコア数およびコアあたりのスレッド数と一致させます。実稼働サーバーに存在する可能性のある他のタスク用にコアを予約する必要があるかどうかを検討してください。

ヒント

経験則: 最初の RoboCopy 実行ではより高遅延のネットワークのデータを大量に移動するため、スレッドカウントをオーバープロビジョニングすることでメリットが得られます (/MT:n)。その後の実行ではコピーの差異が少なくなり、ネットワークスループット制約をコンピューティング制約に移行する可能性が高くなります。こうした状況では多くの場合、RoboCopy のスレッドカウントをマシンで実際に利用できるスレッドに合わせることが推奨されます。そのシナリオでのオーバープロビジョニングはプロセッサのコンテキスト移動を増やす場合があり、おそらくコピーが遅くなるでしょう。

不要な作業の回避

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

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

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

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

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

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

ストレージトランザクション料金の見積もり

Azure Files への移行を開始すると、RoboCopy によってファイルとフォルダーが Azure にコピーされます。 Azure Files の課金モデルによっては、トランザクション料金が適用される場合があります。「課金について」をご覧ください。

標準の Azure ファイル共有に従量課金制の課金モデルを使用している場合、移行によって生成されるトランザクションの数を見積もるのは難しい場合があります。

ソースの使用されたストレージ容量に基づいてトランザクションの数を見積もることはできません。トランザクションの数は、サイズではなく、移行される名前空間項目 (ファイルとフォルダー) とそのプロパティの数に応じてスケーリングされます。たとえば、小さなファイルの 1 GiB を移行するには、より大きなファイルの 1 GiB を移行するよりも多くのトランザクションが必要です。
ダウンタイムを最小限に抑えるために、ソースからターゲットへのコピー操作を複数回実行することが必要になる場合があります。すべてのソースとターゲットの項目は各コピー操作中に処理されますが、後続の実行はより速く完了します。最初の操作の後、コピーの実行間で導入された差異のみがネットワーク経由で転送されます。転送されるデータは少なくなりますが、必要なトランザクションの数は変わらない可能性があることを理解することが重要です。
同じファイルを 2 回コピーしても、トランザクションの数が同じにならない可能性があります。前回のコピー実行で移行された項目を処理すると、読み取りトランザクションがわずかしか発生しない場合があります。これに対し、コピーの実行間でメタデータまたはコンテンツを変更する場合、ターゲットを更新するために、より多くのトランザクションが必要になる場合があります。名前空間内の各ファイルには固有の要件があり、その結果、トランザクションの数が異なる場合があります。

発生するトランザクションの数をより正確に理解するために、独自のデータに対していくつかの初期テストを実行することをお勧めします。これにより、ファイル移行によって生成される可能性があるトランザクションの合計数をより適切に把握できます。

次のステップ

以下の記事は、詳細オプションやベストプラクティスの理解に役立ちます。