做網站遷移大量的小文件怎麼辦？

01-03

公司一個網站準備遷移，就是換台伺服器跑著。發現網站目錄下有大量的小圖片，大概67G，每個圖片100~500kb。目測拷貝過去需要好幾天的時間。敢問知乎，有運維人員遇到過這樣的問題嗎？怎麼處理？
另外這個網站還在運行中，只有晚上幾個小時可以停掉。
伺服器環境：linux5.8+php+nginx

一些分析：

1. 不要打包，如果要寫回磁碟，會增添不必要的 IO 量；

2. 不要壓縮，如果數據主體都是小圖片的話，壓縮沒有任何收益，反而會帶來解壓失敗的風險；

3. 大規模小文件傳輸的主要耗時在於大量元信息的讀取和 TCP 短連接的重複鏈路參數協商過程中，前者很難避免（可以用 dd 命令繞過，但是對於聯機數據不友好），後者可以通過復用長連接解決。

方案一：

使用「rsync + 啟用 TCPKeepAlive 參數的 ssh」來解決。

rsync 支持1）斷點續傳，2）帶寬控制，3）進度報告，4）復用 TCP 連接；

啟用 TCPKeepAlive 參數的 ssh 可以解決稀疏文件傳輸超時斷開問題，請參考（總結）Linux下設置SSH Server保持長時間連接最後一個答案。

還可以結合 xargs 命令或者 parallel 工具來提升 rsync 進程並發數。

方案二：

做過動靜分離的話，直接用雲存儲首頁 - 七牛雲存儲的「鏡像存儲」功能做分發，然後寄塊硬碟完事。

1. 先tar打包(壓縮)再傳輸，網路穩定的話可以這麼做

2. 或者rsync直接傳輸，這個速度會慢，不過可以續傳，如果網路不穩定建議這個

3. 可以分塊打包，比如根據圖片大小適當的分塊篩選(find)打包，然後再傳輸

4. 另外，如果數據不重要，通過HTTP(wget)傳輸應該會更快些

把硬碟拔過去

3TB的硬碟，江浙滬順豐大概是一天，如果要用網路的話，假設100Mbps的上行帶寬，大概實際速度是10MB/s，3*1024*1024/10=314572.8（秒）=5242.8（分鐘）=87.3（小時）=3.6（天），你說哪個速度快。

這裡有個問題要注意，好像沒看到人提起。

dns重新做解析後，並不是全國的機器都會立即訪問到新的伺服器，這就存在遷移後幾十個小時用戶可能同時訪問新伺服器和舊伺服器的情況。這樣產生的新圖片需要通過程序或者rsync同步。當然你們的數據應該也有這種問題，不過好像沒有提及。

如果你不在乎那幾十個小時丟掉小部分的訪問量，這個問題就比較簡單，有個人已經回答了直接把硬碟帶到新機房就可以了。

但是如果你在乎那些數據的話就可以按照下面的方法來:

總體來說要做如下幾件事情

1 新伺服器部署以及測試完成

2 把圖片copy到新硬碟，如果圖片增量非常快(每小時幾個G)就放在凌晨2:30以後，不過我覺得這應該不是你的現狀。

3 找人把硬碟帶到新機房，部署好，啟動系統

4 讓域名指向到新IP

5 啟動圖片同步程序，這個可能要持續到舊的伺服器幾乎沒人訪問為止。

資料庫以及nosql的部分流程基本差不多，只不過同步程序稍微麻煩點。

最後建議，如果業務量沒起來到每天上億的訪問量，還是雲伺服器好，點幾下滑鼠硬碟就到新機器上了。否則每次規模擴大都是不眠夜。

程序生成每m個文件或n兆打成一個包的腳本，再執行，再拷貝到新伺服器，解包

出問題的包，按編號個別重新打、拷、解

當然，如果硬碟可以接過去掛上繼續使用，最簡單了；

如果新伺服器可以把圖片鏈接的實際目錄指向舊伺服器的圖片目錄，也能保證立即可以使用（同時拷貝文件就不怕慢了）

所以還是固態好，4k讀寫飛一樣。

1，舊伺服器的網站伺服器先綁定一個域名，記為B

2，你可以寫一個404.php，把所有404頁面交給404.php解析

3， 404.php的內容可以是把所有404請求轉發到域名B ，用302跳轉，不影響SEO 。

4，先把除了圖片以外的數據遷移至新伺服器，然後剩下的圖片就用任一方式拷貝到新伺服器，這一過程不會影響網站圖片的正常訪問，且停服時間最短。

直接拔硬碟拷貝啊內網拷貝大約1T=3億個小文件時，直接用dd拷貝分區，網卡跑滿，速度飛一般

你的問題，首先需要確定瓶頸何在。那些不問瓶頸而直接給方案，甚至要求打包壓縮的同學，怎麼說你們才好呢。

把瓶頸確定下來，再談。

我猜想，瓶頸可能在磁碟、cpu、網路上。

用 rsync 同步過去。

首先，先改一下舊站上傳圖片的功能，確保新上傳的圖片，保存到別的目錄。

其次，用 rsync 把舊圖片同步到新的機器上。rsync 可限速，不會影響舊站對外服務。67G，花幾天慢慢同步就行了。

最後，舊圖片全都同步過去了，一次性把新上傳的圖片 scp 過去。並，遷網站代碼。

能拆硬碟的盡量拆硬碟，拆過去直接設置陣列備份到新硬碟，然後老硬碟可以換掉了，不能拆硬碟盡量GHOST，再不然就網線支鏈，我轉100多G數據不到一個小時

這點圖片，沒有想像的恐怖。

不久前做了類似的事情，遷移圖片到異地機房的機器上，圖片大約 60+GB，圖片大小 1 - 200KB 之間，且大小主要分布在 50-100KB 之間，可見小文件數量在你目前情況之上。源機器在某地電信機房，出口帶寬是共享 100Mb/s （保證 10Mb/s），目的機器是某雲主機。

做法：

1. rsync 在伺服器帶寬負載小的時候增量同步，控制好同步時機和速度

2. inotify 監控新增文件觸發 rsync 同步，保持異地機器數據盡量最新

tsunami-udp

tsunami-udp 是一款專為網路加速誕生的小工具。用TCP進行傳輸控制、用UDP進行數據傳輸。

cheetahmobile/tsunami-udp · GitHub

還有一個神奇bbcp

bbcp

你可以試試

項目不急著上的話：選取一個時間點，將新上傳的文件放入另一個目錄，然後給現有站點增加一個將從現在開始所有新上傳的圖片同步到目標伺服器的功能。

然後在不影響服務的情況下採用答案中所有傳輸方式的一種，將時間點之前的舊文件轉到目標伺服器。同時部署好目標伺服器上的服務

最後正式遷移。

項目急著上的話：如果這些圖片不完全是熱數據，可以考慮目標伺服器上的讀取邏輯改成先讀本地，如果本地沒有，就從老伺服器那裡抓取。初始並發訪問不大的情況下還是可以試試看的。同時在不影響服務的情況下繼續傳輸。保證最快上線

1.題主的新伺服器上架了吧，基本環境應該搭建好了吧，

2.那麼多的圖片，你可以白天慢慢用rsync同步過去，

3.資料庫和web就沒有什麼難題了

4.關鍵你要保證數據一致性，資料庫可以考慮rsync，其它的浮雲…

5.記住一點，之前同步了會記錄的，不用擔心會再來一遍，不行你可以同步圖片試試…

所以，整體不難，規劃好…一個小時絕對夠

為什麼沒人提到btsync

robocopy誰用誰知道，大量碎文件遷移，效率非常高

67g小文件幾個小時的遷移應該夠的。

67g/0.3(m) = 20多萬個小文件，這個根本不是問題。經常幾百萬幾十K小文件遷移，每周還有50T以上數據遷移到數據挖掘庫。

減少任何不必要的開銷，CPU 內存網路協議磁碟IO 網卡 OS 程序本身的開銷等等。

1.區域網的話:TCP控制+UDP傳輸+遠程管道。

樓上有個哥們說的好，要確定瓶頸。

磁碟IO不用說，主要看CPU和網路這塊。 tar + nc -u /dd + nc. 啟用壓縮耗費CPU，不啟用壓縮耗費帶寬。你測試一下5g的小文件傳輸啟用壓縮和不啟用壓縮分別所用時間。

有條件測試一下中間加交換機傳輸，和直連傳輸。我們網路環境下，經過中高端交換機比直連傳輸更快，我估計和拆包解包的效率有關係。

所以網路環境好，交換機好，直接通過交換機網路傳輸；網路負荷大，還是用直連。

2.還有一個不厚道的方法！

一般伺服器都做了RAID的，如果兩台伺服器磁碟型號一致，然後你懂的。。。

60多G么，直接硬體層面的同步，一個小時估計夠了。

3.用一個USB3.0的移動硬碟。比網路傳輸快幾倍。

dd /TAR都可以，這個就不要壓縮了。

其實最靠譜的是第三個辦法。

樓主遷移完了之後上來反饋一下。

先本地winrar打包，拷貝，在目的機器解包，這樣比直接烤巨量

文件快得多。

用sftp或者ftp就可以了~ 還能保證一段時間內同時兩邊都能被訪問到

做網站遷移 大量的小文件怎麼辦？

做網站遷移大量的小文件怎麼辦？