Windows ServerでRobocopyがFTPに失敗する原因と対策（Error 53: The network path was not found）

Windows Serverのバックアップファイル（.bak）をRobocopyでFTPサーバーへ送ろうとして、Error 53「The network path was not found」で失敗するケースは珍しくありません。原因は経路や権限よりも“Robocopyの仕様”にあります。仕組みと、確実に自動転送する代替手段をまとめます。

発生する症状（RobocopyでError 53が出る）

典型的には、Windows Server上の大容量バックアップ（例：ABC.bak）を、次のようにRobocopyで転送しようとして失敗します。

ROBOCOPY "G:\Backup\full" "\\ftp.xyz.com\backup" ABC.bak /Z /R:5 /W:60

実行すると以下のようなメッセージが出ます。

• Error 53 ... Getting File System Type of Destination
• The network path was not found.

一方で、エクスプローラーからは ftp.xyz.com にログインできてしまうため、「見えているのにRobocopyだけ失敗する」状態になります。

結論：RobocopyはFTPに対応していない（だから失敗する）

RobocopyはFTP（ftp://）転送に対応していません。Robocopyが扱える宛先は、基本的に次のいずれかです。

• ローカルパス（例：D:\Work）
• ドライブレター（例：Z:\）
• UNCパス（例：\\server\share）

これらはすべて、Windowsから見て「ファイルシステムとして扱える」パスであり、通信プロトコルとしては主にSMB/CIFS（Windowsファイル共有）を前提にしています。

一方、FTPはSMBとは別プロトコルです。エクスプローラーでFTPが開けても、その時に動いているのはSMBではありません。結果として、Robocopyが \\ftp.xyz.com\backup を「SMB共有のUNC」として解釈し、接続できずにError 53（ネットワークパスが見つからない）になります。

なぜエクスプローラーでは接続できるのに、Robocopyは失敗するのか

ここが最大の落とし穴です。「エクスプローラーでFTPにログインできる」＝「Robocopyで使える共有がある」ではありません。

エクスプローラーのFTPは“ファイル共有”ではなく“クライアント機能”

Windowsのエクスプローラーは、FTPサーバーに対して「ネットワークの場所」としてログインし、一覧表示やアップロード/ダウンロードができます。これはブラウザのような“クライアント機能”であり、Windowsファイル共有（SMB）とは別物です。

そのため、エクスプローラーで見えるフォルダ階層は「FTPサーバー上のディレクトリ」であって、Windowsの共有名（share）ではありません。

Robocopyは“ファイルシステム”として宛先を判定する

Robocopyはコピー開始前に宛先に対して、ファイルシステム種別（NTFS/ReFSなど）や属性の扱いを確認します。ログに出る Getting File System Type of Destination は、その判定処理です。

UNCパスで指定された宛先は、Windows的には「SMBでつながる共有」を想定するため、FTPサーバーに対しては前提が合いません。これがError 53の根本原因です。

項目	エクスプローラーでのFTP	Robocopyの宛先（UNC/共有）
想定プロトコル	FTP（またはFTPS）	SMB/CIFS
指定方法	ftp:// や「ネットワークの場所」	\\server\share
“フォルダ”の意味	FTPディレクトリ	共有名（share）配下のフォルダ
Robocopyが必要とする前提	不要	ファイルシステムAPI/属性/タイムスタンプ処理が可能

最短で切り分けるチェックリスト（FTPかSMBかを見誤らない）

「Robocopyが失敗する原因がネットワークなのか、仕様なのか」を早く判断するには、次のチェックが有効です。ポイントは、Robocopyが見ているのはFTP(21番)ではなく、SMB(445番)だという点です。

確認項目	コマンド例	見るべきポイント
名前解決	nslookup ftp.xyz.com	IPが引けるか（DNSが正しいか）
SMB疎通（Robocopyの前提）	powershell -Command "Test-NetConnection ftp.xyz.com -Port 445"	445/TCPが到達可能か
FTP疎通（エクスプローラーの前提）	powershell -Command "Test-NetConnection ftp.xyz.com -Port 21"	21/TCPが到達可能か
共有の存在確認（SMB）	dir \\ftp.xyz.com\backup	一覧が取れるか（共有名が正しいか）
結論の判断	（上の結果を総合）	FTPしか通らないならRobocopyではなく転送ツールへ

あなたが本当に必要なのは「FTP転送」か「Robocopy相当の同期」か

対処を決める前に、目的を切り分けるのが近道です。

やりたいこと	最適解	理由
Robocopyの差分/ミラー/再開/詳細ログを使って同期したい	宛先をSMB共有（\\server\share）にする	RobocopyはSMB/ファイルシステム向けの設計
宛先がFTPサーバーで、アップロードさえできればよい	WinSCP / curl / PowerShell（SFTP/FTPS含む）に切り替える	FTPに合う道具を使うのが確実

Robocopyを使い続けたい場合：宛先をSMB共有にする

もし宛先サーバー側でSMB共有が用意できるなら、Robocopyの強み（リトライ、再開、ミラー、ログ、監査に耐える手順）をそのまま活かせます。

SMB共有の基本形

• 宛先サーバー（Windows/Samba等）に共有を作る（例：共有名 backup）
• ファイアウォールでSMB（主にTCP 445）を許可する
• 認証（ドメイン/ローカルユーザー）とアクセス権を整える

認証が必要な共有に対する実行例

共有に資格情報が必要なら、事前に接続してからRobocopyを実行します。

net use \\fileserver\backup /user:DOMAIN\backupuser "password"
ROBOCOPY "G:\Backup\full" "\\fileserver\backup" "ABC.bak" /Z /R:5 /W:60 /LOG+:C:\Logs\robocopy.log

ポイントは、Robocopyの宛先がFTPホスト名ではなく、SMB共有のホスト/共有名になっていることです（例：\\fileserver\backup）。

SMBとFTP/SFTP/FTPSの違い（運用目線の比較）

方式	主なポート	暗号化	向いている場面
SMB（ファイル共有）	445/TCP	環境次第（SMB暗号化/署名など）	社内LAN・VPN内での同期、Robocopyを活かしたい
FTP	21/TCP + データ用ポート	なし（平文になりやすい）	レガシー環境、外部保管庫の指定がFTPのみ
FTPS	990/TCP等（方式により差）	あり（TLS）	FTP互換を保ちつつ暗号化したい
SFTP（SSH）	22/TCP	あり（SSH）	外部転送を安全・シンプルに運用したい

FTPにアップロードしたい場合：代替手段で“転送の自動化”を作る

宛先がFTPしか提供していない、あるいは「外部のバックアップ保管庫がFTP/FTPS/SFTPで受け付ける」というケースでは、Robocopyにこだわるよりも、転送に強いツールで運用を組むほうが安全です。

代替手段の比較（どれを選ぶべきか）

手段	向いている用途	強み	注意点
WinSCP	定期バッチ、堅牢な自動転送、ログ/再試行が必要	スクリプトが書きやすい、再試行・ログ・同期が強い	インストール/配置が必要
curl	単発のアップロード、最小構成での自動化	コマンド1本で済む（環境により標準搭載）	細かな同期（ミラー）には工夫が必要
PowerShell / .NET	既存運用に組み込みたい、前後処理を柔軟に書きたい	監視・通知・世代管理と組み合わせやすい	FTP周りは作り込みが必要。SFTPは追加ライブラリが必要になりがち
SFTPへ切り替え	セキュリティ重視、運用を安定させたい	暗号化が標準、単一ポートで扱いやすい場合が多い	サーバー側の対応が必要

WinSCPでの実装例（大容量ファイルの自動アップロード）

「Windows Serverでバックアップを生成 → FTP/FTPS/SFTPへ確実に送る」を現場運用で安定させたいなら、WinSCPは定番です。転送が失敗した時のログが読みやすく、再試行やタイムアウト調整もしやすいのが理由です。

WinSCPスクリプト例

例として、ABC.bak を /backup ディレクトリへアップロードします。

option batch abort
option confirm off

open ftp://USER:[email protected]/
cd /backup
put "G:\Backup\full\ABC.bak"

exit

バッチから実行し、ログを残す例

"C:\Program Files (x86)\WinSCP\WinSCP.com" ^
  /script="C:\Scripts\upload_ftp.txt" ^
  /log="C:\Logs\winscp_upload.log" ^
  /ini=nul

タスクスケジューラで夜間に回す運用にも向きます。失敗時にログが残るようにしておくと、翌朝の切り分けが劇的に楽になります。

実運用で効く小ワザ（途中失敗に強くする）

• 一時名でアップロードし、最後にリネームして「完成品」だけを見せる（例：ABC.bak.part→ABC.bak）
• 転送成功後にローカル側で世代管理（例：7世代だけ残す）
• ログファイルを日付で分け、監視ツールが拾える場所に置く

curlでの実装例（ワンライナーでFTPへアップロード）

「とにかく1ファイル送れればよい」「サーバーに追加インストールを増やしたくない」という場合は、curlが便利です。

FTPへアップロード

curl -T "G:\Backup\full\ABC.bak" "ftp://USER:[email protected]/backup/ABC.bak" --retry 5 --retry-delay 60

FTPS（暗号化）を使う場合の一例

curl -T "G:\Backup\full\ABC.bak" "ftps://ftp.xyz.com/backup/ABC.bak" --user "USER:PASSWORD" --ssl-reqd --retry 5 --retry-delay 60

SFTPが使えるなら（より推奨されやすい）

curl -T "G:\Backup\full\ABC.bak" "sftp://[email protected]/backup/ABC.bak" --key "C:\Keys\id_rsa" --retry 5 --retry-delay 60

FTPは平文で流れる要素が多く、ネットワーク境界やコンプライアンス要件次第では運用上のハードルになります。可能ならFTPS/SFTPへの切り替えを検討すると、後々の監査対応や障害対応が楽になります。

PowerShellでの運用設計（転送の“前後”を固めると事故が減る）

PowerShellは「バックアップが完了したら転送」「成功したら古い世代を削除」「失敗したらメールやTeamsへ通知」など、前後処理を含めた運用を1本にまとめやすいのが利点です。

転送処理そのものはWinSCPやcurlに任せ、PowerShellは制御に徹する構成が、結果として安定しやすいです。

やりたいこと	おすすめ構成	理由
ログ/再試行/途中再開を確実にしたい	PowerShell（制御）＋ WinSCP（転送）	転送の“枯れた”実装を使える
追加ソフトが難しいが自動化したい	PowerShell（制御）＋ curl（転送）	単純なアップロードなら十分実用的

大容量バックアップ（.bak）を失敗しにくくする実務のコツ

FTP/SFTP/SMBのどれを使うにしても、バックアップファイルの転送は「大容量」「夜間バッチ」「失敗時の再実行」が前提になることが多く、運用設計が結果を左右します。

転送対象のファイルが“書き込み中”になっていないか

バックアップ作成プロセスがまだ書き込み中の状態でアップロードを始めると、転送中にサイズが変わったり、途中でロック競合が起きたりします。次のような運用が安全です。

• バックアップ完了後に別名へリネーム（例：ABC.bak.tmp→ABC.bak）してから転送する
• 完了フラグファイル（例：ABC.bak.done）を作ってから転送を開始する
• ファイルサイズが一定時間変化しないことを確認してから送る

再試行だけでなく“整合性確認”まで入れる

大容量ファイルは、通信瞬断やタイムアウトで失敗しがちです。再試行は必須ですが、再試行するだけでは「壊れたファイルを成功扱い」にするリスクがあります。可能なら次のいずれかで整合性を確認します。

• 転送前後でハッシュ（SHA-256等）を比較する
• 一時ファイル名でアップロードし、最後にリネームで確定させる
• サーバー側でサイズ検証（期待サイズと一致するか）を行う

トラブル	起きやすい原因	対策例
転送が途中で止まる/タイムアウトする	回線品質、NAT、アイドルタイムアウト	ツール側でタイムアウト延長・再試行設定、可能ならSFTP/FTPSへ
“成功”なのにファイルが壊れている	部分転送の上書き、バイナリ/ASCII誤設定	バイナリ転送固定、ハッシュ確認、一時名→リネーム
FTPはつながるがアップロードできない	パーミッション不足、書き込み禁止、容量制限	サーバー側の権限/クォータ確認、パス指定ミスを見直す
RobocopyでError 53になる	宛先がSMB共有ではない（FTPをUNCで指定している）	SMB共有に切替、またはWinSCP/curlへ

よくある誤解とQ&A

「FTPをドライブレターに割り当てればRobocopyできるのでは？」

結論から言うと難しいです。エクスプローラーの「ネットワークの場所」追加は、見た目がフォルダっぽくても、Robocopyが求める“ファイルシステムとしてのドライブ”とは異なります。RobocopyはファイルシステムAPIでアクセスできる宛先が前提です。

「Error 53はDNSや疎通の問題では？」

Error 53自体は“ネットワークパスが見つからない”なので、DNSや疎通が原因になることもあります。ただし今回のように、宛先が \\ftp.xyz.com\backup の形で、FTPサーバーに対してUNCを使っている場合は、原因の中心はSMB共有が存在しない（あるいはSMBが閉じている）ことです。FTPにログインできる事実だけでは、Robocopyの成功条件を満たしません。

「どうしてもRobocopyのように“差分同期”したい」

FTPは本質的に“ファイル共有”ではなく“転送”なので、差分同期（ミラー）をFTPでやるなら、ツール側が同期機能を持っている必要があります。WinSCPには同期機能があり、SFTP/FTP/FTPSでも一定の範囲で同期を実現できます。サーバー側が許すなら、そもそもSMB共有に寄せるのが運用は簡単です。

まとめ：Robocopy FTP Error 53の正体と、最短で解決する考え方

• RobocopyはFTP非対応のため、FTPホストをUNC（\\ftp.xyz.com\...）で指定するとError 53になりやすい
• エクスプローラーでFTPに入れるのは“クライアント機能”であり、SMB共有があることとは別
• Robocopyを使いたいなら宛先をSMB共有にする（\\server\share）
• FTPへ送る必要があるなら、WinSCP/curl/PowerShellなど、FTP向けの道具で自動転送を組む
• 大容量バックアップは、再試行だけでなく整合性確認（ハッシュ/一時名/リネーム）まで含めて設計すると事故が減る