StorSimple 8100 および 8600 から Azure File Sync への移行

  • [アーティクル]

StorSimple 8000 シリーズには、8100 または 8600 物理オンプレミス アプライアンスとそのクラウド サービス コンポーネントが含まれています。 この移行ガイドでは、StorSimple 8010 と 8020 の仮想アプライアンスについても説明します。 これらのいずれかのアプライアンスから、オプションの Azure File Sync を使って Azure ファイル共有にデータを移行できます。Azure File Sync は、StorSimple オンプレミス機能を置き換える既定の戦略的な長期 Azure サービスです。 この記事では、Azure File Sync への移行を成功させるために必要な背景知識と移行手順について説明します。

注意

StorSimple サービス (8000 および 1200 シリーズと StorSimple Data Manager 用の StorSimple デバイス マネージャーを含む) がサポート終了に達しました。 StorSimple のサポート終了は、2019 年に Microsoft ライフサイクル ポリシーと Azure のお知らせのページで発表されました。 追加の通知がメールで送られ、Azure portal と StorSimple の概要に関するページに掲示されました。 詳しくは、Microsoft サポートにお問い合わせください。

移行の概要 - クリックして再生します。

このビデオでは、次の概要について説明します。

  • Azure Files
  • Azure File Sync
  • StorSimple と Azure Files の比較
  • StorSimple Data Manager 移行ツールとプロセスの概要

フェーズ 1:移行を準備する

このセクションでは、StorSimple ボリュームから Azure ファイル共有への移行の開始時に実行する必要がある手順について説明します。

移行を準備する - クリックして再生します。

このビデオの内容は次のとおりです。

  • ストレージ層を選択する
  • ストレージ冗長オプションを選択する
  • 直接共有アクセスと Azure File Sync を選択する
  • StorSimple サービス データ暗号化キーとシリアル番号
  • StorSimple ボリューム バックアップの移行
  • StorSimple ボリュームおよび共有の Azure ファイル共有へのマッピング
  • Azure ファイル共有内の共有をグループ化する
  • マッピングに関する考慮事項
  • 移行計画ワークシート
  • 名前空間マッピング スプレッドシート

インベントリ

移行の計画を始めるときは、まず、移行する必要がある StorSimple のすべてのアプライアンスとボリュームを明らかにします。 その後、最適な移行パスを決定できます。

  • StorSimple 物理アプライアンス (8000 シリーズ) の場合は、この移行ガイドを使用します。
  • StorSimple 仮想アプライアンス (1200 シリーズ) では、別の移行ガイドを使用します。

移行コストの概要

StorSimple Data Manager リソースでの移行ジョブによる StorSimple ボリュームから Azure ファイル共有への移行は無料です。 移行中および移行後に、他のコストが発生する可能性があります。

  • ネットワーク エグレス: StorSimple のファイルは、特定の Azure リージョン内のストレージ アカウントに存在します。 移行する Azure ファイル共有を同じ Azure リージョン内のストレージ アカウントにプロビジョニングする場合、エグレス コストは発生しません。 ただし、この移行の一部として別のリージョン内のストレージ アカウントにファイルを移動する場合は、エグレス コストが適用されます。
  • Azure ファイル共有のトランザクション: ファイルを Azure ファイル共有にコピーするとき (移行の一部として、またはその外部で)、ファイルとメタデータが書き込まれるときに、トランザクション コストがかかります。 ベスト プラクティスとしては、移行の間にトランザクション最適化レベルで Azure ファイル共有を開始します。 移行が完了した後で、目的のレベルに切り替えます。 この記事で説明されている各フェーズでは、これが適切なポイントで示されています。
  • Azure ファイル共有レベルの変更: Azure ファイル共有のレベルを変更すると、トランザクションのコストがかかります。 ほとんどの場合は、前のポイントのアドバイスに従う方がコスト効率は高くなります。
  • ストレージ コスト: この移行で Azure ファイル共有へのファイルのコピーが開始されるときに、ストレージが使用され、課金されます。 移行されたバックアップは、Azure ファイル共有スナップショットになります。 ファイル共有スナップショットでは、含まれている差異に対するストレージ容量のみが消費されます。
  • StorSimple: StorSimple デバイスとストレージ アカウントをプロビジョニング解除するまで、ストレージ、バックアップ、アプライアンスに対する StorSimple のコストが引き続き発生します。

直接共有アクセスと Azure File Sync

Azure ファイル共有により、ファイル サービスのデプロイを構築するための機会の新しい世界が開かれます。 Azure ファイル共有は、ユーザーが使い慣れた Kerberos 認証とネイティブに機能している既存の NTFS アクセス許可 (ファイルとフォルダーの ACL) を使用して、SMB プロトコル経由で直接アクセスできるように設定することができる、クラウド内の SMB 共有です。 Azure ファイル共有への ID ベースのアクセスの詳細について参照してください。

直接アクセスの代わりに、Azure File Sync を使用できます。Azure File Sync は、頻繁に使用されるファイルをオンプレミスにキャッシュする StorSimple の機能に直接相当します。

Azure File Sync は、次の 2 つの主要なコンポーネントに基づく Microsoft のクラウド サービスです。

  • Windows Server でパフォーマンス アクセス キャッシュを作成するためのファイルの同期とクラウドの階層化。
  • SMB や file REST などの複数のプロトコルを介してアクセスできる、Azure でのネイティブ ストレージとしてのファイル共有。

Azure ファイル共有では、属性、アクセス許可、タイムスタンプなどのファイルの忠実性という重要な側面が保持されます。 Azure ファイル共有を使用すると、クラウドに格納されているファイルやフォルダーをアプリケーションやサービスで解釈する必要がなくなります。 使い慣れたプロトコルとクライアントを使用して、それらにネイティブにアクセスできます。 Azure ファイル共有を使用すると、汎用のファイル サーバー データとアプリケーション データをクラウドに格納することができます。

この記事では、移行手順を中心に説明します。 移行前に Azure File Sync について詳しく知りたい場合は、次の記事を参照してください。

StorSimple のサービス データ暗号化キー

最初に StorSimple アプライアンスを設定すると、サービス データ暗号化キーが生成され、そのキーを安全に格納するように指示されます。 このキーは、関連付けられている Azure ストレージ アカウント内のすべてのデータを暗号化するために使用され、そこに StorSimple アプライアンスによってファイルが格納されます。

このサービス データ暗号化キーは、移行を成功させるために必要です。 インベントリ内のアプライアンスごとに 1 つ、このキーをレコードから取得します。

レコード内にキーが見つからない場合は、アプライアンスから新しいキーを生成できます。 各アプライアンスには一意の暗号化キーがあります。

サービス データ暗号化キーの変更

サービス データ暗号化キーを使用して、StorSimple Manager サービスから StorSimple デバイスに送信される、顧客の機密データ (ストレージ アカウントの資格情報など) を暗号化します。 IT 組織にストレージ デバイスに関するキー ローテーション ポリシーがある場合は、これらのキーを定期的に変更する必要があります。 キーの変更プロセスは、StorSimple Manager サービスが 1 つのデバイスを管理しているか、または複数のデバイスを管理しているかによって多少異なります。 詳細については、「StorSimple のセキュリティとデータの保護」を参照してください。

サービス データ暗号化キーの変更は、次の 3 つの手順からなるプロセスです。

  1. Azure Resource Manager 用の Windows PowerShell スクリプトを使用して、サービス データ暗号化キーを変更するデバイスを承認します。
  2. StorSimple 用 Windows PowerShell を使用して、サービス データ暗号化キーの変更を開始します。
  3. StorSimple デバイスを複数使用している場合は、他のすべてのデバイスでサービス データ暗号化キーを更新します。

手順 1:Windows PowerShell スクリプトを使用してサービス データ暗号化キーを変更するデバイスを承認する

通常、デバイスの管理者は、サービス データ暗号化キーを変更する場合、デバイスの承認をサービス管理者に依頼します。 その後、サービス管理者は、キーの変更をデバイスに承認します。

この手順は、Azure Resource Manager ベースのスクリプトを使用して実行します。 サービス管理者は、承認するのに適したデバイスを選択できます。 選択したデバイスは、サービス データ暗号化キー変更プロセスを開始できるようになります。

スクリプトの使用の詳細については、「Authorize-ServiceEncryptionRollover.ps1」を参照してください

サービス データ暗号化キーの変更を許可できるデバイス

デバイスは、サービス データ暗号化キーの変更開始の承認に先立ち、次の条件を満たす必要があります。

  • デバイスがサービス データ暗号化キーの変更の承認の対象となるようにオンラインである必要があります。
  • キーの変更が開始されなかった場合は、30 分経過後にもう一度同じデバイスを承認できます。
  • 別のデバイスを承認するには、既に承認済みのデバイスによってキーの変更が開始されていないことが条件となります。 新しいデバイスが承認された後に、以前のデバイスが変更を開始することはできません。
  • サービス データ暗号化キーのロールオーバーの実行中に、デバイスを承認することはできません。
  • サービスに登録されているデバイスの中に、暗号化をロールオーバーしたデバイスと、ロールオーバしていないデバイスがある場合、デバイスを承認できます。

手順 2:StorSimple 用 Windows PowerShell を使用してサービス データ暗号化キーの変更を開始する

この手順は、承認済みの StorSimple デバイスの StorSimple 用 Windows PowerShell インターフェイスで実行されます。

Note

キーのロールオーバーが完了するまで、StorSimple Manager サービスの Azure Portal では操作を行うことができません。

デバイスのシリアル コンソールを使用して Windows PowerShell インターフェイスに接続している場合は、次の手順を実行します。

サービス データ暗号化キーの変更を開始するには

  1. オプション 1 を選択して、フル アクセスでログオンします。

  2. コマンド プロンプトに、次のコマンドを入力します。

    Invoke-HcsmServiceDataEncryptionKeyChange

  3. コマンドレットが正常に完了すると、新しいサービス データ暗号化キーが表示されます。 このキーをコピーし、このプロセスの手順 3. で使用するために保存します。 このキーは、StorSimple Manager サービスに登録されている残りのすべてのデバイスの更新に使用されます。

    Note

    このプロセスは、StorSimple デバイスを承認してから 4 時間以内に開始する必要があります。

    4 時間を経過すると、この新しいキーはサービスに送信され、サービスに登録されているすべてのデバイスにプッシュされます。 そのようになると、サービスのダッシュボードにアラートが表示されます。 このサービスにより、登録済みのデバイス上でのすべての操作が無効になります。その後、デバイスの管理者は、他のデバイスのサービス データ暗号化キーを更新する必要があります。 ただし、I/O (データをクラウドに送信するホスト) は中断されません。

    サービスに登録されているデバイスが 1 台の場合は、ロールオーバー プロセスが完了し、次の手順をスキップできます。 サービスに登録されているデバイスが複数ある場合は、手順 3. に進みます。

手順 3:他の StorSimple デバイス上のサービス データ暗号化キーを更新する

StorSimple Manager サービスに登録されているデバイスが複数ある場合は、StorSimple デバイスの Windows PowerShell インターフェイスで次の手順を実行する必要があります。 手順 2. で取得したキーを使用して、StorSimple Manager サービスに登録されている残りのすべての StorSimple デバイスを更新する必要があります。

デバイスのサービス データ暗号化を更新するには、次の手順を実行します。

物理デバイス上のサービス データ暗号化キーを更新するには

  1. StorSimple 用 Windows PowerShell を使用して、コンソールに接続します。 オプション 1 を選択して、フル アクセスでログオンします。
  2. コマンド プロンプトに Invoke-HcsmServiceDataEncryptionKeyChange – ServiceDataEncryptionKey を入力します。
  3. 「手順 2. StorSimple 用 Windows PowerShell を使用してサービス データ暗号化キーの変更を開始する」で取得したサービス データ暗号化キーを指定します。

すべての 8010/8020 クラウド アプライアンス上のサービス データ暗号化キーを更新するには

  1. Update-CloudApplianceServiceEncryptionKey.ps1 PowerShell スクリプトをダウンロードして設定します。
  2. PowerShell を開き、コマンド プロンプトに次のように入力します。Update-CloudApplianceServiceEncryptionKey.ps1 -SubscriptionId [subscription] -TenantId [tenantid] -ResourceGroupName [resource group] -ManagerName [device manager]

このスクリプトは、デバイス マネージャーにあるすべての 8010/8020 クラウド アプライアンスで、サービス データ暗号化キーが設定されていることを確認します。

注意事項

StorSimple アプライアンスに接続する方法を決定するときは、次の点を考慮してください。

  • HTTPS セッション経由での接続は、最も安全であり、推奨されるオプションです。
  • デバイスのシリアル コンソールへの直接接続はセキュリティで保護されますが、ネットワーク スイッチを経由したシリアル コンソールへの接続は保護されません。
  • HTTP セッションの接続はオプションですが "暗号化されません"。 閉じた信頼できるネットワーク内で使用されている場合を除き、推奨されません。

既知の制限事項

StorSimple Data Manager と Azure ファイル共有には、移行を妨げる可能性のある、開始する前に考慮すべき次のようないくつかの制限があります。

  • StorSimple アプライアンスの NTFS ボリュームのみがサポートされています。 ReFS ボリュームはサポートされていません。
  • Windows Server のダイナミック ディスクに配置されているボリュームはサポートされていません。
  • このサービスは、BitLocker で暗号化されたボリュームや、データ重複除去が有効になっているボリュームでは機能しません。
  • 破損した StorSimple バックアップは移行できません。
  • 特殊なネットワーク オプション (ファイアウォールまたはプライベート エンドポイントのみの通信など) は、StorSimple バックアップが格納されているソース ストレージ アカウントと、Azure ファイル共有を保持するターゲット ストレージ アカウントのどちらでも有効にすることができません。

ファイルの忠実性

既知の制限事項のいずれの制限によっても移行が妨げられない場合でも、Azure ファイル共有に格納できる内容に対する制限が依然として存在します。

"ファイルの忠実性" とは、ファイルを構成する多数の属性、タイムスタンプ、データを指します。 移行では、ファイルの忠実性は、ソース (StorSimple ボリューム) に関する情報をターゲット Azure ファイル共有にどれだけ適切に変換 (移行) できるかの尺度です。

NTFS ファイルのプロパティのサブセットが Azure Files ではサポートされています。 Windows ACL、一般的なメタデータのほか、一部のタイムスタンプが移行されます。

次の項目は、移行を妨げることはありませんが、移行の間に項目ごとの問題が発生します。

  • タイムスタンプ: ファイルの変更時刻が設定されません。 これは現在、REST プロトコル経由では読み取り専用です。 ファイル上の最終アクセス タイムスタンプは、Azure ファイル共有に格納されているファイルでサポートされる属性ではないため移行されません。
  • 代替データ ストリームを Azure ファイル共有に格納することはできません。 代替データ ストリームを保持しているファイルはコピーされますが、代替データ ストリームはプロセスでファイルから除去されます。
  • シンボリック リンク、ハード リンク、ジャンクション、再解析ポイントは、移行の間にスキップされます。 移行コピー ログには、スキップされた各項目と理由が示されます。
  • EFS で暗号化されたファイルはコピーに失敗します。 コピー ログには、その項目が "アクセスが拒否されました" でコピーに失敗したことが示されます。
  • 破損したファイルはスキップされます。 コピー ログには、"デバイスで重大なハードウェア エラーが発生したため、要求が失敗しました"、"ファイルまたはディレクトリが破損しているか、読み取れません"、"アクセス制御リスト (ACL) の構造が無効です" など、StorSimple ディスクで破損している項目ごとに異なるエラーが示されることがあります。
  • 個別のファイルで 4 TiB を超えるものはスキップされます。
  • ファイル パスの長さは、2,048 文字以下でなければなりません。 これより長いパスを持つファイルやフォルダーはスキップされます。
  • 再解析ポイントはスキップされます。 Microsoft データ重複除去/SIS 再解析ポイントまたはサード パーティのこれらのものはすべて、移行エンジンで解決できないため、影響を受けるファイルやフォルダーの移行が妨げられます。

この記事の最後にある「トラブルシューティング」セクションでは、項目レベルと移行ジョブ レベルのエラー コードと、可能な場合は軽減オプションについて詳しく説明します。

StorSimple ボリュームのバックアップ

StorSimple により、ボリューム レベルでの差分バックアップが提供されます。 Azure ファイル共有にもこの機能があり、共有スナップショットと呼ばれます。

移行ジョブで移動できるのはバックアップだけであり、ライブ ボリュームからのデータはできません。 したがって、ライブ データに最も近いのは最新のバックアップなので、移行で移動されるバックアップのリストに常にそれを含める必要があります。

移行の間に古いバックアップを移動する必要があるかどうかを判断します。 移行ジョブがより速く完了するように、この一覧をできるだけ小さくしておくことをお勧めします。

移行する必要がある重要なバックアップを特定するには、バックアップ ポリシーのチェックリストを作成します。 次に例を示します。

  • 最新のバックアップ。
  • 12 か月分の月次バックアップ。
  • 3 年分の年次バックアップ。

移行ジョブを作成するときは、この一覧を使用して、要件を満たすために移行する必要のある正確な StorSimple ボリューム バックアップを識別できます。

移行するバックアップを選択する前に、すべての StorSimple バックアップ保持ポリシーを中断することをお勧めします。 バックアップの移行には数日または数週間かかる場合があります。 StorSimple には、バックアップを削除するバックアップ保持ポリシーが用意されています。 この移行のために選択したバックアップは、移行される機会が得られる前に削除される可能性があります。

注意事項

50 を超える StorSimple ボリューム バックアップの選択はサポートされていません。

既存の StorSimple ボリュームを 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 ファイルをダウンロードして、マッピングの作成に役立つテンプレートとして使用します。


ダウンロードのコンテキストを設定する Excel アイコン。 名前空間マッピング テンプレートをダウンロードします。

ストレージ アカウントの数

移行では、それぞれがより少数の Azure ファイル共有を保持する複数のストレージ アカウントをデプロイすると、利点が得られる可能性があります。

ファイル共有が非常にアクティブである (多くのユーザーやアプリケーションによって使用されている) 場合、2 つの Azure ファイル共有でストレージ アカウントのパフォーマンス制限に達する可能性があります。 このため、多くの場合は、それぞれに独自の個別のファイル共有があるが、通常はストレージ アカウントあたりの共有の数がせいぜい 2 または 3 である複数のストレージ アカウントに移行する方が適切です。 ベスト プラクティスは、それぞれ 1 つのファイル共有を持つストレージ アカウントをデプロイすることです。 アーカイブできる共有がある場合は、複数の Azure ファイル共有を同じストレージ アカウントにプールすることができます。

これらの考慮事項は、Azure File Sync の場合より、(Azure VM またはサービス経由での) クラウドへの直接アクセスの場合に、よりいっそう適用されます。これらの共有で Azure File Sync だけを使用する場合は、いくつかを 1 つの Azure ストレージ アカウントにグループ化するのが適切です。 将来的には、ファイル共有に直接アクセスするクラウドにアプリをリフト アンド シフトすることが必要になる場合があります。このシナリオには、IOPS とスループットが高いという利点があるためです。 または、IOPS とスループットをより高くするとメリットのある Azure のサービスの使用を始めることもできます。

共有の一覧を作成した後、各共有を、それが配置されるストレージ アカウントにマップします。 Azure リージョンを決定し、各ストレージ アカウントと Azure File Sync リソースが選択したリージョンと一致するようにします。

重要

ここでは、ストレージ アカウントのネットワークとファイアウォールの設定を構成しないでください。 この時点でこれらの構成を行うと、移行が不可能になります。 これらの Azure Storage の設定は、移行が完了した後で構成します。

Storage アカウントの設定

ストレージ アカウントには多くの構成を行います。 ストレージ アカウントの構成を確認するには、次のチェックリストを使用します。 移行が完了したら、ネットワーク構成を変更できます。

  • 大きなファイル共有: 有効 - 大きなファイル共有によってパフォーマンスが向上し、最大 100 TiB を共有に格納できるようになります。 この設定は、Azure ファイル共有を持つターゲット ストレージ アカウントに適用されます。
  • ファイアウォールと仮想ネットワーク: 無効 - 何らかの IP 制限を構成したり、ストレージ アカウントのアクセスを特定の仮想ネットワークに制限したりしないでください。 ストレージ アカウントのパブリック エンドポイントは、移行中に使用されます。 Azure VM からのすべての IP アドレスを許可する必要があります。 移行後は、ストレージ アカウントでファイアウォール規則を構成するのが最善です。 ソースおよびターゲット ストレージ アカウントの両方をこの方法で構成します。
  • プライベート エンドポイント: サポート対象 - プライベート エンドポイントを有効にできますが、移行にはパブリック エンドポイントが使用されるため、これを使用可能のままにする必要があります。 これは、ソースおよびターゲット ストレージ アカウントの両方に適用されます。

フェーズ 1 の概要

「Phase 1:

  • StorSimple のデバイスとボリュームの概要を理解しました。
  • StorSimple デバイスごとのサービス データ暗号化キーを取得しているため、Data Manager サービスは、クラウド内の StorSimple ボリュームにアクセスする準備ができています。
  • 移行する必要があるボリュームとバックアップ (最新のもの以外の場合) についての計画があります。
  • ボリュームを適切な数の Azure ファイル共有およびストレージ アカウントにマップする方法がわかっています。

フェーズ 2:Azure Storage と移行リソースをデプロイする

このセクションでは、Azure で必要なさまざまなリソースの種類のデプロイに関する考慮事項について説明します。 一部は移行後にデータを保持し、一部は移行にだけ必要です。 デプロイ計画が完成するまで、リソースのデプロイを始めないでください。 デプロイした後で Azure リソースの特定の側面を変更することは困難です (場合によっては不可能です)。

必要なリソースをデプロイする - クリックして再生します。

このビデオでは、次の展開について説明します。

  • ストレージ アカウント
  • サブスクリプションとリソース グループ
  • ストレージ アカウント
  • 型と名前
  • パフォーマンスと共有サイズ
  • 場所とレプリケーションの種類
  • Azure ファイル共有
  • StorSimple Data Manager Service

ストレージ アカウントをデプロイする

多くの場合、複数の Azure ストレージ アカウントをデプロイする必要があります。 デプロイ計画に従って、それぞれがより少数の Azure ファイル共有を保持します。 Azure portal で計画したストレージ アカウントをデプロイします。 新しいストレージ アカウントについては、次の基本的な設定に従って検討してください。

重要

まだ、ストレージ アカウントのネットワークとファイアウォールの設定を構成しないでください。 この時点でそれらの構成を行うと、移行が不可能になります。 これらの Azure Storage の設定は、移行が完了した後で構成します。

サブスクリプション

StorSimple のデプロイに使用したのと同じサブスクリプションを使用するか、または別のサブスクリプションを使用できます。 唯一の制限は、サブスクリプションが StorSimple サブスクリプションと同じ Microsoft Entra テナントに存在する必要があることです。 移行を始める前に、StorSimple サブスクリプションを適切なテナントに移動することを検討してください。 個々の StorSimple リソースを別のテナントまたはサブスクリプションに移動することはできず、サブスクリプション全体を移動することしかできません。

リソース グループ

Azure 内のリソース グループは、リソースや管理者の管理アクセス許可の構成に役立ちます。 詳細はこちら。

ストレージ アカウント名

ストレージ アカウントの名前は、ファイル共有にアクセスするために使用される URL の一部になり、特定の文字制限があります。 その名前付け規則では、ストレージ アカウント名が世界中で一意である必要があり、小文字と数字のみが許可され、3 - 24 の文字数である必要があり、ハイフンやアンダースコアなどの特殊文字は許可されないことを考慮してください。 Azure ストレージ リソースの名前付け規則に関するページを参照してください。

場所

ストレージ アカウントの Azure リージョンは重要です。 Azure File Sync を使用する場合は、すべてのストレージ アカウントがストレージ同期サービス リソースと同じリージョンに存在する必要があります。 選択する Azure リージョンは、ローカル サーバーやユーザーの近くにあるか、中央にある必要があります。 リソースをデプロイした後に、そのリージョンを変更することはできません。

現在 StorSimple データ (ストレージ アカウント) が存在するのとは別のリージョンを選択することはできますが、それを行うと、移行中にエグレス料金が適用されます。 データは StorSimple のリージョンから出て、新しいストレージ アカウントのリージョンに入ります。 同じ Azure リージョン内にある場合は、帯域幅の料金はかかりません。

パフォーマンス

Azure ファイル共有には、Premium Storage (SSD) または Standard Storage を選択できます。 Standard Storage には、ファイル共有用の複数の階層が含まれています。 StorSimple から移行するほとんどのお客様には、Standard Storage が適切なオプションです。

  • Premium Azure ファイル共有のパフォーマンスを必要とする場合は、Premium Storage を選択します。
  • ホット データやアーカイブ データなど、汎用的なファイル サーバーのワークロードには、Standard Storage を選択します。 また、クラウド内の共有上のワークロードが Azure File Sync だけである場合も、Standard Storage を選択します。
  • Premium ファイル共有の場合は、ストレージ アカウントの作成ウィザードで [ファイル共有] を選択します。

レプリケーション

いくつかのレプリケーション設定を使用できます。 次の 2 つのオプションからのみ選択してください。

  • ローカル冗長ストレージ (LRS) 。
  • "ゾーン冗長ストレージ (ZRS) " は、すべての Azure リージョンで使用できるわけではありません。

Note

geo 冗長ストレージ (GRS) と geo ゾーン冗長ストレージはサポートされていません。

100 TiB のファイル共有を有効にする

ストレージ アカウントを作成するための Azure portal の [詳細設定] タブを示す画像。

Azure portal の新しいストレージ アカウント ウィザードの [詳細] セクションで、このストレージ アカウントでの [大きいファイルの共有] のサポートを有効にすることができます。 このオプションが使用できない場合は、間違った冗長性の種類を選択した可能性があります。 このオプションを使用できるようにするには、LRS または ZRS だけを選択してください。

大きなファイル共有の使用には、次のいくつかの利点があります。

  • より小さな 5 TiB のファイル共有と比較してパフォーマンスが大幅に向上します (10 倍の IOPS など)。
  • 移行がより速く完了します。
  • ファイル共有に、そこに移行するすべてのデータを保持するための十分な容量 (差分バックアップに必要なストレージ容量を含む) があることが確認されます。
  • 将来の拡張に対応できます。

重要

移行前または移行中に、ストレージ アカウントに特殊なネットワークを適用しないでください。 パブリック エンドポイントには、ソースとターゲットのストレージ アカウントでアクセスできる必要があります。 特定の IP 範囲または仮想ネットワークに制限することはサポートされていません。 移行後にストレージ アカウントのネットワーク構成を変更できます。

Azure ファイル共有

ストレージ アカウントを作成したら、ストレージ アカウントの [ファイル共有] セクションに移動し、フェーズ 1 の移行計画に従って適切な数の Azure ファイル共有をデプロイします。 Azure での新しいファイル共有については、次の基本的な設定に従って検討してください。

新しいファイル共有の UI を示す Azure portal のスクリーンショット。




小文字、数字、ハイフンがサポートされています。



ここでのクォータは、Windows Server インスタンスでの SMB ハード クォータに相当します。 ベスト プラクティスとして、ここではクォータを設定しないでください。クォータに達すると、移行や他のサービスが失敗します。



新しいファイル共有に対して
を選択します。 移行の間に、多くのトランザクションが発生します。 後でワークロードに最適な層に変更する方が、コスト効率がよくなります。

StorSimple Data Manager

移行ジョブを保持する Azure リソースは、StorSimple Data Manager と呼ばれます。 [新しいリソース] を選択して、それを検索します。 [作成] を選択します。

この一時的なリソースは、オーケストレーションに使用されます。 移行が完了した後でプロビジョニングを解除します。 それを必ず StorSimple ストレージ アカウントと同じサブスクリプション、リソース グループ、リージョンにデプロイしてください。

Azure File Sync

Azure File Sync を使用すると、最も頻繁にアクセスされるファイルのオンプレミス キャッシュを追加できます。 StorSimple のキャッシュ機能と同様に、Azure File Sync のクラウドを使った階層化機能を使用すると、Windows Server インスタンスとマルチサイトの同期で使用可能なキャッシュ容量に対する制御の強化との組み合わせで、ローカル アクセスの待機時間が向上します。オンプレミスのキャッシュを使用することが目的である場合は、ローカル ネットワークに十分な直接接続ストレージ容量を備えた Windows Server VM を準備します (物理サーバーとフェールオーバー クラスターもサポートされます)。

重要

Azure File Sync はまだ設定しないでください。 移行のフェーズ 4 より前に、Azure File Sync のデプロイを始めないでください。

フェーズ 2 の概要

フェーズ 2 が終了すると、ストレージ アカウントとすべての Azure ファイル共有がデプロイされています。 また、StorSimple Data Manager リソースも作成されています。 フェーズ 3 で移行ジョブを構成するとき、後者を使用します。

フェーズ 3: 移行ジョブを作成して実行する

このセクションでは、移行ジョブを設定し、選択したターゲット Azure ファイル共有にコピーする必要のある StorSimple ボリューム上のディレクトリをマップする方法について説明します。

移行ジョブを作成して実行する - クリックして再生します。

このビデオの内容は次のとおりです。

  • 移行ジョブを作成する
  • まとめ
  • ソース
  • 移行するボリューム バックアップの選択
  • 移行先
  • ディレクトリのマッピング
  • セマンティックのルール
  • 移行ジョブを実行する
  • ジョブ定義を実行
  • ジョブの状態を見る
  • ジョブを並列で実行する
  • ログ ファイルを解釈する

作業を始めるには、StorSimple Data Manager に移動し、メニューで [ジョブ定義] を見つけて、 [+ ジョブ定義] を選択します。 正しいターゲット ストレージの種類は既定値です: [Azure ファイル共有] 。

StorSimple 8000 シリーズの移行ジョブの種類。

移行ジョブの新しいジョブ作成フォームのスクリーンショット。

ジョブ定義名この名前は、移動しているファイルのセットを示すものである必要があります。 Azure ファイル共有に似た名前を付けることをお勧めします。



リージョンを選択するときは、StorSimple のストレージ アカウントと同じリージョンを選択する必要があります。または、利用できない場合は、それに近いリージョンを選択します。

source

ソース サブスクリプション
StorSimple デバイス マネージャー リソースを格納するサブスクリプションを選択します。



アプライアンスが登録されている StorSimple デバイス マネージャーを選択します。




を確認してください。



移行するボリュームが保持されている StorSimple デバイスを選択します。



ソース ボリュームを選択します。 後で、ボリューム全体またはサブディレクトリをターゲットの Azure ファイル共有に移行するかどうかを決定します。

ボリューム バックアップ
[Select volume backups] (ボリューム バックアップの選択) を選択して、このジョブの一部として移動する特定のバックアップを選択できます。 詳細なプロセスについては、後のこの記事の専用セクションを参照してください。

Target

この移行ジョブのターゲットとして、サブスクリプション、ストレージ アカウント、Azure ファイル共有を選択します。

ディレクトリのマッピング

関連するすべての詳細は、この記事の専用セクションで説明します。

移行するボリューム バックアップの選択

移行する必要があるバックアップの選択には、次の重要な側面があります。

  • 移行ジョブで移動できるのはバックアップだけであり、ライブ ボリュームのデータはできません。 そのため、ライブ データに最も近いのは最新のバックアップなので、移行で移動されるバックアップのリストに常にそれを含める必要があります。 [バックアップの選択] ダイアログを開くと、それが既定で選択されています。
  • ライブ共有への差分ができるだけ小さくなるように、最新のバックアップが最近のものであることを確認します。 移行ジョブを作成する前に、別のボリューム バックアップを手動でトリガーして完了することをお勧めします。 ライブ共有への小さな差分によって移行エクスペリエンスが向上します。 この差分を 0 にできる、つまり、最新のバックアップが一覧に取得された後に StorSimple ボリュームへのそれ以上の変更が発生しなかった場合は、ユーザーのカットオーバーが大幅に簡略化および高速化されます。
  • バックアップを、古いものから最新のものまで、Azure ファイル共有に対して再生する必要があります。 移行ジョブを実行した後に、以前のバックアップを Azure ファイル共有上のバックアップの一覧 "に並べ替える" ことはできません。 そのため、ジョブを作成する "前に"、バックアップのリストが完全であることを確認する必要があります。
  • ジョブ内のこのバックアップの一覧は、そのジョブが実行されなかった場合でも、ジョブが作成された後には変更できません。
  • バックアップを選択するには、移行する StorSimple ボリュームがオンラインである必要があります。

StorSimple バックアップが移行に選択されている部分を詳述した新しいジョブ作成フォームのスクリーンショット。

移行ジョブに StorSimple ボリュームのバックアップを選択するには、ジョブ作成フォームで [Select volume backups](ボリューム バックアップの選択) を選択します。

バックアップ選択ブレードの上半分に、使用可能なすべてのバックアップの一覧が表示されている画像。選択されたバックアップはこの一覧で淡色表示され、ブレードの下半分にある 2 番目の一覧に追加されます。もう一度削除することもできます。

[バックアップの選択] ブレードが開くと、それが 2 つの一覧に分けられています。 最初のリストには、利用可能なすべてのバックアップが表示されます。 特定の時間範囲でフィルター処理することにより、結果セットを広げたり狭めたりできます。 (次のセクションを参照)

選択されたバックアップは淡色表示され、ブレードの下半分にある 2 番目の一覧に追加されます。 2 番目のリストには、移行用に選択されたすべてのバックアップが表示されます。 誤って選択したバックアップは再度削除することもできます。

注意事項

移行するバックアップを "すべて" 選択する必要があります。 後で以前のバックアップを追加することはできません。 ジョブが作成された後に、ジョブを変更して選択内容を変更することはできません。

バックアップ選択ブレードの時間範囲の選択を示すスクリーンショット。

既定では、この一覧はフィルター処理されており、過去 7 日以内の StorSimple ボリュームのバックアップが表示されます。 過去 7 日以内に行われなかった場合でも、最新のバックアップが既定で選択されます。 古いバックアップの場合は、ブレードの上部にある時間範囲フィルターを使用します。 既存のフィルターから選択するか、またはカスタム時間範囲を設定して、この期間内に作成されたバックアップのみにフィルター処理できます。

注意事項

50 を超える StorSimple ボリューム バックアップの選択はサポートされていません。 バックアップの数が多いジョブは失敗するおそれがあります。 選択したバックアップが移行される前に、バックアップ保有ポリシーによって削除されていないことを確認してください。

ディレクトリのマッピング

ディレクトリのマッピングは、移行ジョブでは省略可能です。 セクションを空のままにすると、StorSimple ボリュームのルートにある "すべての" ファイルとフォルダーが、ターゲットの Azure ファイル共有のルートに移動されます。 ほとんどの場合、ボリュームの内容全体を 1 つの Azure ファイル共有に格納することは、最適な方法ではありません。 多くの場合、Azure の複数のファイル共有にボリュームの内容を分割することをお勧めします。 プランをまだ作成していない場合は、最初に「既存の StorSimple ボリュームを Azure ファイル共有にマップする」を参照してください。

移行計画の一環として、StorSimple ボリューム上のフォルダーを複数の Azure ファイル共有に分割する必要があると決定している場合があります。 その場合は、次のように分割することができます。

  1. 1 つのボリューム上のフォルダーを移行するために、複数のジョブを定義します。 それぞれの StorSimple ボリューム ソースは同じですが、ターゲットとしての Azure ファイル共有は異なります。
  2. ジョブ作成フォームの「ディレクトリ マッピング」セクションを使用し、特定のマッピング セマンティクスに従って、StorSimple ボリュームのフォルダーを指定したファイル共有に移行する必要があることを正確に指定します。

重要

このフォームのパスとマッピング式を、フォームの送信時に検証することはできません。 マッピングが正しく指定されていない場合、ジョブは完全に失敗するか、望ましくない結果を生成する可能性があります。 その場合は、通常、Azure ファイル共有を削除して再作成してから、その共有に対する新しい移行ジョブでマッピングのステートメントを修正するのが最善の方法です。 修正したマッピングのステートメントを使用して新しいジョブを実行すると、省略されたフォルダーを修正し、既存の共有に移動できます。 ただし、この方法で対処できるのは、パスのスペルミスのために省略されたフォルダーのみです。

セマンティックの要素

マッピングは左から右に表記されます: [\ソースパス] > [\ターゲットパス]。

セマンティックの文字 意味
\ ルート レベル インジケーター。
> [ソース] と [ターゲット マッピング] の演算子。
| または RETURN (改行) 2 つのフォルダー マッピング命令の区切り記号。
または、この文字を省略し、
キーを押して、次のマッピング式を独自の行に作成することもできます。

例

フォルダー User data の内容を、ターゲット ファイル共有のルートに移動します。

\User data > \

ボリュームの内容全体を、ターゲット ファイル共有の新しいパスに移動します。

\ > \Apps\HR tracker

ソース フォルダーの内容を、ターゲット ファイル共有の新しいパスに移動します。

\HR resumes-Backup > \Backups\HR\resumes

複数のソースの場所を、新しいディレクトリ構造に並べ替えます。

\HR\Candidate Tracker\v1.0 > \Apps\Candidate tracker
\HR\Candidates\Resumes > \HR\Candidates\New
\Archive\HR\Old Resumes > \HR\Candidates\Archived

セマンティックのルール

  • フォルダーのパスは、常にルート レベルを基準にして指定します。
  • 各フォルダーのパスは、ルート レベル インジケーター "\" で開始します。
  • ドライブ文字は含めません。
  • 複数のパスを指定するとき、ソースまたはターゲットのパスを重複することはできません。:
    無効なソース パスの重複の例:




    無効なターゲット パスの重複の例:
    >


  • 存在しないソース フォルダーは無視されます。
  • ターゲットに存在しないフォルダー構造は作成されます。
  • Windows と同様に、フォルダー名は大文字と小文字が区別されませんが、大文字と小文字は維持されます。

Note

StorSimple ボリュームの \System Volume Information フォルダーと $Recycle.Bin の内容は、移行ジョブによってコピーされません。

移行ジョブを実行する

移行ジョブは、リソース グループにデプロイした Data Manager リソースの [ジョブ定義] の下に一覧表示されます。 ジョブ定義の一覧から、実行するジョブを選択します。

開かれたジョブ ブレードで、ジョブの現在の状態と、選択したバックアップの一覧を確認できます。 バックアップの一覧は、最も古いものから順に並べられており、この順序で Azure ファイル共有に移行されます。

ジョブを開始するためのコマンドが強調されている移行ジョブ ブレードのスクリーンショット。また、移行のスケジュール対象に選択されたバックアップも表示されます。

移行ジョブの最初の状態は [Never ran](未実行) です。
準備ができたら、移行ジョブを開始します。 解像度が高い方のバージョンのイメージを選択します。
バックアップが正常に移行されると、Azure ファイル共有スナップショットが自動的に取得されます。 StorSimple バックアップの元のバックアップ日付が Azure ファイル共有スナップショットの [コメント] セクションに配置されます。 このフィールドを利用すると、データが最初にバックアップされた日時をファイル共有スナップショットが取得された日時と比較して確認できます。

注意事項

バックアップは、最も古いものから順に処理する必要があります。 移行ジョブが作成されたら、選択した StorSimple ボリューム バックアップの一覧を変更することはできません。 バックアップの一覧が正しくないか、不完全である場合は、ジョブを開始しないでください。 ジョブを削除し、正しいバックアップを選択して新しいジョブを作成します。 選択したバックアップごとに、保有期間のスケジュールを確認します。 バックアップは、移行される機会が得られる前に、1 つ以上の保持ポリシーによって削除される可能性があります。

項目ごとのエラー

移行ジョブのバックアップの一覧には、コピー中に発生した可能性のあるすべての問題を一覧表示する 2 つの列があります。

  • コピー エラー
    この列には、コピーされる必要があったがコピーされなかったファイルまたはフォルダーの一覧が表示されます。 多くの場合、これらのエラーは復旧できます。 バックアップでこの列に項目の問題が一覧表示される場合は、コピー ログを確認してください。 これらのファイルを移行する必要がある場合は、 [Retry backup](バックアップの再試行) を選びます。 このオプションは、バックアップの処理が完了すると使用できるようになります。 オプションについては、「移行ジョブを管理する」セクションで詳しく説明します。
  • サポートされていないファイル
    この列には、移行できないファイルまたはフォルダーの一覧が表示されます。 Azure Storage には、ファイル名、パスの長さ、および現在または論理的に Azure ファイル共有に格納できないファイルの種類の制限があります。 この種のエラーがあっても、移行ジョブは一時停止しません。 バックアップの移行を再試行しても結果は変わりません。 バックアップでこの列に項目の問題が一覧表示される場合は、コピー ログを確認して記録を残してください。 このような問題が前回のバックアップで発生し、コピー ログでこのエラーの原因がファイル名、パスの長さ、または影響を受けているその他の問題であったことがわかった場合は、ライブ StorSimple ボリュームで問題を解決し、StorSimple ボリューム バックアップを取得して、そのバックアップだけで新しい移行ジョブを作成することもできます。 その後に、この解決された名前空間を移行できます。それが Azure ファイル共有の最新またはライブ バージョンになります。 これは、手動で時間のかかるプロセスです。 コピー ログを慎重に確認し、その価値があるかどうかを評価します。

これらのコピー ログは *.csv ファイルで、コピーに成功した名前空間項目と失敗した項目の一覧が示されています。 エラーは、前に説明したカテゴリにさらに分割されます。 ログ ファイルの場所で "failed" を検索することで、失敗したファイルのログを見つけることができます。 結果は、コピーに失敗したファイルのログのセットです。 これらのログをサイズで並べ替えます。 サイズが 17 バイトになると、追加のログが生成されることがあります。 これらは空であり、無視することができます。 並べ替えると、内容が含まれるログに注目できます。

成功したコピーを記録するログファイルにも同じ処理が適用されます。

移行ジョブを管理する

移行ジョブには次の状態があります。

  • [未実行]
    定義されているが、まだ実行されていない新しいジョブ。
  • 待機中
    この状態のジョブは、移行サービスでリソースがプロビジョニングされるのを待機しています。 準備ができると、自動的に別の状態に切り替わります。
  • 失敗
    失敗したジョブで致命的エラーが発生し、それ以上多くのバックアップを処理できません。 ジョブがこの状態になることは想定されていません。 サポート リクエストが最善の措置です。
  • キャンセル済み / キャンセル中
    移行ジョブ全体またはジョブ内の個々のバックアップをキャンセルすることができます。 キャンセルされた移行ジョブはバックアップの処理を停止するため、キャンセルされたバックアップは処理されません。 ジョブの取り消しには長い時間がかかることを想定してください。 その場合、新しいジョブを作成できなくなることはありません。 最適な対処方法は、ジョブが完全に [キャンセル済み] 状態になるまで待つことです。 失敗したジョブまたはキャンセルされたジョブは無視することも、後で削除することもできます。 StorSimple の移行が終わって Data Manager リソースを削除できるようになる前に、ジョブを削除する必要はありません。

実行中状態の大きな状態アイコンが上部に表示されている移行ジョブ ブレードのスクリーンショット。

実行中

実行中のジョブは、現在、バックアップを処理しています。 ブレードの下半分にあるテーブルを参照して、現在処理されているバックアップと、既に移行された可能性があるバックアップを確認します。
既に移行されたバックアップには、コピー ログへのリンクを含む列があります。 バックアップで何からのエラーが報告された場合は、そのコピー ログを確認する必要があります。

一時停止状態の大きな状態アイコンが上部に表示されている移行ジョブ ブレードのスクリーンショット。

一時停止

移行ジョブは、決定が必要なときは一時停止されます。 この状態では、ブレード上部の 2 つのコマンド ボタンが有効になります。
移動されるはずのファイルが移動されなかったことがバックアップで示されている場合は ([Copy error](コピー エラー) 列)、
を選びます。
バックアップが見つからない場合 (移行ジョブを作成した後でポリシーによって削除された)、またはバックアップが破損している場合は、
を選びます。 失敗したバックアップをクリックすると開くブレードで、詳細なエラー情報を確認できます。

現在のバックアップを "
" または "
" すると、移行サービスによってターゲットの Azure ファイル共有に新しいスナップショットが作成されます。 前のものは、不完全である可能性があるため、後で削除することもできます。

完了状態の大きな状態アイコンが上部に表示されている移行ジョブ ブレードを示す画像。

[Complete](完了) と [Complete with warnings](完了 (警告あり)\

ジョブのすべてのバックアップが正常に処理されると、移行ジョブは [Complete](完了) と表示されます。
完了 (警告あり) は、次の場合に発生する状態です。

  • バックアップで回復可能な問題が発生しました。 このようなバックアップは、"部分的成功" または "失敗" とマークされます。
  • ユーザーが、示された問題を含むバックアップをスキップすることで、一時停止中のジョブを続行することを決定しました。 (ユーザーが [Retry backup](バックアップの再試行) ではなく [Skip backup](バックアップのスキップ) を選択しました)
移行ジョブが警告ありで完了した場合は、常に、関連するバックアップのコピー ログを確認する必要があります。

ジョブを並列実行する

それぞれに Azure ファイル共有に移行する必要のある独自の共有がある複数の StorSimple ボリュームが存在する可能性があります。 並列で実行できる範囲を理解しておくことが重要です。 複数のジョブを同時に実行する場合、ユーザー エクスペリエンスでは適用されない制限があり、完全な移行が機能低下したり、抑制されたりします。

移行ジョブの定義では制限はありません。 同じ、または異なる StorSimple アプライアンスで、同じ StorSimple ソース ボリュームと同じ Azure ファイル共有を定義できます。 ただし、それらの実行には次の制限があります。

  • ソースの StorSimple ボリュームが同じ移行ジョブを、同時に複数実行することはできません。
  • ターゲットの Azure ファイル共有が同じ移行ジョブを、同時に複数実行することはできません。
  • 次のジョブを開始する前に、前のジョブのいずれかが copy stage にあり、ファイルの移動の進行状況を少なくとも 30 分間表示していることを確認してください。
  • 前の規則に従っている限り、StorSimple デバイス マネージャーあたり最大 4 つの移行ジョブを並列に実行できます。

移行ジョブを開始しようとすると、前の規則がチェックされます。 実行中のジョブがある場合は、新しいジョブを開始できない可能性があります。 現在実行中のジョブのうち、それが完了してからでないと新しいジョブを開始できないものの名前の一覧を含むアラートを受け取ります。

ヒント

Data Manager リソースの [ジョブ定義] タブで移行ジョブを定期的にチェックして、そのいずれかが一時停止され、完了のためにユーザーの入力を必要としていないかどうかを確認することをお勧めします。

フェーズ 3 のまとめ

フェーズ 3 が終了すると、StorSimple ボリュームから Azure ファイル共有への少なくとも 1 つの移行ジョブが実行されています。 実行により、指定したバックアップが Azure ファイル共有のスナップショットに移行されます。 共有のための Azure File Sync の設定 (共有への移行ジョブが完了した後) またはインフォメーション ワーカーとアプリのための Azure ファイル共有への直接共有アクセスの設定に集中できるようになります。

フェーズ 4: Azure ファイル共有にアクセスする

Azure ファイル共有へのアクセスには、主に次の 2 つの方法があります。

  • Azure File Sync:オンプレミスの Windows Server インスタンスに Azure File Sync をデプロイします。 Azure File Sync には、StorSimple と同様に、ローカル キャッシュのすべての利点があります。
  • 直接共有アクセス: 直接共有アクセスをデプロイします。 この戦略は、特定の Azure ファイル共有へのアクセス シナリオでローカル キャッシュの利点が得られない場合、またはオンプレミスの Windows Server インスタンスをホストできなくなった場合に使用します。 この場合、ユーザーとアプリは引き続き SMB プロトコルを使用して SMB 共有にアクセスします。 これらの共有はオンプレミスのサーバー上にはなくなっており、クラウドのものを直接使用します。

このガイドの「フェーズ 1」で、どのオプションが最適であるかを既に決定しておく必要があります。

このセクションの残りの部分では、デプロイの手順について説明します。

Azure ファイル共有のアクセス オプション - クリックして再生します。

このビデオの内容は次のとおりです。

  • Azure ファイル共有にアクセスする方法
  • Azure File Sync
  • 直接共有アクセス
  • Azure File Sync のデプロイ方法
  • Azure File Sync クラウド リソースをデプロイする
  • オンプレミスの Windows Server インスタンスをデプロイする
  • Azure File Sync のための Windows Server インスタンスの準備
  • Windows Server インスタンスで Azure File Sync を構成する
  • 初期同期を監視する
  • Azure File Sync をテストする
  • SMB 共有を作成する

Azure File Sync のデプロイ

ここでは、Azure File Sync の一部をデプロイします。

  1. Azure File Sync クラウド リソースを作成します。
  2. オンプレミス サーバーに Azure File Sync エージェントをデプロイします。
  3. クラウド リソースにサーバーを登録します。

同期グループはまだ作成しないでください。 Azure ファイル共有での同期の設定は、Azure ファイル共有への移行ジョブが完了した後でのみ行う必要があります。 移行が完了する前に Azure File Sync の使用を開始する場合は、カットオーバーをいつ開始できたかを簡単に識別できなくなるため、移行が不必要に困難になります。

Azure File Sync クラウド リソースをデプロイする

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

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

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

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

ヒント

移行が完了した後でデータが存在する Azure リージョンを変更する場合は、この移行のターゲット ストレージ アカウントと同じリージョンに、ストレージ同期サービスをデプロイします。

オンプレミスの Windows Server インスタンスをデプロイする

  • 仮想マシンまたは物理サーバーとして、Windows Server 2019 (最低でも 2012R2) のサーバーを作成します。 また、Windows Server フェールオーバー クラスターもサポートされています。 StorSimple 8100 または 8600 の前面にあるサーバーを再利用しないでください。
  • 直接接続ストレージをプロビジョニングまたは追加します。 ネットワーク接続ストレージはサポートされていません。

StorSimple 8100 または 8600 アプライアンスがローカルでキャッシュに使用できる容量以上のストレージを新しい Windows Server インスタンスに用意することをお勧めします。 StorSimple アプライアンスを使用したときと同じ方法で、Windows Server インスタンスを使用します。 アプライアンスと同じ容量のストレージがある場合、キャッシュ エクスペリエンスは同じでなくても似ているはずです。 Windows Server インスタンスのストレージは、いつでも追加または削除できます。 この機能により、ローカル ボリューム サイズとキャッシュに使用できるローカル ストレージの容量をスケールできます。

ファイル同期のために Windows Server インスタンスを準備する

このセクションでは、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 のストレージ同期サービス リソースに移動します。 左側のメニューで、 [登録済みサーバー] に移動します。 ご利用のサーバーがそこに一覧表示されます。

Windows Server インスタンスで Azure File Sync を構成する

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

重要

作業を続ける前に、ファイルとフォルダーの Azure ファイル共有への StorSimple 移行が完了している必要があります。 ファイル共有への変更がそれ以上行われないことを確認します。

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

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

重要

クラウドを使った階層化を必ず有効にしておきます。 クラウドを使った階層化は、ローカル サーバーが、クラウドに格納されているよりもストレージ容量が少なくても、完全な名前空間を使用できるようにする Azure File Sync 機能です。 また、高速なパフォーマンスのために、ローカルで関心を持たれているデータもローカルにキャッシュされます。 このステップでクラウドを使った階層化を有効にするもう 1 つの理由は、このステージではファイルの内容を同期したくないためです。 この時点では、名前空間のみを移動する必要があります。

直接共有アクセスをデプロイする

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

フェーズ 4 のまとめ

このフェーズの終わりには、StorSimple Data Manager で複数の移行ジョブを作成して実行しました。 それらのジョブによって、ファイルとフォルダーおよびそれらのバックアップが、Azure ファイル共有に移行されました。 また、Azure File Sync をデプロイするか、直接共有アクセスのためのネットワークとストレージ アカウントを準備しました。

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

このフェーズでは、移行を完了します。

  • ダウンタイムを計画します。
  • フェーズ 3 の移行ジョブが実行されている間に、StorSimple 側で生成されたユーザーとアプリのすべての変更をキャッチアップします。
  • Azure File Sync または直接共有アクセスによる Azure ファイル共有を使用して、ユーザーを新しい Windows Server インスタンスにフェールオーバーします。

ワークロードを Azure ファイル共有にカット オーバーする手順 - クリックして再生します。

このビデオの内容は次のとおりです。

  • ワークロードのカットオーバーの前に実行する手順
  • カットオーバーを実行する
  • カットオーバー後の手順

ダウンタイムを計画する

この移行アプローチを使用すると、ユーザーとアプリに若干のダウンタイムが発生します。 目標は、ダウンタイムを最小限に抑えることです。 次の考慮事項が役に立つ場合があります。

  • 移行ジョブの実行中に、StorSimple ボリュームを使用可能な状態に保ちます。
  • 共有へのデータ移行ジョブの実行が完了したら、StorSimple ボリュームと共有からユーザー アクセス (少なくとも書き込みアクセス) を削除します。 最後の RoboCopy により Azure ファイル共有がキャッチアップされます。 その後、ユーザーをカットオーバーできます。 どこで RoboCopy を実行するかは、Azure File Sync または直接共有アクセスのどちらの使用を選択したかによって異なります。 そのことについては、後のセクションで説明します。
  • RoboCopy のキャッチアップを完了すると、Azure ファイル共有で直接、または Azure File Sync を使用して Windows Server インスタンス上の SMB 共有で、新しい場所をユーザーに公開できる状態になります。多くの場合、DFS-N のデプロイは、迅速かつ効率的にカットオーバーを実行するのに役立ちます。 これにより、既存の共有アドレスの一貫性が維持され、移行されたファイルとフォルダーが含まれる新しい場所がポイントされるようになります。

アーカイブ データの場合は、StorSimple ボリューム (またはサブフォルダー) でダウンタイムを取得し、StorSimple ボリューム バックアップをさらに 1 つ取得して、移行した後に、ユーザーやアプリからのアクセスのために移行先を開くことが完全に実行可能なアプローチです。 これにより、キャッチアップ RoboCopy の必要がなくなります。 ただし、この方法には、移行の必要なファイルとバックアップの数によっては、ダウンタイムが数日以上の長さになる可能性があるという短所があります。 これは、長期間書き込みアクセスを行わずに実行できるアーカイブ ワークロードに対してしか選択できないかもしれません。

名前空間がサーバーに完全に同期されたことを確認する

Azure ファイル共有に Azure File Sync を使用する場合は、ローカルの RoboCopy を開始する "前に"、名前空間全体のサーバーへのダウンロードが完了したことを確認することが重要です。 名前空間のダウンロードにかかる時間は、Azure ファイル共有内の項目の数によって異なります。 サーバーに名前空間が完全に移動されたかどうかを確認するには、次の 2 つの方法があります。

Azure portal

Azure portal を使用して、名前空間が完全に移動されたことを確認できます。

  • Azure portal にサインインし、同期グループに移動します。 同期グループとサーバー エンドポイントの同期状態を確認します。
  • 注目する方向はダウンロードです。 サーバー エンドポイントが新しくプロビジョニングされている場合、名前空間がまだダウンロードされていることを示す初期同期が表示されます。 その状態が初期同期以外に変わった後、名前空間はサーバーに完全に設定されます。

これで、ローカルの RoboCopy に進むことができます。

Windows Server イベント ビューアー

Windows Server インスタンスのイベント ビューアーを使用して、名前空間が完全に移動されたことを確認することもできます。

  1. イベント ビューアーを開き、 [アプリケーションとサービス] に移動します。
  2. Microsoft\FileSync\Agent\Telemetry に移動して開きます。
  3. 完了した同期セッションに対応する、最新のイベント 9102 を探します。
  4. [詳細] を選択し、SyncDirection の値が Download であるイベントを確認します。
  5. サーバーへの名前空間のダウンロードを完了すると、Scenario の値が FullGhostedSync で HResult = 0 である 1 つのイベントが発生します。
  6. そのイベントがない場合は、SyncDirection = Download および Scenario = "RegularSync" である他の 9102 イベント を調べることもできます。 これらのイベントのいずれかが見つかったら、現時点では、名前空間のダウンロードが完了し、同期するものがあるかどうかに関係なく、通常の同期セッションの進行中であることを示しています。

最終的な RoboCopy

この時点で、オンプレミスの Windows Server インスタンスと StorSimple 8100 または 8600 アプライアンスには違いがあります。

  1. 移行の進行中にユーザーやアプリが StorSimple 側で生成した変更を取得する必要があります。
  2. Azure File Sync を使用している場合: StorSimple アプライアンスにはキャッシュがありますが、Windows Server インスタンスは名前空間のみであり、現時点ではファイル コンテンツはローカルに格納されていません。 最後の RoboCopy により、使用可能なローカルにキャッシュされたファイルの内容を取得することによってローカルの Azure File Sync キャッシュをすぐに開始でき、Azure File Sync サーバーに格納できます。
  3. 無効な文字があるため、一部のファイルが移行ジョブによって残されている可能性があります。 その場合は、Azure File Sync が有効になっている Windows Server インスタンスにコピーします。 後で、それらを同期されるように調整できます。特定の共有に Azure File Sync を使用していない場合は、StorSimple ボリュームで無効な文字を使用してファイルの名前を変更することをお勧めします。 次に、Azure ファイル共有に対して RoboCopy を直接実行します。

警告

Windows Server 2019 の Robocopy では、/MIR 関数を使用しているときに、ターゲット サーバー上の Azure File Sync によって階層化されたファイルがソースから再コピーされ、Azure に再アップロードされるという問題が発生しました。 Robocopy は、2019 以外の Windows Server (Windows Server 2016 など) で実行することをお勧めします。

警告

サーバーに Azure ファイル共有の名前空間が完全にダウンロードされる前に、RoboCopy を開始することは "できません"。 詳細については、「名前空間がサーバーに完全に同期されたことを確認する」を参照してください。

移行ジョブが最後に実行されてから変更されたファイルと、前にこれらのジョブで移動されていないファイルをコピーするだけです。 移行が完了した後で、サーバーに移動されなかった問題を解決できます。 詳細については、Azure File Sync のトラブルシューティングに関する記事を参照してください。

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 シナリオに対する重要な修正プログラムが含まれています。

RoboCopy コマンドのソースとターゲットの場所を構成する場合は、ソースとターゲットの構造が一致していることを確認してください。 移行ジョブのディレクトリ マッピング機能を使用した場合は、ルート ディレクトリの構造が StorSimple のボリュームの構造と異なる場合があります。 その場合は、サブディレクトリごとに 1 回ずつ、複数の RoboCopy ジョブが必要になることがあります。 コマンドが想定どおりに実行されるかどうかわからない場合は、 /L パラメーターを使用できます。これにより、実際に変更を行わずに、コマンドがシミュレートされます。

この RoboCopy コマンドでは /MIR を使用するため、同じファイル (階層化されたファイルなど) は移動されません。 ただし、ソースとターゲットのパスが間違っている場合は、/MIR により、StorSimple のソース パスには存在しない Windows Server インスタンスまたは Azure ファイル共有上のディレクトリ構造も消去されます。 移行中に行われた最新の変更で移行された内容を更新するという RoboCopy ジョブの目的を達成できるように、それらを正確に一致させる必要があります。

RoboCopy のログ ファイルを調べて、ファイルが残っているかどうかを確認します。 問題がある場合は修正し、RoboCopy コマンドを再実行します。 対象のファイルまたはフォルダーの未解決の問題を解決する前に、StorSimple リソースのプロビジョニングを解除しないでください。

問題の特定の Azure ファイル共有をキャッシュするために Azure File Sync を使用せずに、直接共有アクセスを選択した場合は、次のようにします。

  1. ローカルの Windows コンピューターにネットワーク ドライブとして Azure ファイル共有をマウントします。
  2. StorSimple とマウントされた Azure ファイル共有の間で RoboCopy を実行します。 ファイルがコピーされない場合は、StorSimple 側で名前を修正して無効な文字を削除します。 その後で、RoboCopy を再試行します。 前に示した RoboCopy コマンドは、StorSimple に対する不要な呼び出しを再度行うことなく、複数回実行できます。

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

指定された 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 からファイル、サーバーから Azure ファイル共有、など)。 コピーされなかったファイルをキャッチして再試行するための /MIR スイッチを使用した 1 回以上の追加実行。

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

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

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

Windows Server 2022 と RoboCopy LFSM

RoboCopy スイッチ /LFSM を使用すると、"ボリュームがいっぱい" というエラーで RoboCopy ジョブが失敗することを回避できます。 ファイルのコピーによってコピー先ボリュームの空き領域が "底" 値を下回るたびに、RoboCopy が一時停止します。

RoboCopy は Windows Server 2022 で使用します。 このバージョンの RoboCopy にのみ、重要なバグ修正と、スイッチをほとんどの移行で必要な追加フラグと互換性のあるものにする機能が含まれています。 たとえば、/B フラグとの互換性などです。

/B を使用すると、バックアップ アプリケーションで使用するのと同じモードで RoboCopy が実行されます。 このスイッチを使用すると、現在のユーザーがアクセス許可を持っていないファイルを、RobocCopy によって移動できます。

通常、RoboCopy は、コピー元、コピー先、または 3 台目のマシンで実行できます。

重要

/LFSM を使用する場合は、Windows Server 2022 ターゲット Azure File Sync サーバーで RoboCopy を実行する必要があります。

また、/LFSM を使用する場合にはコピー先に UNC パスではなく、ローカル パスを使用する必要もあることに注意してください。 たとえば、コピー先パスとして、\\ServerName\FolderName などの UNC パスではなく、E:\Foldername を使用する必要があります。

注意事項

Windows Server 2022 で現在利用できる RoboCopy のバージョンにはバグがあり、ファイルごとのエラー数をカウントするために一時停止が発生します。 次の回避策を適用してください。

お勧めの /R:2 /W:1 フラグを使用すると、/LFSM によって生じる一時停止が原因でファイルが失敗する可能性が高くなります。 この例では、/LFSM によって一時停止が発生したために 3 回の一時停止後にコピーされなかったファイルがあると、RoboCopy では間違ってそのファイルを失敗とします。 これに対する回避策は、/R:n と /W:n により大きい値を使用することです。 良い例は /R:10 /W:1800 (それぞれ 30分 の 10 回の再試行) です。 これにより、コピー先ボリュームに領域を作成する時間を Azure File Sync 階層化アルゴリズムに与えることになります。

このバグは修正されましたが、修正はまだ一般公開されていません。 修正プログラムの提供と展開方法に関する最新情報については、この段落を確認してください。

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

Azure File Sync を使用している場合は、その Azure File Sync が有効になっている Windows Server インスタンスに、StorSimple のボリュームに存在していた共有と一致する SMB 共有を作成することが、必要になる可能性があります。 ここで時間を無駄にしないために、このステップを前倒しし、早期に実行することができます。 ただし、この時点より前に、Windows Server インスタンスが変更されないよう、誰もアクセスできないようにする必要があります。

DFS-N のデプロイがある場合、DFN 名前空間を新しいサーバー フォルダーの場所に指すようにすることができます。 DFS-N のデプロイがなく、Windows Server インスタンスを使用するローカル環境に 8100 または 8600 アプライアンスを配置した場合、そのサーバーをドメインから削除できます。 次に、Azure File Sync を有効にした新しい Windows Server インスタンスをドメインに参加させます。 そのプロセスの間に、そのサーバーに古いサーバーと同じサーバー名と共有名を指定し、カットオーバーがユーザー、グループ ポリシー、スクリプトに対して透過的なままになるようにします。

DFS-N の詳細を参照してください。

フェーズ 6: プロビジョニング解除

リソースのプロビジョニングを解除すると、そのリソースおよびそのデータの構成にアクセスできなくなります。 プロビジョニング解除を元に戻すことはできません。 次のことを確認するまで続行しないでください。

  • 移行が完了しました。
  • プロビジョニングを解除しようとしている StorSimple ファイル、フォルダー、またはボリューム バックアップに関する依存関係がありません。

始める前に、運用環境の新しい Azure File Sync のデプロイを少し観察することをお勧めします。 その間に、発生する可能性のある問題を修正できます。 Azure File Sync のデプロイを少なくとも数日間観察した後、リソースのプロビジョニング解除を次の順序で開始できます。

  1. Azure portal を使用して StorSimple Data Manager リソースのプロビジョニングを解除します。 それによりすべての DTS ジョブが削除されます。 コピー ログを簡単に取得することができなくなります。 それらがレコードにとって重要な場合は、プロビジョニングを解除する前に取得します。
  2. StorSimple の物理アプライアンスが移行されていることを確認してから、登録を解除します。 移行されたことを確認できない場合は、続行しないでください。 まだ必要な間にこれらのリソースのプロビジョニングを解除した場合、データやその構成を回復することはできません。
    必要に応じて、最初に StorSimple ボリューム リソースのプロビジョニングを解除できます。これにより、アプライアンス上のデータがクリーンアップされます。 このプロセスには数日かかることがあり、アプライアンス上のデータが科学捜査的にゼロに設定されることはありません。 このことが重要な場合は、リソースのプロビジョニング解除とは別に、ポリシーに従って、ディスクのゼロ設定を処理する必要があります。
  3. StorSimple デバイス マネージャーに登録されているデバイスがこれ以上ない場合は、そのデバイス マネージャー リソース自体を削除することができます。
  4. それから、Azure の StorSimple ストレージ アカウントを削除します。 やはり、続行する前に、移行が完了していることと、このデータに依存しているものやユーザーがないことを確認してください。
  5. StorSimple 物理アプライアンスをデータ センターから取り外します。
  6. StorSimple アプライアンスを所有している場合は、PC を自由にリサイクルできます。 デバイスがリースされている場合は、リース元に通知し、必要に応じてデバイスを返却します。

移行が完了しました。

Note

まだ質問があるか、問題が発生していますか。
その場合は、スペースなしの電子メールアドレス: Azure Files migration at microsoft dot com にご連絡ください

トラブルシューティング

StorSimple Data Manager 移行サービスを使用する場合、移行ジョブ全体または個々のファイルがさまざまな理由で失敗する可能性があります。 「ファイルの忠実性」セクションに、サポートされているシナリオとサポートされていないシナリオの詳細があります。 次の表に、エラー コード、エラーの詳細、および可能な場合は軽減オプションを示します。

ジョブ レベルのエラー

段階 エラー 詳細と軽減策
Backup "指定されたパラメーターのバックアップが見つかりませんでした" ジョブ実行用に選択されたバックアップが、"推定" または "コピー" の時点で見つかりません。 StorSimple バックアップ カタログにまだバックアップが存在することを確認してください。 自動バックアップ保持ポリシーにより、移行のためにバックアップを選択してから、そのバックアップの移行ジョブを実際に実行する間にバックアップが削除されることがあります。 移行を開始する前に、バックアップ保持スケジュールを無効にすることを検討してください。
推定
コンピューティングの構成		 "暗号化キーをインストールできませんでした" "サービス データ暗号化キー" が正しくありません。 詳細についてこの記事の暗号化キーに関するセクションを参照し、正しいキーを取得してください。
"バッチ エラー" 移行を実行するために必要なすべての内部インフラストラクチャを起動すると問題が発生する可能性があります。 このプロセスには、他の複数のサービスが関係しています。 通常、これらの問題は、ジョブの実行を再試行すると解決されます。
StorSimple Manager の内部エラーが発生しました。 しばらくしてから操作をやり直してください。 引き続き問題が発生する場合は、Microsoft サポートにお問い合わせください。 (エラー コード: 1074161829) この一般的なエラーには複数の原因がありますが、StorSimple デバイス マネージャーが、上限である 50 個のアプライアンスに達した可能性があります。 デバイス マネージャーで、最近実行されたジョブがこのエラーで突然失敗し始めたかどうかを確認します。その場合は、これが問題であることを示唆しています。 この特定の問題の軽減策は、Data Manager サービスによって作成されて使用されたオフラインの StorSimple 8001 アプライアンスを削除することです。 サポート チケットを提出するか、ポータルで手動で削除することができます。 オフラインの 8001 シリーズ アプライアンスのみを削除してください。
ファイルの推定中 "ボリュームの複製ジョブに失敗しました" このエラーは、何らかの原因で破損したバックアップを指定したことを示している可能性が高いです。 移行サービスでマウントまたは読み取りを行うことができません。 バックアップを手動で試すか、サポート チケットを開くことができます。
"ボリュームが NTFS 以外の形式であるため続行できません" 移行サービスで使用できるのは、重複排除が有効になっていない NTFS ボリュームのみです。 ReFS やサードパーティの形式など、別の形式のボリュームがある場合、移行サービスではそのボリュームを移行できません。 「既知の制限事項」セクションを参照してください。
サポートにお問い合せください。 ディスクに適切なパーティションが見つかりません 移行用に指定されたボリュームを持つはずの StorSimple ディスクに、そのボリュームのパーティションがないように見えます。 これは異常な状態であり、破損や管理上の不整合を示している可能性があります。 この問題をさらに調査する唯一のオプションは、サポート チケットを提出することです。
タイムアウト 推定フェーズがタイムアウトで失敗する場合は、通常、StorSimple アプライアンス、またはソース ボリューム バックアップの速度が遅く、場合によっては破損していることのいずれかの問題です。 バックアップを再実行しても解決しない場合は、サポート チケットを提出することをお勧めします。
ファイル <path> が見つかりません
パスの一部が見つかりませんでした"		 ジョブ定義を使用すると、ソース サブパスを指定できます。 このエラーは、そのパスが存在しない場合に表示されます。 例: \Share1 > \Share\Share1
この例では、\Share1 をソースのサブパスとして指定し、ターゲット内の別のサブパスにマッピングしています。 ただし、ソース パスが存在しません (スペルミスかもしれません)。 注: Windows では大文字と小文字は保持されますが、大文字と小文字は区別されません。 つまり、\Share1 と \share1 を指定することは同等です。 また、存在しないターゲット パスは自動的に作成されます。
"この要求では、この操作の実行は許可されません" このエラーは、ソース StorSimple ストレージ アカウントまたは Azure ファイル共有を持つターゲット ストレージ アカウントでファイアウォール設定が有効になっている場合に表示されます。 パブリック エンドポイント経由のトラフィックを許可し、それ以上のファイアウォール規則で制限しないようにする必要があります。 そうしないと、データ変換サービスは、承認されている場合でも、どちらのストレージ アカウントにもアクセスできません。 ファイアウォール規則をすべて無効にして、ジョブを再実行してください。
ファイルのコピー中 "アクセスされているアカウントは HTTP をサポートしていません" ターゲット ストレージ アカウントでインターネット ルーティングを無効にするか、または Microsoft ルーティング エンドポイントを使用します。
"指定された共有は空き領域がありません" ターゲットが Premium Azure ファイル共有である場合は、共有のための十分な容量をプロビジョニングしたことを確認してください。 一時的な過剰プロビジョニングは一般的な現象です。 ターゲットが標準の Azure ファイル共有である場合は、ターゲット共有で "大きいファイルの共有" 機能が有効になっていることを確認します。 Standard Storage は、共有を使用するにつれて拡大します。 ただし、レガシ ストレージ アカウントをターゲットとして使用する場合は、5 TiB の共有制限が発生する可能性があります。 "大きいファイルの共有" 機能を手動で有効にする必要があります。 ターゲット上で制限を修正し、ジョブを再実行してください。

項目レベルのエラー

移行ジョブの実行のコピー フェーズ中に、個々の名前空間項目 (ファイルとフォルダー) でエラーが発生する可能性があります。 次の表に、最も一般的なエラーの一覧と、可能な場合の軽減オプションを示します。

段階 エラー 対応策
Copy に設定する必要があります -2146233088
サーバーがビジーです。"		 エラーが多すぎる場合は、ジョブを再実行します。 エラーが非常に少ない場合、ジョブの再実行を試みることはできますが、多くの場合、失敗した項目を手動でコピーした方が速い可能性があります。 その後、次のバックアップの処理にスキップして移行を再開します。
-2146233088
指定された時間内に操作を完了できません。"		 エラーが多すぎる場合は、ジョブを再実行します。 エラーが非常に少ない場合、ジョブの再実行を試みることはできますが、多くの場合、失敗した項目を手動でコピーした方が速い可能性があります。 その後、次のバックアップの処理にスキップして移行を再開します。
"アップロードがタイムアウトしたか、コピーが開始されていません" エラーが多すぎる場合は、ジョブを再実行します。 エラーが非常に少ない場合、ジョブの再実行を試みることはできますが、多くの場合、失敗した項目を手動でコピーした方が速い可能性があります。 その後、次のバックアップの処理にスキップして移行を再開します。
-2146233029
操作は取り消されました。		 エラーが多すぎる場合は、ジョブを再実行します。 エラーが非常に少ない場合、ジョブの再実行を試みることはできますが、多くの場合、失敗した項目を手動でコピーした方が速い可能性があります。 その後、次のバックアップの処理にスキップして移行を再開します。
1920
ファイルにアクセスできません。"		 これは、移行エンジンが再解析ポイント、リンク、またはジャンクションを検出した場合に発生する一般的なエラーです。 それらはサポートされていません。 これらの種類のファイルはコピーできません。 この記事の「既知の制限事項」セクションと「ファイルの忠実性」セクションを確認してください。
-2147024891
アクセスが拒否されました		 これは、ディスク上でアクセスできない方法で暗号化されたファイルのエラーです。 ディスクから読み取ることができるが、単に暗号化されたコンテンツが含まれるファイルは影響を受けず、コピーできます。 唯一のオプションは、手動でコピーすることです。 このような項目を見つけるには、影響を受けるボリュームをマウントし、次のコマンドを実行します。get-childitem <path> [-Recurse] -Force -ErrorAction SilentlyContinue | Where-Object {$_.Attributes -ge "Encrypted"} | format-list fullname, attributes
有効な Win32 FileTime ではありません。 パラメーター名: fileTime この場合、移行エンジンが依存するタイムスタンプが破損しているか、アプリケーションによって正しくない形式で書き込まれたため、ファイルにアクセスすることはできますが、コピーの評価はできません。 バックアップ内のタイムスタンプを変更することはできないため、できることはあまりありません。 このファイルを保持することが重要な場合は、最新バージョン (このファイルを含む最後のバックアップ) で、手動でファイルをコピーし、タイムスタンプを修正してから、ターゲットの Azure ファイル共有に移動します。 このオプションは大規模に実施することは難しいですが、ターゲットに少なくとも 1 つのバージョンを保持する必要がある価値の高いファイルに対するオプションです。
-2146232798
セーフ ハンドルが閉じられました"		 多くの場合、一時的なエラーです。 エラーが多すぎる場合は、ジョブを再実行します。 エラーが非常に少ない場合、ジョブの再実行を試みることはできますが、多くの場合、失敗した項目を手動でコピーした方が速い可能性があります。 その後、次のバックアップの処理にスキップして移行を再開します。
-2147024413
致命的なデバイス ハードウェア エラー"		 これはまれなエラーであり、実際には物理デバイスではなく、移行サービスで使用される 8001 シリーズの仮想化アプライアンスについての報告です。 アプライアンスで問題が発生しています。 このエラーが発生したファイルにより、移行が次のバックアップに進むのが停止されることはありません。 そのため、手動コピーを実行したり、このエラーが発生したファイルを含むバックアップを再試行したりすることが困難になります。 残されたファイルが非常に重要な場合、または多数のファイルがある場合は、すべてのバックアップの移行を再度開始する必要がある場合があります。 詳細な調査を行うには、サポート チケットを開いてください
削除
(ミラーの消去)		 指定されているディレクトリが空ではありません。 このエラーは、移行モードが "ミラー" に設定され、Azure ファイル共有から項目を削除するプロセスが、アイテムの削除を妨げる問題に遭遇したときに発生します。 削除は、以前のスナップショットからではなく、ライブ共有でのみ行われます。 削除が必要なのは、影響を受けるファイルは現在のバックアップに存在しないため、次のスナップショットの前にライブ共有から削除する必要があるためです。 2 つのオプションがあります。オプション 1: ターゲットの Azure ファイル共有をマウントし、このエラーが発生したファイルを手動で削除します。 オプション 2: これらのエラーを無視し、ターゲットがソースと同じではなく、元の StorSimple バックアップにはなかった追加の項目がいくつか含まれていることを期待して、次のバックアップの処理を続行できます。
正しくない要求 このエラーは、ソース ファイルに、Azure ファイル共有にコピーできなかった特定の特性があることを示します。 特に、ファイル名に非表示の制御文字がある、またはファイル名またはファイル パスに 2 バイト文字の 1 バイトが含まれている可能性があります。 コピー ログを使用してパス名を取得し、ファイルを一時的な場所にコピーし、パスの名前を変更してサポートされていない文字を削除してから、もう一度 Azure ファイル共有に robocopy を実行できます。 その後、次に処理するバックアップにスキップして、移行を再開できます。

次のステップ

  • クラウドを使った階層化ポリシーの柔軟性を理解します。
  • Azure ファイル共有で Azure Backup を有効にして、スナップショットをスケジュールし、バックアップ保持期間のスケジュールを定義します。
  • Azure portal で、一部のファイルが完全に同期していないことがわかった場合は、その問題を解決する手順についてトラブルシューティング ガイドを確認します。