Azure Data Box を使用して Azure File Sync にオフラインでデータを移行する
この移行に関する記事は、Azure File Sync および Azure Data Box というキーワードに当てはまる複数の記事の 1 つです。 この記事がご使用のシナリオに当てはまるかどうかを確認してください。
- データ ソース: Windows Server 2012 R2 以降。Azure File Sync がインストールされ、元のファイル セットを指します。
- 移行ルート: Windows Server 2012 R2 以降 ⇒Data Box ⇒ Azure File Sync ⇒ Windows Server の元のファイルの場所と同期
- オンプレミスのファイル キャッシュ: はい、最終的な目標は、現在の場所からファイルを同期させる Azure File Sync のデプロイです。
ご自身のオンプレミスの Windows Server から、別のファイル共有にデータの大部分を移動するには、Azure Data Box を使用するパスが有効です。その後、必要に応じて、元のソース サーバー上で Azure File Sync を追加できます。
使用できる移行パスはさまざまです。正しいパスに従うことが重要です。
- お使いのデータが Windows Server 2012 R2 以降にあり、AFS をそのサーバーにインストールし、元の場所を同期する。 このシナリオでは、必ずしもすべてのファイルをアップロードするのではなく、代わりに Data Box を使用し、ファイル同期を使用して継続的な変更に対応します。 この記事では、このシナリオを対象とした移行パスについて説明します。
- AFS をインストールしない、またはインストールできないソース、 たとえば、NAS (ネットワーク接続ストレージ) や別のサーバー上にデータがある。 新しい空のサーバーを作成し、そのサーバー上で Azure File Sync を使用します。 このシナリオの場合、この移行ガイドは適切でありません。 NAS から Azure File Sync への DataBox を使用した移行に関するページをご覧になるか、移行の概要ページで、ご自身のシナリオに合ったガイドを見つけてください。
- その他のすべてのシナリオについては、Azure File Share 移行ガイドの表をご確認ください。 この概要ページは、すべての移行シナリオの良い出発点になります。
移行の概要
移行プロセスは、いくつかのフェーズで構成されます。 次のことを行う必要があります。
- ストレージ アカウントとファイル共有をデプロイする。
- 1 つ以上の Azure Data Box デバイスをデプロイして、Windows Server 2012 R2 以降からデータを移動する。
- 権限のあるアップロードで Azure File Sync を構成する。
以下のセクションでは、移行プロセスの各フェーズについて詳しく説明します。
ヒント
この記事に戻った場合は、画面の右側にあるナビゲーションを使用して、中断した移行フェーズにジャンプします。
フェーズ 1: 必要な Azure ファイル共有の数を決定する
この移行ガイドでは、ご自身のファイルを含むオンプレミスの直接接続ストレージ (DAS) を引き続き使用する必要があります。 Data Box はその場所から取り込まれ、Azure File Sync もその場所で設定されます。 NAS (ネットワーク接続ストレージ) は、この移行パスでは機能しません。
同期対象を決定するには、Azure File Sync の "同期グループ" を設定します。これにより、ファイル セットが同期する場所がそれぞれ決まります。 各同期グループには、少なくとも 1 つのサーバーの場所 ("サーバー エンドポイント" と呼ばれます)、1 つの Azureファイル共有 ("クラウド エンドポイント" と呼ばれます) があります。
ファイル セットのサブ パスを、それぞれの Azure ファイル共有に同期させることができます。 つまり、ファイル セットを完全にカバーするように、複数の同期グループを設定します。 セクションの残りの部分では、使用できるオプションについて説明します。 ご自身のデータを再構築する必要がある場合は、このガイドの手順を続行する前に、まずは再構築を行い、Data Box を注文するか、同期を設定してください。
注意事項
移行を開始する前に、ファイルとフォルダーを、長期的にどうあるべきかを考えた構造にしておくことが必須です。 移行中、不必要にフォルダーを再構築することは避けます。 Azure Data Box を使用して 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 つのファイル サーバーをターゲットにする場合の追加の考慮事項に従ってください。" |
マッピング テーブルを作成する
前述の情報を使用して、必要な Azure ファイル共有の数を決定し、既存のデータのどの部分がどの Azure ファイル共有に格納されるかを判断します。
必要に応じて参照できるように、自分の考えを記録しておく表を作成します。 一度に多数の Azure リソースをプロビジョニングするときは、マッピング計画の詳細がおろそかになりがちなので、情報が整理された状態を維持することが重要です。 次の Excel ファイルをダウンロードして、マッピングの作成に役立つテンプレートとして使用します。
|
名前空間マッピング テンプレートをダウンロードします。 |
フェーズ 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 のドキュメントを参照してください。
Note
Data Box と Data Box Heavy については、SMB 経由でのデータのコピーだけがサポートされています。 データ コピー サービスを使用したデータのコピーは、ファイルの忠実性が保持されないのでサポートされていません。
フェーズ 4: ファイルを 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 のドキュメントの手順に従ってください。
- Data Box に接続します。
- データを Data Box にコピーします。
- Azure にアップロードするために Data Box を準備します。
リンク先の 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 シナリオに対する重要な修正プログラムが含まれています。
フェーズ 5: Azure File Sync クラウド リソースをデプロイする
このガイドを続行する前に、すべてのファイルが適切な Azure ファイル共有に到達するまで待ちます。 Data Box データの発送と取り込みの処理には時間がかかります。
この手順を完了するには、Azure サブスクリプションの資格情報が必要です。
Azure File Sync を構成するためのコア リソースは、"ストレージ同期サービス" と呼ばれます。 同じファイル セットを今すぐ、または今後同期するすべてのサーバーに対して、1 つのみをデプロイすることをお勧めします。 データを交換する必要のない個別のサーバー セットがある場合のみ、複数のストレージ同期サービスを作成します。 たとえば、同じ Azure ファイル共有を同期しないようにする必要があるサーバーがある場合です。 それ以外の場合は、1 つのストレージ同期サービスを使用することをお勧めします。
ストレージ同期サービスには、自分の場所に近い Azure リージョンを選択します。 他のすべてのクラウド リソースは、同じリージョンにデプロイする必要があります。 管理が簡単になるように、サブスクリプションに新しいリソース グループを作成し、同期リソースとストレージ リソースを格納します。
詳細については、「Azure File Sync のデプロイ」の記事にあるストレージ同期サービスのデプロイに関するセクションを参照してください。記事のこのセクションのみに従います。 後の手順に、この記事の他のセクションへのリンクがあります。
フェーズ 6: 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 のストレージ同期サービス リソースに移動します。 左側のメニューで、 [登録済みサーバー] に移動します。 ご利用のサーバーがそこに一覧表示されます。
フェーズ 7: 既存の Windows Server 上で Azure File Sync を構成する
このプロセスのために、登録済みのオンプレミス Windows Server インスタンスを準備して、インターネットに接続しておく必要があります。
このステップでは、前の手順で Windows Server インスタンスに設定したすべてのリソースとフォルダーを結び付けます。
- Azure portal にサインインします。
- ストレージ同期サービスのリソースを見つけます。
- 各 Azure ファイル共有のストレージ同期サービス リソース内に新しい "同期グループ" を作成します。 Azure File Sync の用語では、Azure ファイル共有は、同期グループの作成と共に記述する同期トポロジの "クラウド エンドポイント" になります。 同期グループを作成する際に、ここで同期するファイルのセットを認識できるように、わかりやすい名前を付けます。 名前が一致する Azure ファイル共有を参照していることを確認します。
- 同期グループを作成すると、同期グループの一覧にその行が表示されます。 名前 (リンク) を選択して、同期グループの内容を表示します。 [クラウド エンドポイント] の下に Azure ファイル共有が表示されます。
- [サーバー エンドポイントの追加] ボタンを見つけます。 プロビジョニングしたローカル サーバー上のフォルダーは、この "サーバー エンドポイント" のパスになります。
サーバー エンドポイントの作成ウィザードで、フォルダー パスの下のチェックボックスを利用します。 このオプションは、Azure ファイル共有内の構造と同じファイルおよびフォルダー構造を指すパスを入力した場合にのみ選択します (ファイルとフォルダーは、Data Box によってこの名前空間に移動されます)。
フォルダー階層が一致しない場合、その不一致は、自動的に解決できない差異として示されます。 不一致を避けなければ、Data Box プロセスに投資しても、メリットを得られません。 Azure ファイル共有内のすべてのデータが削除され、 すべてのデータを、ローカル サーバーからアップロードする必要が出てきます。 サーバーからの Azure Data Box による一括移行、および最新の変更によるクラウド共有のシームレスな更新のメリットを得るには、ディレクトリ構造が一致している必要があります。
Note
このチェックボックスを有効にすると、初期同期モードが "Azure ファイル共有内のファイルとフォルダーが、このサーバーのパス内のコンテンツで上書きされる" ように設定されます。このオプションは、同期グループ内の最初のサーバー エンドポイントに対してのみ使用できます。
この新しいサーバー エンドポイントに対して権限のあるアップロードを構成したら、必要に応じて、クラウドを使った階層化を有効にすることができます。
クラウドを使った階層化は、ローカル サーバーが、クラウドに格納されているよりもストレージ容量が少なくても、完全な名前空間を使用できるようにする Azure File Sync の機能です。 ローカル環境で関心のあるデータも、アクセスのパフォーマンスを上げるためにローカルにキャッシュされます。 クラウドを使った階層化は省略可能です。 これは Azure File Sync サーバー エンドポイントごとに個別に設定できます。 この機能を使用して、オンプレミスで固定のストレージ フットプリントを実現しながら、ユーザーにローカル パフォーマンス キャッシュを提供し、よりクールなデータをクラウドに格納します。
詳細については、「クラウドの階層化の概要」を参照してください。また、さまざまなクラウド階層化ポリシーを詳しく確認し、ローカル サーバー上でのキャッシュ/階層化の内容を微調整することもできます。
移行を完了する
サーバー エンドポイントの作成後、同期は機能しています。 ただし、同期では Azure Data Box を介して Azure ファイル共有に移動したファイルとフォルダーを列挙 (検出) する必要があります。 名前空間のサイズによっては、最新のサーバー変更がクラウドに同期されるまでに時間がかかることがあります。 ユーザーには影響がなく、引き続きサーバー上のデータを処理することができます。 この戦略により、ダウンタイムなしのクラウド移行が実現します。
同期のために構成する必要があるすべての Azure ファイル共有またはサーバーの場所について、同期グループを作成する手順と、一致するサーバー フォルダーをサーバー エンドポイントとして追加する手順を繰り返します。 Azure Data Box を使用して、お使いのファイルを複数の Azure ファイル共有に移動しました。 ご自身のオンプレミス データを、これらの Azure ファイル共有に接続するためのサーバー エンドポイントをすべて作成したら、移行は完了です。
次のステップ
Azure ファイル共有と Azure File Sync については、さらに知るべきことがあります。以下の記事は、詳細なオプションおよびベスト プラクティスの理解に役立ちます。 また、トラブルシューティングに役立つ情報も提供します。 これらの記事には、必要に応じて Azure ファイル共有のドキュメントへのリンクが含まれています。