假設：
兩個獨立的FastDFS，分別是服務器A、B。兩臺服務器處於不同網段，不能互通。第三方，從A存儲目錄下，拷貝文件到B相同目錄，然後在B服務器上，下載拷貝的文件。
結論：報錯，提示"getStoreStorage fail,errno code:22"等類似信息。
這是因爲拷貝的文件的名字，有特定規則導致的
FastDFS的文件ID中可以反解出哪些字段？
文件ID中除了包含group name和存儲路徑外，文件名中可以反解出如下幾個字段：
1）文件創建時間（unix時間戳，32位整數）
2）文件大小
3）上傳到的源storage server IP地址（32位整數）
4）文件crc32校驗碼
5）隨機數（這個字段用來避免文件重名）
文件名包含：源存儲服務器IP地址、文件創建時間戳、文件大小、隨機數和文件拓展名等信息。
一、組名：文件上傳後所在storage組名稱，在文件上傳成功後有storage服務器返回，需要客戶端自行保存。
二、虛擬磁盤路徑：storage配置的虛擬路徑，與磁盤選項store_path*對應。如果配置了store_path0則是M00，如果配置了store_path1則是M01，以此類推。
三、數據兩級目錄：storage服務器在每個虛擬磁盤路徑下創建的兩級目錄，用於存儲數據文件。
四、文件名：與文件上傳時不同。是由存儲服務器根據特定信息生成，文件名包含：源存儲服務器IP地址、文件創建時間戳、文件大小、隨機數和文件拓展名等信息。
因爲這個名字會有源存儲服務器，所以估計會從文件名稱算出的源下載文件，而不會從文件真實的存儲下載。就上面的例子，雖然請求是在B上下載那個文件，但其實可能最終根據文件名稱，算出源是A，所以去A下載文件，最終導致失敗。
所以，因爲文件命名規則的特定意義，導致簡單的FastDFS文件遷移是行不通的。
幾種方案，一種是在目標服務器，利用客戶端或其他方式，重新上傳文件，得到新的文件名，後期使用新的文件名。二，知道文件名的命名規則，把其中有關源服務器ip的屬性修改成正確的機器ip值。這個方案有點困難，因爲源碼是C寫的，看不懂C的id生成規則，所以無法修改一個長字符串中的特定屬性。三，是利用FastDFS自身的機制，storage server、tracker server之間的同步機制，實現數據的遷移。這個方法，可以參考https://blog.csdn.net/qq_38616723/article/details/103049012。