Synology NASをUniFi UNAS Pro 8へ移行：Robocopy、SMB Multichannel、そして驚きのパフォーマンスの落とし穴

Synology NASをUniFi UNAS Pro 8へ移行：Robocopy、SMB Multichannel、そして驚きのパフォーマンスの落とし穴 2026年8月23日 コメント [0] Musings に投稿 スポンサー提供 私は長年Synology NASを使用してきましたが、最近そのコンテンツを新しいUbiquiti UniFi UNAS Pro 8に移行し始めました。これは比較的退屈な作業になるはずでした。両方のデバイスはSMBを使用し、私のネットワークは高速（最近内部的に10ギガビットにアップグレード済み）で、Windowsは何十年も前からマシン間でファイルを確実にコピーするためのツールを持っています。当然、私がすでに知っていると思っていたことを学ぶ一晩になり、それが私がブログを始めた理由です（笑）。私にとって、これは興味深い歴史でもありました。なぜなら、2007年（信じられない！）に「XCopyは有害とみなされる - RobocopyまたはXXCopyまたはSyncBack」という投稿を書いたからです。当時の私の主張は、基本的に、十分なファイルを移動するようになると、エクスプローラーは移動手段ではなくなり、Robocopyがかなり良い選択肢になるということでした。私は/Z、Robocopyの再開可能モードさえ使用しました。なぜなら、部分的に転送されたファイルを再開できることは、信頼性の低い接続で役立ったからです。ほぼ20年後、/Zは私が削除する必要があった最も重要なことの1つであることが判明しました。なぜなら、それがすべてを非常に遅くしたからです。 移行 基本的な作業は単純でした。Synologyには\server\musicのような共有があり、UNASにも\UNAS-Pro-8\musicのような対応する共有がありました。私は最初にエクスプローラーを使用しました。ほとんどの場合、それがそこにあったからであり、そして簡単なことが本当に簡単なことである場合があるからです。エクスプローラーが個々のファイルでエラーを生成し始めるまで、それは続きました。 ファイルシステム制限のため、要求された操作を完了できませんでした 私の最初の考えはファイル名でした。NASの移行は、あるファイルシステムが別のファイルシステムよりも許容度が高いことを発見する機会に満ちています。括弧やその他の句読点を含むファイル名がありました。その後、これが失敗しました。 \server\music\Athlete\Tourist\05 Wires.m4p 05 Wires.m4pには特に変わったところはありません。そのため、もう少し情報を得るためにRobocopyに切り替えました。それは一貫して92%に達し、Windowsエラー665を返しました。 92% 新規ファイル 4.3 m 05 Wires.m4p エラー 665 (0x00000299) ファイルのコピー ファイルシステム制限のため、要求された操作を完了できませんでした この時点で、有用な質問はもはや「そのファイル名に何が問題なのか？」ではなく、「パスのどの部分がこのファイルを拒否しているのか？」でした。私はファイルをSynologyからローカルのWindowsデスクトップにコピーしました。それはうまくいきました。次に、ローカルファイルをWindowsからUNASにコピーしましたが、同じファイルシステム制限で失敗しました。これにより問題が特定され、Synologyはファイルを読み取ることができ、Windowsはそれを保存できましたが、この特定のファイルをUNASに書き込むことに関して問題が発生しました。 代替データストリーム、再び NTFSファイルは、通常私たちがファイルのコンテンツとして考える通常の名前のないストリームに加えて、名前付きの代替データストリームを含むことができます。これは古いWindowsファイルシステム機能であり、Windowsがダウンロードされたファイルの出所を記録するために使用できるZone.Identifierについて議論した2007年に私が書いたものと偶然一致します。私は2003年にも代替データストリームについてブログを書きました！！！WindowsはDIR /Rでこれらのストリームを公開できます。そこで私は次を実行しました。 dir /r "%USERPROFILE%\Desktop\05 Wires.m4p" そして次を得ました。 11/30/2011 02:17 PM 4,576,368 05 Wires.m4p 360,456 05 Wires.m4p:01APIC_03.jpg:$DATA それがありました。通常の4.5 MBの音楽ファイルに加えて、01APIC_03.jpgという名前の約360 KBのデータストリームがありました。これは、奇妙な92%の失敗も説明していました。Robocopyは、ファイルの主要なコンテンツを正常に処理してから、追加のストリームに遭遇していました。通常の.m4pファイルの中間あたりで発生しているように見えた失敗は、実際にはWindowsが追加のファイルシステムデータを処理しようとしたときに発生していました。 Robocopyにはこの状況に正確に対応するサポートがあります。Microsoftは、Xを/COPYフラグの1つとして文書化しています。これは「代替データストリームをスキップする」という意味です。したがって： /COPY:DATX は、ファイルのデータ、属性、タイムスタンプをコピーしますが、代替ストリームはコピーしません。 /DCOPY:DATX は、ディレクトリに同様の動作を適用します。 私は同じファイルを再試行しました。 robocopy "\server\music\Athlete\Tourist" "\UNAS-Pro-8\music\Athlete\Tourist" "05 Wires.m4p" /R:0 /W:0 /COPY:DATX /DCOPY:DATX /V そしてそれは正常に完了しました。ここで重要な区別は、DATXがMP3、M4A、M4P、JPEG、またはその他のファイル形式内に保存されているメタデータを削除しないということです。それはRobocopyにファイルに関連付けられた個別のファイルシステムストリームを複製しないように指示します。私のケースでは、これらの追加ストリームは新しいNASに保持する必要のあるものではありませんでした。 コピーは成功しましたが、遅かった ADSの問題が理解された後、私は比較的標準的なRobocopyコマンドで大規模な移行を開始しました。 robocopy "\server\music" "\UNAS-Pro-8\music" /E /Z /MT:16 /R:2 /W:2 /COPY:DATX /DCOPY:DATX /XJ /TEE /LOG:"%USERPROFILE%\Desktop\synology-to-unas.log" 実行されましたが、パフォーマンスはバラバラでした。時には毎秒数百メガビットが見られましたが、その後劇的に低下しました。小さなファイルが長時間そこに留まっているように見えることがありました。バッファリング、遅いディスク、パリティ計算、UNASでのSMBの動作、あるいは私のSynologyがついに限界に達したのではないかと疑問に思い始めました。それで、「ランダムなものを試す（二分法）」時間になりました。スレッド数を減らしました。シングルスレッドを試しました。どれも助けになりませんでした。それから/Zを削除しました。 MicrosoftのRobocopyドキュメントでは、/Zを再開可能モードとして説明しており、中断されたファイルがゼロバイトから再開するのではなく再開できるようにします。私が忘れていたのは、Microsoftの現在の移行ガイダンスでは、再開可能性のために必要な追加のロギングがコピーパフォーマンスを大幅に低下させる可能性があるため、/Zは慎重に使用すべきだと警告していることです。私の音楽の成功した実行は次のようなものになりました。 robocopy "\server\music" "\UNAS-Pro-8\music" /E /MT:4 /R:2 /W:2 /COPY:DATX /DCOPY:DATX /XJ /TEE /LOG:"%USERPROFILE%\Desktop\synology-to-unas-DATX.log" その実行からの要約は次のとおりです。 合計 コピー済み スキップ 不一致 失敗 ファイル : 15940 6991 8949 0 0 バイト : 70.907 g 47.917 g 22.989 g 0 0 スピード : 187,185,171 バイト/秒。 したがって、残りの約48 GBのデータをコピーした実行は、平均して約187 MB/秒で、失敗したファイルはありませんでした。これは、他のすべてを同じに保ちながら正確に1つの変数を変更した制御されたベンチマークではなかったため、/Zが以前の遅延のすべてのビットを説明したと主張するつもりはありません。しかし、実用的な違いは十分に大きかったため、再開可能性が望ましいように聞こえるという理由だけで、LAN移行コマンドに自動的に含めるものはもう/Zではありません。安定したローカルネットワークでは、それなしで開始し、実際にそのセマンティクスが必要になった場合にのみ追加します。 /MTは便利ですが、特定の問題に役立ちます Robocopyの/MT:nオプションは、複数のスレッドを使用してコピーを実行します。1から128までの値をサポートし、/MTが数値なしで提供された場合は8スレッドがデフォルトです。Microsoft自身の移行ガイダンスは、より多くのスレッドが自動的に高速な移行につながるわけではないことを指摘しており、実際のワークロードに対してスレッド数を測定することを推奨しています。これは、/MT:4を「1つのファイルを4倍速くする」と考えるのをやめたときに、より意味が通るようになりました。不確かな出所の何千ものファイル（私がリッピングした、冗談です）を含む音楽コレクションを想像してみてください。ファイルを開く、宛先ファイルを作成する、そのコンテンツを読み書きする、メタデータを処理する、そしてそれを閉じるという作業があります。シングルスレッドコピーには、これらの操作の1つが完了するのを待っている間にネットワークまたはストレージが待機している期間があります。複数のファイルを同時に進行させることで、Robocopyはその作業をオーバーラップさせる機会を得られます。この特定のコレクションでは、4つのスレッドが適切なフィットであることが判明しました。16は明らかにそれ以上の助けにはならず、1つのスレッドは改善ではありませんでした。私は/MTをすべてのコマンドラインに属する魔法の値にすることを避けるでしょう。なぜなら