Data Box を使用して Azure File Sync によってネットワーク接続ストレージ (NAS) からハイブリッド クラウド デプロイに移行する

  • [アーティクル]

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

  • データ ソース: ネットワーク接続ストレージ (NAS)
  • 移行ルート: NAS ⇒ Data Box ⇒ Azure ファイル共有 ⇒ Windows Server と同期
  • オンプレミスでのファイルのキャッシュ: はい、最終的な目標は Azure File Sync のデプロイです

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

Azure File Sync は、ダイレクト接続ストレージ (DAS) の場所で機能します。 ネットワーク接続ストレージ (NAS) の場所への同期はサポートされていません。 そのため、ファイルを移行する必要があります。 この記事では、その移行の計画と実装について説明します。

適用対象

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

移行の目標

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

移行の概要

移行プロセスは、いくつかのフェーズで構成されます。 次のことを行う必要があります。

  • Azure ストレージ アカウントとファイル共有をデプロイします。
  • Windows Server を実行しているオンプレミス コンピューターをデプロイします。
  • Azure File Sync を構成します。
  • Robocopy を使用してファイルを移行します。
  • カットオーバーを実行します。

以下のセクションでは、移行プロセスの各フェーズについて詳しく説明します。

ヒント

この記事に戻った場合は、画面の右側にあるナビゲーションを使用して、中断した移行フェーズにジャンプします。

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

この手順では、必要な Azure ファイル共有の数を決定します。 1 つの Windows Server インスタンス (またはクラスター) では、最大 30 個の Azure ファイル共有を同期できます。

現在、SMB 共有としてユーザーとアプリに対してローカルに共有しているボリュームには、さらに多くのフォルダーが存在する場合があります。 このシナリオを理解する最も簡単な方法は、1:1 で Azure ファイル共有にマップするオンプレミスの共有を想像することです。 1 つの Windows Server インスタンスの共有数が 30 以下と十分に少ない場合は、1 対 1 のマッピングをお勧めします。

共有の数が 30 を超える場合、通常オンプレミスの共有を 1 対 1 で Azure ファイル共有にマッピングする必要はありません。 次のオプションを検討してください。

共有のグループ化

たとえば、人事 (HR) 部門に 15 個の共有がある場合、すべての HR データを 1 つの Azure ファイル共有に格納することを検討できます。 1 つの Azure ファイル共有にオンプレミスの共有を複数格納しても、ローカルの Windows Server インスタンスに通常の 15 個の SMB 共有を作成できます。 これは、単にこれらの 15 個の共有のルート フォルダーを共通フォルダーの下のサブフォルダーとして整理することを意味します。 その後、この共通フォルダーを Azure ファイル共有に同期します。 そうすることで、このオンプレミスの共有グループに必要なのは、クラウド内の 1 つの Azure ファイル共有のみとなります。

ボリュームの同期

Azure File Sync では、ボリュームのルートを Azure ファイル共有に同期することをサポートしています。 ボリューム ルートを同期した場合、すべてのサブフォルダーとファイルは同じ Azure ファイル共有に格納されます。

ボリュームのルートを同期することが常に最適なオプションであるとは限りません。 複数の場所に同期することには利点があります。 たとえば、そうすることで、同期スコープあたりの項目数を少なく抑えることができます。 Azure ファイル共有と Azure File Sync は、共有ごとに 1 億個の項目 (ファイルとフォルダ) を保持できるようテストされています。 ただし、ベスト プラクティスとしては、1 つの共有に保持する項目数は、2000 万から 3000 万個未満にすることをお勧めします。 Azure File Sync に含める項目数を少数に設定することは、ファイルの同期にとって有益というだけではありません。項目の数が少ないと、次のようなシナリオでも利点があります。

  • クラウド コンテンツの初期スキャンの完了までの時間が短くなり、その結果、Azure File Sync 対応のサーバーに名前空間が表示されるまでの待機時間が短縮されます。
  • Azure ファイル共有スナップショットからのクラウド側の復元が高速になります。
  • オンプレミスサーバーのディザスター リカバリーが大幅にスピードアップされます。
  • Azure ファイル共有 (同期以外) で直接行われた変更が、より高速に検出、同期されます。

ヒント

ファイルとフォルダーの数が不明な場合は、JAM Software GmbH の TreeSize ツールをぜひご利用ください。

デプロイ マップへの構造化アプローチ

後の手順でクラウド ストレージをデプロイする前に、オンプレミス フォルダーと Azure ファイル共有の間にマップを作成することが重要です。 このマッピングを行うと、プロビジョニングする Azure File Sync の "同期グループ" リソースの数と名称が通知されます。 同期グループは、Azure ファイル共有とサーバー上のフォルダーを連携させ、同期接続を確立します。

必要な Azure ファイル共有の数を決めるには、次の制限事項とベストプラクティスをレビューしてください。 そのことが、マップの最適化に役立ちます。

  • Azure File Sync エージェントがインストールされているサーバーは、最大 30 個の Azure ファイル共有と同期できます。

  • Azure ファイル共有は、ストレージ アカウント内にデプロイされます。 この配置により、このストレージ アカウントが、IOPS やスループットなどのパフォーマンス数のスケール ターゲットになります。

    Azure ファイル共有をデプロイする際には、ストレージ アカウントの IOPS 制限に注意してください。 理想的には、ファイル共有をストレージ アカウントに 1:1 でマップする必要があります。 ただし、組織と Azure の両方からのさまざまな制限と制約により、これが常に可能とは限りません。 1 つのストレージ アカウントに 1 つのファイル共有のみをデプロイすることができない場合は、使用頻度が高い共有と低い共有を考慮し、最もアクティブなファイル共有が同じストレージ アカウントに一緒にデプロイされないようにしてください。

    Azure ファイル共有をネイティブで使用する Azure にアプリをリフトする場合は、Azure ファイル共有のパフォーマンスをさらに上げる必要があります。 将来的にでもこのように使用することが考えられる場合は、1 つの標準の Azure ファイル共有を独自のストレージ アカウントに作成するのが最善です。

  • 1 つの Azure リージョンにつき、1 サブスクリプションあたりのストレージ アカウント数は 250 に制限されています。

ヒント

この情報を考慮して、ボリューム上の複数のトップレベル フォルダーを共通の新しいルート ディレクトリにグループ化することがしばしば必要になります。 次に、この新しいルート ディレクトリと、その中にグループ化したすべてのフォルダーを、1 つの Azure ファイル共有に同期します。 この手法を使用すると、サーバーあたり 30 個の Azure ファイル共有同期の制限内に抑えることができます。

共通のルートの下でのこのグループ化は、データへのアクセスにはいっさい影響しません。 ACL はそのまま維持されます。 今ここで共通のルートに変更したローカル サーバー フォルダー上に必要共有パス (SMB 共有や NFS 共有など) がある場合に限り、その調整が必要となります。 それ以外の変更はありません。

重要

Azure File Sync の最も重要なスケール ベクターは、同期が必要な項目 (ファイルとフォルダー) の数です。 詳細については、「Azure File Sync のスケール ターゲット」を確認してください。

ここでのベストプラクティスは、同期スコープあたりの項目数を少なくしておくことです。 これは、フォルダーを Azure ファイル共有にマッピングする際に考慮する必要がある重要な要素です。 Azure File Sync は、共有ごとに 1 億個の項目 (ファイルとフォルダー) を使用して検証済みです。 ただし、多くの場合、1 つの共有に保持する項目数は、2000 万から 3000 万個未満にすることをお勧めします。 これらの数値を超え始めた場合は、名前空間を複数の共有に分割します。 これらの数値をほぼ下回っている場合、複数のオンプレミスの共有を同じ Azure ファイル共有にグループ化することを続行できます。 この方法により、拡大する余地が得られます。

状況によっては、一連のフォルダーが同じ Azure ファイル共有に論理的に同期される可能性があります (前述の新しい共通のルート フォルダーのアプローチを使用します)。 ただし、1 つの Azure ファイル共有ではなく 2 つに同期されるように、フォルダーを再グループ化することをお勧めします。 このアプローチを使用すると、ファイル共有あたりのファイルとフォルダーの数をサーバー間に分散させることができます。 オンプレミスの共有を分割し、より多くのオンプレミス サーバー間で同期させることもできます。これにより、追加のサーバーごとに 30 を超える Azure ファイル共有と同期することができます。

ファイル同期の一般的なシナリオと考慮事項

# 同期シナリオ サポートされています 考慮事項 (または制限事項) 解決策 (または対処法)
1 複数のディスク/ボリュームと複数の共有があるファイル サーバーと、同じターゲット Azure ファイル共有 (統合) いいえ ターゲットの Azure ファイル共有 (クラウド エンドポイント) は、1 つの同期グループとの同期のみをサポートします。

同期グループは、登録済みサーバーごとに 1 つのサーバー エンドポイントのみをサポートします。		 1) 最初に、1 つのディスク (そのルート ボリューム) を、ターゲットの Azure ファイル共有と同期させます。 最大のディスク/ボリュームから始めると、オンプレミスのストレージ要件に対応できます。 クラウドの階層化を構成して、すべてのデータをクラウドに階層化します。これにより、ファイル サーバーのディスク領域を解放します。 他のボリューム/共有から、同期中の現在のボリュームにデータを移動します。 すべてのデータがクラウドに階層化/移行されるまで、手順を 1 つずつ続行します。
2) 一度に 1 つのルート ボリューム (ディスク) をターゲットにします。 クラウドの階層化を使用して、すべてのデータをターゲットの Azure ファイル共有に階層化します。 同期グループからサーバー エンドポイントを削除し、次のルート ボリューム/ディスクを含むエンドポイントを再作成し、同期させます。このプロセスを繰り返します。 注: エージェントの再インストールが必要になる場合があります。
3) 複数のターゲット Azure ファイル共有を使用することをお勧めします (パフォーマンス要件に基づいて同じまたは異なるストレージ アカウント)
2 1 つのボリュームと複数の共有があるファイル サーバーと、同じターゲット Azure ファイル共有 (統合) はい 登録済みサーバーごとの複数のサーバー エンドポイントを、同じターゲット Azure ファイル共有と同期させることはできません (上記と同じ) 複数の共有または最上位フォルダーを保持しているボリュームのルートを同期させます。 詳しくは、共有のグループ化の概念に関するページと「ボリュームの同期」を参照してください。
3 複数の共有、ボリューム、またはこれらの両方があるファイル サーバーと、1 つのストレージ アカウントの複数の Azure ファイル共有 (1 対 1 の共有マッピング) はい 1 つの Windows Server インスタンス (またはクラスター) では、最大 30 個の Azure ファイル共有を同期できます。

ストレージ アカウントは、パフォーマンスのためのスケール ターゲットです。 IOPS とスループットは、ファイル共有間で共有されます。

同期グループあたりのアイテム (ファイルとフォルダー) の数は、1 つの共有あたり 1 億個以内にします。 理想的には、1 つの共有あたり 2 千万または 3 千万個未満にするのが最適です。		 1) 複数の同期グループを使用します (同期グループの数 = 同期させる先の Azure ファイル共有の数)。
2) このシナリオでは、一度に 30 個の共有のみを同期させることができます。 そのファイル サーバーに 30 を超える共有がある場合は、共有のグループ化の概念に関するページと「ボリュームの同期」を使用して、ソースのルート フォルダーまたは最上位フォルダーの数を減らします。
3) オンプレミスで追加の File Sync サーバーを使用し、それらのサーバーにデータを分割/移動して、ソース Windows サーバーの制限事項に対処します。
4 複数の共有、ボリューム、またはこれらの両方があるファイル サーバーと、異なるストレージ アカウントの複数の Azure ファイル共有 (1 対 1 の共有マッピング) はい 1 つの Windows Server インスタンス (またはクラスター) を、最大 30 個の Azure ファイル共有と同期させることができます (同じまたは異なるストレージ アカウント)。

同期グループあたりのアイテム (ファイルとフォルダー) の数は、1 つの共有あたり 1 億個以内にします。 理想的には、1 つの共有あたり 2 千万または 3 千万個未満にするのが最適です。		 上記と同じ方法
5 1 つのルート ボリュームまたは共有がある複数のファイル サーバーと、同じターゲット Azure ファイル共有 (統合) いいえ 同期グループでは、別の同期グループで既に構成されているクラウド エンドポイント (Azure ファイル共有) を使用できません。

同期グループでは、異なるファイル サーバーでサーバー エンドポイントを使用できますが、ファイルは区別できません。		 "上記のシナリオ # 1 のガイダンスと、一度に 1 つのファイル サーバーをターゲットにする場合の追加の考慮事項に従ってください。"

マッピング テーブルを作成する

Diagram that shows an example of a mapping table. Download the following file to experience and use the content of this image.

前述の情報を使用して、必要な Azure ファイル共有の数を決定し、既存のデータのどの部分がどの Azure ファイル共有に格納されるかを判断します。

必要に応じて参照できるように、自分の考えを記録しておく表を作成します。 一度に多数の Azure リソースをプロビジョニングするときは、マッピング計画の詳細がおろそかになりがちなので、情報が整理された状態を維持することが重要です。 次の Excel ファイルをダウンロードして、マッピングの作成に役立つテンプレートとして使用します。


Excel icon that sets the context for the download. 名前空間マッピング テンプレートをダウンロードします。

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

このフェーズでは、フェーズ 1 のマッピング テーブルを参照し、それを使用して、適切な数の Azure ストレージ アカウントと、その中のファイル共有をプロビジョニングします。

Azure ファイル共有は、Azure ストレージ アカウントのクラウドに格納されます。 ここでは、また別のレベルのパフォーマンスに関する考慮事項が適用されます。

高度にアクティブな共有 (多くのユーザーやアプリケーションによって使用される共有) がある場合、2 つの Azure ファイル共有がストレージ アカウントのパフォーマンス制限に達する可能性があります。

ベスト プラクティスは、それぞれ 1 つのファイル共有を持つストレージ アカウントをデプロイすることです。 アーカイブ共有がある場合、またはそれらの中での日常のアクティビティが少ないことが予想される場合は、複数の Azure ファイル共有を同じストレージ アカウントにプールすることができます。

これらの考慮事項は、Azure File Sync より、(Azure VM 経由での) クラウドへの直接アクセスの場合によりいっそう当てはまります。これらの共有で Azure File Sync のみを使用する場合は、いくつかのものを 1 つの Azure ストレージ アカウントにグループ化するのが適切です。

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

前のフェーズで、共有の適切な数を決定しました。 この手順では、ファイル共有へのストレージ アカウントのマッピングを行いました。 次に、適切な数の Azure ファイル共有が含まれている適切な数の Azure ストレージ アカウントをデプロイします。

ご利用の各ストレージ アカウントのリージョンが、いずれも同じであり、既にデプロイしているストレージ同期サービス リソースのリージョンと一致していることを確認します。

注意事項

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

既定では、Azure ファイル共有は引き続き 5 TiB の上限で作成されます。 大きなファイル共有を作成するには、「Azure ファイル共有を作成する」の手順に従ってください。

ストレージ アカウントをデプロイする際のもう 1 つの考慮事項は、使用する Azure ストレージの冗長性です。 詳細については、「Azure Storage 冗長オプション」を参照してください。

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

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

この手順は、必ず前のフェーズが完了してから開始してください。 この時点で、Azure ストレージ リソース (ストレージ アカウントとファイル共有) が作成されているはずです。 Data Box を注文するときは、Data Box によるデータの移動先のストレージ アカウントを指定する必要があります。

このフェーズでは、前のフェーズからの移行プランの結果を、使用可能な Data Box オプションの制限にマップする必要があります。 これらの考慮事項は、選択する Data Box オプションと、それらのうちいくつが NAS 共有を Azure ファイル共有に移動するために必要になるかについて計画を立てるのに役立ちます。

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

  • どの Azure Data Box アプライアンスでも、最大 10 個のストレージ アカウントにデータを移動できます。
  • 各 Data Box オプションには、それ自身が使用できる容量が付属しています。 「Data Box のオプション」を参照してください。

移行プランを参照して、作成することを決定したストレージ アカウントの数とそれぞれの共有を確認してください。 次に、NAS 上でそれぞれの共有のサイズを確認します。 この情報を組み合わせることで、どのアプライアンスからどのストレージ アカウントにデータを送信するかを最適化し、決定することができます。 2 つの Data Box デバイスから、ファイルを同じストレージ アカウントに移動することはできますが、1 つのファイル共有のコンテンツを 2 つの Data Box に分割しないでください。

Data Box のオプション

標準的な移行の場合、次に示す Data Box のオプションから、いずれか、または組み合わせて選択します。

  • Data Box Disk。 容量がそれぞれ 8 TiB の SSD ディスクが 1 台から最大 5 台 (最大で合計 40 TiB) が Microsoft からお客様に発送されます。 暗号化とファイル システムのオーバーヘッドにより、使用できる容量は約 20% 少なくなります。 詳細については、Data Box Disk のドキュメントを参照してください。
  • Data Box。 これが最も一般的なオプションです。 NAS と同じように動作するラグド Data Box アプライアンスが Microsoft からお客様に発送されます。 使用可能な容量は 80 TiB です。 詳細については、Data Box のドキュメントを参照してください。
  • Data Box Heavy。 このオプションは、NAS と同じように機能する、車輪付きのラグド Data Box アプライアンスです。 容量は 1 PiB です。 暗号化とファイル システムのオーバーヘッドにより、使用できる容量は約 20% 少なくなります。 詳細については、Data Box Heavy のドキュメントを参照してください。

フェーズ 4: オンプレミスに適切な Windows Server インスタンスをプロビジョニングする

Azure Data Box デバイスが届くのを待っている間に、Azure File Sync で使用する 1 つ以上の Windows Server インスタンスのニーズに関する確認を始めることができます。

  • 仮想マシンまたは物理サーバーとして、Windows Server 2019 (最低でも Windows Server 2012 R2) のインスタンスを作成します。 また、Windows Server フェールオーバー クラスターもサポートされています。
  • ダイレクト接続ストレージをプロビジョニングまたは追加します。 (サポートされていない NAS ではなく、DAS です)。

デプロイする Windows Server インスタンスのリソース構成 (コンピューティングと RAM) は、主に同期するファイルとフォルダーの数によって変わります。 ご心配な場合は、より高いパフォーマンス構成を使用することをお勧めします。

同期する必要がある項目の数に基づいて Windows Server インスタンスをサイズ指定する方法を参照してください。

Note

前記のリンク先の記事には、サーバー メモリ (RAM) の範囲に関する表が含まれています。 対象のサーバーに対する範囲の下限の数字を使用できますが、初期同期にはかなり長い時間がかかることが予想されます。

フェーズ 5: ファイルを Data Box にコピーする

Data Box が到着したら、NAS アプライアンスにスムーズにネットワーク接続できるように設定する必要があります。 注文した Data Box の種類のセットアップ ドキュメントに従ってください。

Data Box の種類によっては、Data Box コピー ツールが使用できる場合があります。 現時点では、これらは完全な忠実性でファイルをコピーするものではないため、Azure ファイル共有への移行にはお勧めしません。 代わりに Robocopy を使用してください。

Data Box が届くと、注文時に指定したストレージ アカウントごとに事前プロビジョニングされた SMB 共有が利用できます。

  • ファイルが Premium の Azure ファイル共有に配置される場合は、Premium の "ファイル ストレージ" のストレージ アカウントごとに 1 つの SMB 共有が存在します。
  • ファイルが Standard ストレージ アカウントに配置される場合、Standard の (GPv1 および GPv2) ストレージ アカウントごとに 3 つの SMB 共有が存在します。 _AzFiles で終わるファイル共有のみが、移行に関連します。 すべてのブロックおよびページの BLOB 共有を無視します。

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

  1. Data Box に接続します。
  2. データを Data Box にコピーします。
    Robocopy (以下の手順に従います) または新しい Data Box データ コピー サービスを使用できます。
  3. Azure にアップロードするために Data Box を準備します。

ヒント

Robocopy の代替として、Data Box にデータ コピー サービスが作成されました。 このサービスを使用すると、Data Box にファイルを完全に忠実に読み込むことができます。 このデータ コピー サービスのチュートリアルに従って、正しい Azure ファイル共有ターゲットを設定してください。

Data Box のドキュメントには、Robocopy コマンドが指定されています。 このコマンドは、ファイルとフォルダーの完全な忠実性を維持するのには適していません。 代わりに次のコマンドを使用します。

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 など) の削除が必要になる場合があります。
/LFSM 階層型ストレージを持つターゲットの場合のみ。 移行先がリモート SMB 共有の場合はサポートされません。
RoboCopy を "低空き領域モード" で動作するよう指定します。このスイッチは、RoboCopy が完了する前にローカル容量が不足する可能性がある、階層型ストレージを持つターゲットにのみ有効です。 これは、Azure File Sync のクラウドの階層化が有効なターゲットで使用するために特別に追加されました。 これは、Azure File Sync とは別に使用できます。このモードでは、ファイルのコピーによって宛先ボリュームの空き領域が "床" 値よりも小さくなるたびに、Robocopy が一時停止します。 この値は /LFSM:n のフラグ形式で指定できます。 パラメーター n は、ベース 2: nKB、nMB、またはnGB で指定します。 明示的な床値を示さずに /LFSM を指定した場合、床は宛先ボリュームのサイズの 10% に設定されます。 低空き領域モードは、/MT、/EFSRAW または /ZB では利用できません。 /B のサポートは Windows Server 2022 で追加されました。 詳細 (関連するバグと回避策に関する詳細を含みます) については、以下の「Windows Server 2022 と RoboCopy LFSM」セクションを参照してください。
/Z 慎重に使用する
再起動モードでファイルをコピーします。 このスイッチは、ネットワーク環境が不安定な場合にのみ、使用することをお勧めします。 追加のログ記録が原因で、コピーのパフォーマンスが大幅に低下します。
/ZB 慎重に使用する
再起動モードを使用します。 アクセスが拒否された場合、このオプションではバックアップ モードが使用されます。 このオプションでは、チェックポイント処理が原因で、コピーのパフォーマンスが大幅に低下します。

重要

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

フェーズ 6: Azure File Sync クラウド リソースをデプロイする

このガイドを続行する前に、すべてのファイルが適切な Azure ファイル共有に到達するまで待ちます。 Data Box データの発送と取り込みの処理には時間がかかります。

この手順を完了するには、Azure サブスクリプションの資格情報が必要です。

Azure File Sync を構成するためのコア リソースは、"ストレージ同期サービス" と呼ばれます。 同じファイル セットを今すぐ、または今後同期するすべてのサーバーに対して、1 つのみをデプロイすることをお勧めします。 データを交換する必要のない個別のサーバー セットがある場合のみ、複数のストレージ同期サービスを作成します。 たとえば、同じ Azure ファイル共有を同期しないようにする必要があるサーバーがある場合です。 それ以外の場合は、1 つのストレージ同期サービスを使用することをお勧めします。

ストレージ同期サービスには、自分の場所に近い Azure リージョンを選択します。 他のすべてのクラウド リソースは、同じリージョンにデプロイする必要があります。 管理が簡単になるように、サブスクリプションに新しいリソース グループを作成し、同期リソースとストレージ リソースを格納します。

詳細については、「Azure File Sync のデプロイ」の記事にあるストレージ同期サービスのデプロイに関するセクションを参照してください。記事のこのセクションのみに従います。 後の手順に、この記事の他のセクションへのリンクがあります。

フェーズ 7: Azure File Sync エージェントをデプロイする

このセクションでは、Azure File Sync エージェントをご利用の Windows Server インスタンスにインストールします。

デプロイ ガイドでは、 [Internet Explorer セキュリティ強化の構成] を無効にする必要があることが説明されています。 このセキュリティ対策は、Azure File Sync には該当しません。これをオフにすると、Azure への認証が問題なく行えるようになります。

PowerShell を開きます。 次のコマンドを使用して必須の PowerShell モジュールをインストールします。 プロンプトが表示されたら、完全なモジュールと NuGet プロバイダーを必ずインストールしてください。

Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync

サーバーからインターネットへの接続で問題が発生した場合は、この段階で解決する必要があります。 Azure File Sync は、インターネットへの任意の使用可能なネットワーク接続を使用します。 インターネットに接続するためにプロキシ サーバーを要求することもサポートされています。 今すぐにマシン全体のプロキシを構成することも、エージェントのインストール中に Azure File Sync だけが使用するプロキシを指定することもできます。

プロキシを構成することが、このサーバーに対してファイアウォールを開く必要があることを意味する場合は、その方法を採用しても問題ありません。 サーバー インストールの終了時、サーバー登録が完了した後に、選択したリージョン用に Azure File Sync が通信する必要がある Azure 内の正確なエンドポイント URL を示すネットワーク接続レポートが示されます。 このレポートには、なぜ通信が必要なのかも示されています。 このレポートを使用して、このサーバーのファイアウォールを特定の URL にロック ダウンできます。

また、ファイアウォール全体を開かない、より保守的なアプローチを採用することもできます。 代わりに、上位レベルの DNS 名前空間と通信するようサーバーを制限できます。 詳細については、「Azure File Sync のプロキシとファイアウォールの設定」をご覧ください。 ご自分のネットワークのベスト プラクティスに従ってください。

サーバーのインストール ウィザードの終了時に、サーバーの登録ウィザードが開きます。 以前からご利用のストレージ同期サービスの Azure リソースにサーバーを登録します。

最初にインストールする必要がある PowerShell モジュールを含め、これらの手順については、デプロイ ガイドで詳しく説明されています。Azure File Sync エージェントのインストール。

最新のエージェントを使用してください。 Microsoft ダウンロード センターからダウンロードできます。Azure File Sync エージェント。

インストールとサーバーの登録が正常に完了したら、この手順が正常に完了したことを確認できます。 Azure portal のストレージ同期サービス リソースに移動します。 左側のメニューで、 [登録済みサーバー] に移動します。 ご利用のサーバーがそこに一覧表示されます。

フェーズ 8: Windows Server インスタンスで Azure File Sync を構成する

このプロセスのために、登録済みのオンプレミス Windows Server インスタンスを準備して、インターネットに接続しておく必要があります。

このステップでは、前の手順で Windows Server インスタンスに設定したすべてのリソースとフォルダーを結び付けます。

  1. Azure portal にサインインします。
  2. ストレージ同期サービスのリソースを見つけます。
  3. 各 Azure ファイル共有のストレージ同期サービス リソース内に新しい "同期グループ" を作成します。 Azure File Sync の用語では、Azure ファイル共有は、同期グループの作成と共に記述する同期トポロジの "クラウド エンドポイント" になります。 同期グループを作成する際に、ここで同期するファイルのセットを認識できるように、わかりやすい名前を付けます。 名前が一致する Azure ファイル共有を参照していることを確認します。
  4. 同期グループを作成すると、同期グループの一覧にその行が表示されます。 名前 (リンク) を選択して、同期グループの内容を表示します。 [クラウド エンドポイント] の下に Azure ファイル共有が表示されます。
  5. [サーバー エンドポイントの追加] ボタンを見つけます。 プロビジョニングしたローカル サーバー上のフォルダーは、この "サーバー エンドポイント" のパスになります。

クラウドを使った階層化機能を有効にし、最初のダウンロード セクションで [Namespace only](名前空間のみ) を選択します。

重要

クラウドを使った階層化は、ローカル サーバーが、クラウドに格納されているよりもストレージ容量が少なくても、完全な名前空間を使用できるようにする Azure File Sync の機能です。 ローカル環境で関心のあるデータも、アクセスのパフォーマンスを上げるためにローカルにキャッシュされます。 クラウドを使った階層化は省略可能です。 これは Azure File Sync サーバー エンドポイントごとに個別に設定できます。 この機能を使用する必要があるのは、すべてのクラウド データを保持するのに十分なローカル ディスク容量が Windows Server インスタンスになく、クラウドからすべてのデータをダウンロードすることは避けたい場合です。

同期のために構成する必要があるすべての Azure ファイル共有またはサーバーの場所について、同期グループを作成する手順と、一致するサーバー フォルダーをサーバー エンドポイントとして追加する手順を繰り返します。 名前空間の同期が完了するまで待ちます。 次のセクションでは、同期を確実に完了する方法について説明します。

Note

サーバー エンドポイントの作成後、同期は機能しています。 ただし、同期では Data Box を介して Azure ファイル共有に移動したファイルとフォルダーを列挙 (検出) する必要があります。 名前空間のサイズによっては、クラウドの名前空間がサーバーに表示されるまでにかなりの時間がかかることがあります。

フェーズ 9: 名前空間がサーバーに完全に表示されるまで待機する

移行の次の手順に進む前に、サーバーにクラウド共有から名前空間が完全にダウンロードされるまで待ちます。 サーバーへのファイルの移動の開始が早すぎると、不要なアップロードや、さらにはファイル同期の競合が発生するリスクがあります。

サーバーで初回ダウンロード同期が完了したかどうかを確認するには、同期している Windows Server インスタンスでイベント ビューアーを開き、Azure File Sync テレメトリ イベント ログを使用します。 テレメトリ イベント ログは、イベント ビューアーの Applications and Services\Microsoft\FileSync\Agent にあります。

最新の 9102 イベントを検索します。 同期セッションが完了すると、イベント ID 9102 がログされます。 イベント テキストには、ダウンロード同期の方向のフィールドがあります。 (HResult は 0 にする必要があり、ファイルをダウンロードする必要があります。)

サーバーで名前空間のダウンロードが完了したことを確認するには、このコンテンツを含む、この種類の 2 つの連続するイベントを確認する必要があります。 2 つの 9102 イベントの間に他のイベントがあっても問題ありません。

フェーズ 10: NAS から Robocopy を実行する

ご使用のサーバーで、クラウド共有からの名前空間全体の初期同期が完了したら、この手順を続行できます。 この手順を続行する前に、初期同期が完了している必要があります。 詳細については、前のセクションを参照してください。

この手順では、Robocopy ジョブを実行して、クラウド共有を、共有を Data Box にフォークしてから発生した NAS 上の最新の変更と同期します。 この Robocopy の実行は、NAS 共有で発生したチャーンの量によって、短時間で終了することも、時間がかかることもあります。

警告

Windows Server 2019 で低下した Robocopy の動作のため、Robocopy /MIR スイッチは階層化されたターゲット ディレクトリに対応していません。 移行のこのフェーズでは、Windows Server 2019 または Windows 10 クライアントは使用できません。 中間の Windows Server 2016 インスタンスで、Robocopy を使用します。

基本的な移行方法を次に示します。

  • NAS アプライアンスから Robocopy を実行して、Windows Server インスタンスを同期します。
  • Azure File Sync を使用して、Windows Server から Azure ファイル共有を同期します。

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

  1. NAS アプライアンス上で最初の場所を特定します。
  2. Windows Server インスタンス上で、既に Azure File Sync が構成されている対応するフォルダーを特定します。
  3. Robocopy を使用してコピーを開始します。

次の Robocopy コマンドを実行すると、NAS ストレージから Windows Server のターゲット フォルダーに差分 (更新されたファイルおよびフォルダー) のみがコピーされます。 その後、Windows Server インスタンスによってそれらが 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 など) の削除が必要になる場合があります。
/LFSM 階層型ストレージを持つターゲットの場合のみ。 移行先がリモート SMB 共有の場合はサポートされません。
RoboCopy を "低空き領域モード" で動作するよう指定します。このスイッチは、RoboCopy が完了する前にローカル容量が不足する可能性がある、階層型ストレージを持つターゲットにのみ有効です。 これは、Azure File Sync のクラウドの階層化が有効なターゲットで使用するために特別に追加されました。 これは、Azure File Sync とは別に使用できます。このモードでは、ファイルのコピーによって宛先ボリュームの空き領域が "床" 値よりも小さくなるたびに、Robocopy が一時停止します。 この値は /LFSM:n のフラグ形式で指定できます。 パラメーター n は、ベース 2: nKB、nMB、またはnGB で指定します。 明示的な床値を示さずに /LFSM を指定した場合、床は宛先ボリュームのサイズの 10% に設定されます。 低空き領域モードは、/MT、/EFSRAW または /ZB では利用できません。 /B のサポートは Windows Server 2022 で追加されました。 詳細 (関連するバグと回避策に関する詳細を含みます) については、以下の「Windows Server 2022 と RoboCopy LFSM」セクションを参照してください。
/Z 慎重に使用する
再起動モードでファイルをコピーします。 このスイッチは、ネットワーク環境が不安定な場合にのみ、使用することをお勧めします。 追加のログ記録が原因で、コピーのパフォーマンスが大幅に低下します。
/ZB 慎重に使用する
再起動モードを使用します。 アクセスが拒否された場合、このオプションではバックアップ モードが使用されます。 このオプションでは、チェックポイント処理が原因で、コピーのパフォーマンスが大幅に低下します。

重要

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

NAS アプライアンスでファイルが使用する量より少ないストレージを Windows Server にプロビジョニングした場合は、クラウドを使った階層化を構成しています。 ローカル環境の Windows Server ボリュームがいっぱいになると、クラウドを使った階層化により、既に正常に同期されているファイルの階層化が開始されます。 クラウドを使った階層化により、NAS アプライアンスからのコピーを続けるのに十分な領域が生成されます。 クラウドを使った階層化では、1 時間に 1 回、同期されたものが確認されて、ボリューム空き領域 99% になるようにディスク領域が解放されます。

Robocopy を使用すると、Windows Server インスタンスでローカルに格納できるよりも多くのファイルを移動しなければならない場合があります。 Robocopy を使用した方が、Azure File Sync でファイルをアップロードしてローカル ボリューム外に階層化するよりも速くファイルを移動できます。 この状況では、Robocopy は失敗します。 このシナリオを回避する順序で共有を処理することをお勧めします。 たとえば、Windows Server インスタンスで使用可能な空き領域に収まる共有のみを移動します。 または、すべての共有に対して Robocopy ジョブを同時に開始しないようにします。 良い点は、/MIR スイッチを使用することで、差分だけを確実に移動できることです。 差分を移動した後、再開されたジョブでファイルを再度移動する必要はありません。

カットオーバーを実行する

Robocopy コマンドを初めて実行するときは、ユーザーとアプリケーションが引き続き NAS 上のファイルにアクセスしていて、それを変更する可能性があります。 Robocopy では 1 つのディレクトリを処理してから、次のディレクトリに移動します。 その後、NAS のユーザーが、現在の Robocopy の実行中に処理されない最初のディレクトリでファイルの追加、変更、または削除を行う可能性があります。 これは正しい動作です。

最初の実行では、チャーンされたデータの大部分が Windows Server インスタンスに移動され、Azure File Sync 経由でクラウドに移動されます。この最初のコピーには、次の条件によっては時間がかかることがあります。

  • アップロードの帯域幅。
  • ローカル ネットワークの速度と、それに合った最適な Robocopy スレッドの数。
  • Robocopy と Azure File Sync によって処理される必要がある項目 (ファイルとフォルダー) の数。

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

共有に対して 2 回目に Robocopy を実行すると、より速く完了します。 これは、前回の実行以降に発生した変更だけを転送する必要があるためです。 同じ共有に対してジョブを繰り返し実行できます。

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

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

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

  • これらのユーザーを Windows Server ローカル ユーザーとして再作成します。
  • Robocopy によって Windows Server インスタンスに移動された既存の SID を、新しい Windows Server ローカル ユーザーの SID にマップします。

これで、共通のルートまたはボリューム (フェーズ 1 からのマッピングによって異なります) への共有または共有のグループの移行は完了しました。

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

非推奨のオプション: "オフライン データ転送"

Azure File Sync エージェント バージョン 13 がリリースされる前、Data Box 統合は "オフライン データ転送" と呼ばれるプロセスを通して実現されました。 このプロセスは非推奨です。 これは、エージェント バージョン 13 で、この記事で説明されているはるかに簡単かつ高速な手順に置き換えられました。 非推奨の "オフライン データ転送" 機能を使用する必要があるとわかっている場合は、引き続きそうすることができます。 これは、具体的には、以前の AFS PowerShell モジュールを使用することによって引き続き可能です。

Install-Module Az.StorageSync -RequiredVersion 1.4.0
Import-module Az.StorageSync -RequiredVersion 1.4.0
# Verify the specific version is loaded:
Get-module Az.StorageSync

警告

2022 年 5 月 15 日以降は、"オフライン データ転送" モードでサーバー エンドポイントを作成できなくなります。 この方法で進行中の移行は、2022 年 7 月 15 日より前に終了する必要があります。 "オフライン データ転送" が有効になっているサーバー エンドポイントを使用して移行を実行し続けると、サーバーは 2022 年 7 月 15 日にサーバーからの残りのファイルのアップロードを開始し、Azure Data Box で転送されたファイルをステージング共有に利用できなくなります。

トラブルシューティング

最も一般的な問題は、Windows Server 側で "ボリュームがいっぱい" になったために Robocopy コマンドが失敗することです。 クラウドを使った階層化は 1 時間ごとに動作し、同期されたローカルの Windows Server ディスクからコンテンツが退避されます。 目標は、ボリュームの空き領域を 99% にすることです。

同期を進行させ、クラウドを使った階層化にディスク領域を解放させます。 これは、Windows Server インスタンスのエクスプローラーで確認できます。

Windows Server インスタンスに空き容量が十分にある場合は、コマンドを再度実行すると問題が解決されます。 この状況で、壊れるものは何もありません。 自信を持って前進できます。 コマンドを再実行する不便さだけが、唯一の影響です。

Azure File Sync の問題のトラブルシューティングを行うには、次のセクションに記載されている記事をご覧ください。

次のステップ

Azure ファイル共有と Azure File Sync については、さらに知るべきことがあります。以下の記事は、詳細なオプションおよびベスト プラクティスの理解に役立ちます。 また、トラブルシューティングに役立つ情報も提供します。 これらの記事には、必要に応じて Azure ファイル共有のドキュメントへのリンクが含まれています。