こんにちは！普段 Azure インフラの構築業務を担当している上村です。
今回は、比較的最近登場した Azure Storage Mover という製品について調査し、実際に触ってみました。
※本記事は、2025 年 3 月時点の情報を記載しています。最新の正確な情報は Microsoft の公式ドキュメントをご確認下さい。
Azure Storage Mover（以下、単に Storage Mover と呼びます）は、オンプレミスファイルサーバーを Azure のストレージアカウントに移行するためのデータ移行ツールです。
Storage Mover の公式ドキュメントの冒頭では、下記のように記載されています。
オンプレミスファイルサーバーの移行ツールとしては、従来の RoboCopy をはじめとして幾つかの移行ツールが既に存在しますが、それらに追加するような形で比較的最近登場したツールです。移行のための様々な設定や操作をマネージド化して便利になったこと、規模の大きい移行でも纏めて管理できるようになったことなどがこの製品の「推しポイント」であるということが、上記の記述から伺えます。
では、具体的にはどのような仕様になっていて、旧来の製品と比べてのメリット・デメリットはどのようなものなのでしょうか。
Storage Mover では、オンプレミスの仮想化環境にエージェントサーバーを作成し、このエージェントサーバーを介して Azure にファイルサーバーのデータを送信するというしくみになっています。
Storage Mover と移行先のストレージアカウント以外に必要となる Azure リソースとしては、オンプレミスファイルサーバーの認証情報を格納する Key Vault や、移行時のログを格納する Log Analytics があります。
そのほか、プライベート接続を構成する場合は、仮想ネットワークやプライベートエンドポイント、仮想ネットワークゲートウェイといったネットワークリソースが必要となります（なお、プライベート経由で移行する場合でも、制御メッセージ・進行状況テレメトリ・コピーログの通信はパブリック経由になります）。
サポートされている移行元（ソース）と移行先（ターゲット）は、下記の通りです。
※ 通常オンプレミスファイルサーバーでは SMB マウントを使用しているケースが多いと思われますので、以降は基本的に SMB ファイルサーバーを Azure ファイル共有に移行することを想定した内容を記載します。
エージェントサーバーとして使用できる仮想化環境は Windows Hyper-V および VMware のみです。Azure VM はサポートされていません。
ネットワーク要件としては、インターネット接続が必要で、アウトバウンド TCP 443 が許可されている必要があります。
そのほか、メモリ・仮想コア・ストレージ等の要件については、こちら
をご確認ください。
ターゲットの Azure ファイル共有でサポートされているものは全て移行可能です。
Azure ファイル共有でサポートされるメタデータについては
こちら
をご確認ください。
こちらもターゲットの Azure ファイル共有の仕様に依存します。
Azure ファイル共有では、NTFS 権限はサポートされますが共有権限はサポートされず、代わりに RBAC による制御となります。詳細は
こちら
をご確認ください。
上記のほかにも、何か移行できない種類のファイルがあるのではないか、といった懸念もあるでしょう。Storage Mover のドキュメントには特に記載が無かったため念のため Microsoft 社にも確認したのですが、Storage Mover の仕様としては、基本的にはプロトコルレベルで問題が無ければあとはターゲットの Azure ファイル共有の仕様に依存するとのことでした。
では Azure ファイル共有の制限がどうなっているかというと、下記のドキュメントに詳細な制限が記載されています。主に問題になりそうなのはパス長やサブフォルダ数等かと思われますが、実際の移行にあたっては詳細をご確認いただくことをお勧めします。
Storage Mover では、下記 2 つのコピー方式が選択できます。
移行プロセス進行中、ソース・ターゲットともに、ファイル編集・保存・作成・削除等の操作を実行することは可能です。移行プロセス進行中にこのような操作を実施した場合には、エラーログとして出力されるようです。
SMB ファイルサーバーを Azure ファイル共有に移行するための手段は複数存在します。他の移行手段に関する詳細については こちら や こちら のドキュメントに譲るとして、本項ではそれらと比較した際の Storage Mover の主なメリット・デメリットとして考えられるものを記載します。
上記を踏まえると、Storage Mover の使用が適切なケースは、主に下記の点を満たす場合だと言えるでしょう。
実際に Storage Mover を構築し、移行作業を試してみました。
作業の流れは下記の通りです。
1. Azure リソースの準備（ストレージアカウント、Key Vault、Log Analytics、Storage Mover）
2. エージェントサーバーの作成
3. Storage Mover でソース・ターゲット等の情報を設定し、ジョブを作成して実行
詳細は割愛しますが、Azure Portal で下記の通りリソースを作成しておきます。
作成後、ターゲットとなるファイル共有を作成しておきます。
作成後、オンプレミスファイルサーバーにログインするためのアカウントおよびパスワードを、それぞれ「シークレット」に格納しておきます。
特別な設定は不要です。
作成する際のパラメータは、名前・リソースグループ・リージョンだけです。
リージョンについては、どこを選択しても問題はありません。ファイルサーバーのデータは、エージェントサーバーを介して Azure ファイル共有に送信されるしくみです。Storage Mover が直接データの送信で使用されるわけではないので、地理的に遠くのリージョンを選択してもパフォーマンスには影響ありません。
また、この段階では、Storage Mover リソース作成後に何か設定を行う必要はまだありません。
オンプレミスでエージェントサーバーを作成していきます。
Hyper-V を使用する場合は、こちら
のドキュメントに作成手順が記載されています。一方で VMware を使用する場合の手順については Microsoft のドキュメントには詳細な記載がありません。そのため、この記事では VMware を使用した場合のエージェントサーバー構築の一連の流れを簡単にご紹介します。
1. まず、エージェントサーバーの OVA ファイルを こちら からダウンロードしておきます。
2. 次に、VMware ESXi の管理画面から仮想マシンの作成画面に進み、「OVFファイルまたはOVAファイルから仮想マシンをデプロイ」を選択して OVA ファイルをアップロードします。
3. あとは通常の VMware 仮想マシンを作成する場合と同様、ウィザードに従ってデータストアやプロビジョニング方法を指定し、最後に「完了」を押下して VM を作成します。
4. VM が作成されたら、エージェントサーバーの中に入ってネットワーク関連の設定をしていき、その後に Azure 上の Storage Mover にエージェントサーバーを登録するという流れになります。
ちなみにエージェントサーバーは Ubuntu ベースの仮想マシンであり、用意された項目以外の操作は基本的に出来ないようになっています。
5. まずエージェントサーバーに接続し、デフォルトの ID・パスワード
でログインします。
すぐにパスワード変更を要求されるため、新しいパスワードを入力して変更します。
6. CLI 上でどの操作を行うか聞かれますので、「2）Network configuration」を選択し、プロンプトに従って設定していきます。ここでは構築したオンプレミスの環境に応じた設定を行ってください。
ちなみに、今回設定した「1）Interface」の設定項目は下記の通りでした。
7. 「2）Network configuration」の設定を完了して「Quit」で抜けると、自動的に Azure との接続確認が走ります。
リージョンを聞かれるので、Storage Mover で使用するリージョン名を入力して接続確認を行い、すべて「OK」となることを確認します。
8. ネットワークまわりの設定が完了したら、次にエージェントの登録作業を実施していきます。
エージェントサーバーに接続して最初に表示される選択肢の中から、今度は「4）Register」を選択します。
プロンプトに従って、サブスクリプション ID・リソースグループ名・Storage Mover 名、任意のエージェント名などを入力します。
9. 最後にアクセス許可コードを入力してデバイス認証を行うように求められるため、表示された URL にアクセスします。
10. 使用する Azure テナントの Entra ID アカウントを用いて、上記で表示されたアクセス許可コードを入力して認証します。これがエラー無く実施できれば、エージェントサーバー側の設定は完了です！
Azure Portal で、作成しておいた Storage Mover を開きます。
作成する項目は下記の 4 つです。
Storage Mover のページで、[ストレージエンドポイント] タブから作成します。
ソースエンドポイントでは、ソースとなるファイルサーバーへの接続に必要な情報を設定します。ファイルサーバーの IP アドレスおよび共有名のほか、ID・パスワードを格納しておいた Key Vault の情報等を入力します。
同様にターゲットエンドポイントも作成します。
ターゲットエンドポイントでは、移行先となる Azure ファイル共有を指定するだけです。
プロジェクトは、複数の移行ジョブを束ねて管理するための入れ物だと認識しておけばよいかと思います。
設定項目はプロジェクト名だけです。
最後に移行ジョブを作成します。必須の設定項目は下記の通りです。
移行ジョブを作成したら、「ジョブの開始」を押下して移行を実行します。
※ このとき、ターゲットの Azure ファイル共有や Key Vault に対する RBAC が自動的に割り当てられます。
※ RBAC の割り当てを行うため、ログインアカウントにはリソースグループの所有者が割り当たっている必要があります。
コピーの進行状況はこのように Azure Portal から視覚的に確認できます。
コマンドラインツールによる移行ではどうしても実行状況が分かりづらいため、データ量が多くコピーが長時間に及ぶケースでは、特に便利であるように思われます。
成功すると下記のように表示されます。
また、Log Analytics を構成している場合は、上記の移行状況の下部に、コピーに失敗した内容が下記のようにエラーログとして表示されます（勿論 Log Analytics で Kusto クエリを打っても同じ内容が確認できます）。
ちなみに上記のエラーログは、① 移行ジョブ実行中に、既にコピーされていた「exceltest.xlsx」をターゲット側の Azure ファイル共有で削除したものと、② 移行中にデータソースで「exceltest1.xlsx」を削除したものです。
勿論、移行作業中はデータソース・ターゲットともにデータが変更されないように事前に調整することが望ましいですが、仮に何か修正を加えた場合でも、Storage Mover では検知してこのような形でエラーログとして出力してくれるようです。
そして、仮に移行できなかったデータがあったり、移行完了後にソースのデータが変更されたりした場合でも、「ジョブの実行」から何度でも差分のみの移行が簡単に実行できます。
いかがだったでしょうか。Storage Mover は、SMB なら Azure ファイル共有、NFS なら BLOB ストレージにファイルサーバー移行をする場合に使えるツールであり、主に大容量データをオンラインで移行する場合に有効であると考えられます。このような条件に当てはまる場合は、利用を検討してもよいのではないでしょうか。
また、Storage Mover は比較的最近登場したツールであり今後も機能拡充が見込まれるものと思われますので、最新情報もぜひチェックしてみてください（リリースノートは
こちら
から確認できます）。
