家里那臺四盤位 NAS 跑了兩年多硬盤占用率從 40% 一路漲到 80%而辦寬帶時被塞過來的那個運營商網(wǎng)盤賬號幾百個 G 的空間常年只躺著幾張發(fā)票截圖和一堆過期安裝包。這種資源錯配我盯了很久一邊是硬盤要加錢擴容一邊是白給的容量在曬太陽。后來我干脆把 NAS 上一個專門用來堆冷數(shù)據(jù)的同步文件夾通過WebDAV掛到了那個網(wǎng)盤的開放接口上讓兩邊按計劃自動對賬。整個過程不裝任何第三方客戶端不上傳主賬號密碼跑起來之后基本不用管。這篇寫的就是這套東西的完整落地過程。WebDAV 同步文件夾這套組合能干什么簡單說把你 NAS 上某個目錄里的文件自動、定時、增量地推到網(wǎng)盤上反過來也行。它解決的問題很具體——NAS 硬盤容量有限且擴容成本高而閑置的網(wǎng)盤空間幾乎免費同時 NAS 自帶的同步套件跑不了那些只出 Windows/Mac 客戶端的網(wǎng)盤WebDAV 是少數(shù)雙方都認的通用接口。適合誰來參考手里有 NAS、有一個吃灰的網(wǎng)盤賬號、愿意花兩個小時配置一次然后長期省事的人。新手也能跟我會把每一步為什么這么做講清楚踩過的坑也會列出來。1. 先把這套方案到底省了什么搞清楚1.1 需求拆解為什么要繞道 WebDAV而不是直接用官方客戶端很多人第一反應是“網(wǎng)盤不是有官方客戶端嗎裝一個不就完了”。問題就在這兒官方客戶端基本只覆蓋 Windows、macOS、手機端NAS 這種跑精簡 Linux 的設備根本裝不上。你當然可以每天開電腦手動拖一遍但那不叫方案那叫體力活。WebDAV 的價值在于它是一套基于 HTTP 的文件操作協(xié)議——PROPFIND 列目錄、PUT 上傳、GET 下載、DELETE 刪除、MOVE 改名全是標準動作。對 NAS 來說遠端那個網(wǎng)盤就是一個“長得像網(wǎng)絡驅(qū)動器的東西”NAS 的同步套件只要支持 WebDAV 這一種連接類型就能掛載所有提供 WebDAV 入口的服務。類比一下各家網(wǎng)盤的官方客戶端像專用充電器插頭形狀各不相同WebDAV 像通用插座只要你出的是標準插頭誰家的電都能取。我對比過三條路結(jié)論很明確方式能否在 NAS 上自動跑是否增量傳輸對本地空間的占用維護成本官方同步客戶端基本不行無 NAS 版是需要一臺常開的電腦高得留臺機器網(wǎng)頁端手動上傳不行否每次全量無極高純?nèi)肆ebDAV NAS 同步套件可以做成計劃任務是靠索引比對無額外占用配一次之后基本零維護選 WebDAV 不是因為它先進而是因為它“夠舊”。越舊的協(xié)議支持它的設備越多這在自建存儲這個圈子里是條鐵律。1.2 三塊積木的全景圖數(shù)據(jù)到底怎么流動這套方案由三個部件拼起來任何一個環(huán)節(jié)理解錯了都會在后面排查時抓瞎。第一塊是NAS 側(cè)的 WebDAV 服務。NAS 系統(tǒng)里通常有個叫 WebDAV Server 的套件裝上、啟用、分配端口它就把你指定的共享文件夾變成一個可以用 WebDAV 協(xié)議訪問的地址。注意這塊在本方案里其實是“可選”的——如果你只是單向把 NAS 文件推到網(wǎng)盤根本不需要開這個服務它的用武之地是反過來讓別的設備手機、另一臺電腦通過 WebDAV 訪問 NAS 上的文件。第二塊是網(wǎng)盤側(cè)的 WebDAV 入口。這是整個方案的地基。部分網(wǎng)盤在網(wǎng)頁端的設置里有“開放接口”或“第三方應用”之類的開關打開之后會給你一個地址和一個專用密碼。地址形如https://服務域名/webdav/這個路徑各家不一樣有的帶/dav有的帶/remote.php/dav必須照官方說明抄。第三塊是NAS 側(cè)的同步套件很多系統(tǒng)叫 CloudSync 或類似名字。它扮演客戶端角色主動向網(wǎng)盤的 WebDAV 地址發(fā)起出站連接拉文件列表、比對、傳輸。這里有個特別關鍵、但很多人繞不明白的點數(shù)據(jù)流的方向是 NAS 主動出站連網(wǎng)盤不是網(wǎng)盤來連 NAS。這意味著你不需要公網(wǎng) IP、不需要在路由器上做端口映射、不需要任何內(nèi)網(wǎng)穿透。家里寬帶是幾層 NAT 之后的大內(nèi)網(wǎng)也沒關系只要 NAS 能上網(wǎng)就行。我見過不少人一頭扎進端口映射里折騰半天其實方向搞反了。1.3 收益與代價的清醒賬別只看省下的錢先說收益。那個網(wǎng)盤賬號的容量是辦寬帶時附帶的幾百 G 到一兩個 T 不等市面上同類容量的一年會員費少說也要一兩百。把它當成 NAS 的“異地冷備層”等于用零邊際成本換來一份不在同一個物理位置的數(shù)據(jù)副本——硬盤掛了、機器進水了、誤刪了云端還有一份。這個價值比省下的會員費大得多。再說代價一共三條都得提前認。其一是上行帶寬。家寬的上行普遍是下行的十分之一甚至更少50Mbps 上行理論值 6.25MB/s實際跑滿的情況很少。我第一次同步一個 40GB 的素材庫跑了一整夜還多。這個后面會算細賬。其二是接口的限流。網(wǎng)盤對第三方接口一般有并發(fā)和頻率限制你開十個并發(fā)猛沖輕則變慢重則報 429 被臨時拒絕。所以并發(fā)數(shù)不能貪。其三是單向性帶來的心理落差。這套方案做的是文件搬運不是“網(wǎng)盤體驗”。你在網(wǎng)頁端看不到漂亮的相冊歸類沒有秒傳沒有在線解壓。把它當備份層用心態(tài)就正了指望它替代網(wǎng)盤客戶端會失望。2. 動手前的準備與關鍵取舍2.1 硬件、系統(tǒng)與網(wǎng)絡前提的一次性盤點動手前我把這幾項挨個確認了一遍省得配到一半發(fā)現(xiàn)缺東西。NAS 系統(tǒng)版本盡量在 7.x 以上這里說的是那種網(wǎng)頁版管理界面、套件生態(tài)比較全的系統(tǒng)老版本 6.x 的同步套件在 WebDAV 兼容性上確實有差異某些服務商會因為 TLS 版本太低而拒絕握手。硬盤剩余空間至少要是計劃同步量的 1.5 倍——為什么是 1.5 而不是 1因為同步套件需要維護索引數(shù)據(jù)庫還要留出沖突文件副本的空間卡在 1.0 會很難受。網(wǎng)絡這塊只需要確認一件事NAS 能正常解析外網(wǎng)域名、能出站訪問 443 端口。在 NAS 的終端里curl -I https://你的網(wǎng)盤域名試一下能返回 200 或 301 就沒問題。如果公司網(wǎng)絡或某些特殊環(huán)境攔截了 443那就先解決這個別往下走。還有一個容易被忽略的點NAS 的系統(tǒng)時間必須準。同步套件的差異判斷很大程度上依賴文件的修改時間mtime如果 NAS 的時間偏差超過幾分鐘會導致已經(jīng)同步過的文件被反復判定為“有變化”而重傳。在系統(tǒng)設置里把 NTP 時間同步打開指向一個公共時間服務器這一步別省。2.2 四組關鍵參數(shù)怎么定為什么這么定參數(shù)這東西最忌諱照抄別人的配置因為每個人帶寬、文件結(jié)構(gòu)、同步量都不同。我把四組核心參數(shù)的取值邏輯列出來你按自己的情況套。參數(shù)常見默認值我的取值定這個值的理由同步方向雙向僅上傳異地冷備雙向會把云端的刪除動作傳回本地風險太大同步計劃實時監(jiān)控每天凌晨 2:00 一次實時監(jiān)控會頻繁拉目錄列表容易觸發(fā)限流并發(fā)文件數(shù)32降到 2 之后大文件失敗率明顯下降見第 5 章實測上傳限速不限白天 2MB/s夜間不限白天不搶占家人看視頻的帶寬同步方向這一段值得多說兩句。雙向同步聽著美好——兩邊永遠一致——但它有個致命特性刪除會傳播。你在網(wǎng)頁端手滑清空了一個目錄下一輪同步時本地那份也跟著沒了。我吃過這個虧一次誤操作帶走了三十多 G 的資料雖然有回收站兜底但恢復過程極其難受。所以我的原則是跨公網(wǎng)的同步一律只做單向本地是源云端是副本。想反向取回文件時手動建一個“僅下載”的臨時任務用完就刪。同步計劃的取舍在于“實時性值不值那個代價”。實時監(jiān)控模式inotify在文件數(shù)量超過十萬之后內(nèi)存占用和目錄掃描開銷都很可觀而且每次變動都要往云端發(fā)一次列表請求。對冷數(shù)據(jù)備份這個場景一天一次完全夠用凌晨跑還能避開帶寬高峰。2.3 賬號與權(quán)限的最小化設計這一節(jié)是我認為最該較真、但絕大多數(shù)教程一句話帶過的地方。第一絕對不要在同步任務里填網(wǎng)盤的主登錄密碼。去網(wǎng)盤的開放接口頁面生成一個專用的應用密碼/授權(quán)碼這類密碼通常只顯示一次抄在密碼管理器里。專用密碼的好處是可以單獨吊銷、權(quán)限受限、泄露了不影響主賬號。我在第一次配置時就犯過錯圖省事填了登錄密碼結(jié)果觸發(fā)了異地登錄驗證賬號被臨時鎖定折騰了半小時才解開。第二NAS 上單獨建一個用戶。不要用管理員賬號跑同步任務。新建一個普通用戶比如叫sync-bot只授予它一個專用共享文件夾的讀寫權(quán)限其他文件夾一律不給。這樣即使同步任務被利用損失范圍也被框死在那一個目錄里。第三專用共享文件夾。我在存儲池里建了一個獨立文件夾比如叫cloud-bridge里面按photos、docs、archive分了三個子目錄。同步任務只指向這個文件夾絕不指向整個存儲池。為什么不直接同步整個盤因為系統(tǒng)會在各個目錄里塞eaDir縮略圖和索引目錄、#recycle回收站、.DS_Store、Thumbs.db這類東西全量同步上去會把云端搞得一團糟還白占配額。第四開啟失敗鎖定。系統(tǒng)安全設置里通常有“連續(xù)登錄失敗 N 次后封鎖 IP”的選項打開它順便把兩步驗證也開了。3. NAS 側(cè)把 WebDAV 服務架起來3.1 套件安裝與服務啟用的完整步驟雖然前面說了這塊在本方案里是可選的但我還是建議裝上原因是它能幫你快速驗證“WebDAV 這套東西在我機器上到底通不通”出問題時也能當對照組。進套件中心搜 WebDAV找到官方那個 WebDAV Server安裝。裝完打開界面很樸素就兩個勾選框啟用 HTTP 和啟用 HTTPS。默認端口 HTTP 是 5005HTTPS 是 5006。我當時的做法是兩個都勾上但端口都改掉。改成什么隨便挑兩個 20000 到 60000 之間的、沒被占用的數(shù)字就行比如 HTTP 改 50080、HTTPS 改 50443。為什么改默認端口是全世界的掃描器第一個試的地方日志里每天幾千條爆破記錄看著就煩改掉之后清凈很多。啟用之后立刻測一下。在同一局域網(wǎng)的電腦上瀏覽器訪問http://NAS的局域網(wǎng)IP:50080如果彈出一個需要輸入賬號密碼的認證框說明服務起來了。輸進去能看到共享文件夾列表就徹底通了。提示這里有個坑。部分系統(tǒng)的瀏覽器對 WebDAV 的 PROPFIND 方法處理得很怪直接訪問會返回 405 或者一片空白。別慌這不代表服務沒起來換一個支持 WebDAV 的客戶端比如能掛 WebDAV 的文件管理器去測就正常。3.2 證書、端口與訪問控制什么該開什么不該開證書這塊分兩種情況別搞混。只在局域網(wǎng)內(nèi)訪問不需要證書HTTP 就夠。局域網(wǎng)是你自己家的網(wǎng)絡明文傳輸?shù)娘L險等同于零。很多人一上來就折騰 Lets Encrypt純屬給自己加戲。需要從外網(wǎng)訪問那就必須上 HTTPS而且要用正規(guī) CA 簽發(fā)的證書不能用自簽的。自簽證書的問題是客戶端不認每個設備都要手動“信任”一次還容易在系統(tǒng)更新后失效。正規(guī)證書現(xiàn)在申請門檻不高很多系統(tǒng)自帶免費證書申請功能配一個域名解析過去就能簽。訪問控制要做三層。第一層是防火墻系統(tǒng)防火墻里只放行你改過的那個端口其他一律拒絕。第二層是自動封鎖連續(xù)失敗 5 次封 24 小時。第三層是賬號隔離前面 2.3 節(jié)說的那個sync-bot用戶只給它一個文件夾的權(quán)限登錄后看不到別的東西。我額外做了一件事把 WebDAV 服務的訪問日志打開每周掃一眼。不是為了防黑客——家用環(huán)境被針對性攻擊的概率極低——而是為了看有沒有異常的大量 PROPFIND 請求那通常意味著某個客戶端配置錯了在瘋狂重試。3.3 共享文件夾與權(quán)限的落地配置新建共享文件夾的路徑是控制面板 → 共享文件夾 → 新增。名字就叫cloud-bridge所在存儲池選容量大的那個。加密選項我建議不開——開了之后每次系統(tǒng)重啟都要手動掛載無人值守的定時同步任務會因為文件夾沒掛載而全部失敗這是很多人踩過的坑。建好之后回到用戶與群組編輯sync-bot的權(quán)限在共享文件夾權(quán)限頁里把cloud-bridge勾成“讀寫”其他所有文件夾都設成“禁止訪問”。注意是“禁止訪問”而不是“只讀”只讀雖然不能改但能看到目錄結(jié)構(gòu)沒必要。然后用管理員賬號在cloud-bridge里建三個子目錄photos、docs、archive。分別對應你要同步的三類數(shù)據(jù)。為什么不建一個大目錄混著放因為后面你會想給不同目錄設不同的同步頻率——照片半年才動一次文檔天天變混在一起就只能按最頻繁的那個來白白多跑請求。驗證方式是回到局域網(wǎng)電腦用資源管理器“映射網(wǎng)絡驅(qū)動器”地址填\\NAS的IP\cloud-bridge用sync-bot的賬號登錄。能進、能新建文件、能刪——三項都通過權(quán)限就配對了。4. 云盤側(cè)WebDAV 入口的開啟與地址填寫4.1 找到開關、生成專用密碼、抄下地址這部分各家服務商差別最大我只能給通用路徑和判斷方法。先在瀏覽器登錄網(wǎng)盤網(wǎng)頁版找設置類入口。關鍵詞是“開放接口”“第三方應用”“開發(fā)者”“WebDAV”“應用密碼”這幾個詞之一一般藏在“賬號安全”或“實驗室功能”下面。有些服務商把它放在很深的二級菜單找不到就直接搜官方幫助文檔里“WebDAV 怎么開啟”這是最快的辦法。打開開關之后頁面通常會給你三樣東西服務器地址、賬號、應用密碼。賬號一般就是你的手機號或郵箱密碼是一串隨機字符只顯示一次關掉頁面就再也看不到了。我第一次就是手快點了關閉只好把開關關掉再重新打開重新生成一次。地址的格式要特別留意。常見的有這么幾種https://xxx.example.com/webdav/—— 最樸素的形式https://xxx.example.com/dav/—— 多一層路徑https://xxx.example.com/remote.php/dav/files/用戶名/—— 帶用戶名的完整路徑https://xxx.example.com/—— 根路徑就是不需要額外加結(jié)尾有沒有斜杠路徑層級對不對都會直接決定連不連得上。這一點在第 6 章的排查表里我會展開這里先記住抄地址的時候原樣復制別自己“優(yōu)化”。4.2 先在電腦上驗證三件套再去 NAS 里配這是我認為整個流程里最重要的一條經(jīng)驗不要在 NAS 的同步套件里做第一次連接測試。NAS 的同步套件在連接失敗時給出的錯誤信息往往非常含糊就一句“連接失敗”或者“認證失敗”你根本分不清是地址錯了、密碼錯了、還是 TLS 版本不對。而在電腦上用支持 WebDAV 的文件管理器去連報錯會精確得多——401 就是密碼問題404 就是路徑問題超時就是網(wǎng)絡問題。具體怎么做找一款支持 WebDAV 的文件管理工具手機端、電腦端都有不少新建連接把地址、賬號、應用密碼填進去。連上了能看到云端的目錄列表說明三件套百分百正確。這時候再去 NAS 里配成功率極高。我當時第一次沒做這一步直接在同步套件里填報“無法連接”查了四十分鐘才發(fā)現(xiàn)是地址結(jié)尾少了個斜杠。后來老老實實先在電腦上驗后面配第二臺機器時兩分鐘就通了。4.3 同步方向與遠程路徑的確定在正式開始同步之前還要在云端把目錄結(jié)構(gòu)想清楚。我的做法是在云盤根目錄下建一個nas-backup文件夾里面再按photos、docs、archive分三個子目錄和本地一一對應。為什么不直接同步到根目錄因為根目錄下還有你自己平時用的東西發(fā)票、安裝包、別人的分享轉(zhuǎn)存混在一起之后同步套件的文件列表會變長差異比對變慢而且你也沒法一眼看出哪些是 NAS 推上來的。同目錄結(jié)構(gòu)還有個好處將來你要做反向恢復云端 → 本地路徑能一一對應上不用重新理一遍。這里要提醒一個心理預期云端目錄和本地目錄的“總大小”不會完全相等。因為有些文件被過濾規(guī)則排除了eaDir之類有些因為文件名含非法字符被跳過了。差個幾百 M 是正常的差幾十個 G 就要去查了。5. 同步任務的落地與實測記錄5.1 創(chuàng)建任務的完整步驟打開 NAS 上的同步套件CloudSync 一類左下角有個加號點開是服務商列表。列表里會有一堆常見的云服務往下翻找到 WebDAV 那一項選中。第一步填連接信息服務器地址就是 4.1 抄下來的那個注意要帶協(xié)議頭https://很多人漏了協(xié)議頭直接報格式錯誤、端口地址里已經(jīng)帶端口的話這里留空或填默認 443、用戶名、密碼。第二步選本地路徑和遠程路徑。本地路徑選/cloud-bridge/photos遠程路徑選/nas-backup/photos。這里有個細節(jié)遠程路徑的輸入框有時候需要你先點一下“瀏覽”按鈕讓套件去拉一次云端目錄樹拉不出來說明連接有問題別硬填。第三步選同步方向。三個選項雙向、僅上傳本地更改、僅下載遠程更改。選“僅上傳”。第四步設計劃。選“每天”然后指定時間 02:00。如果套件提供“高級設置”點進去做三件事開文件過濾把eaDir、#recycle、.DS_Store、Thumbs.db、*.tmp加進去、把并發(fā)文件數(shù)改成 2、把“不覆蓋較新的文件”之類的沖突策略選上。保存任務就建好了。第一輪建議手動點一次“立即運行”盯著它跑完別直接丟給定時任務。5.2 參數(shù)實測并發(fā)、分片、限速分別怎么影響結(jié)果我拿一個 12GB 的目錄照片加視頻約 8000 個文件其中 30 個超過 500MB做了三輪對比記錄如下輪次并發(fā)數(shù)分片大小限速結(jié)果第一輪3默認默認不限總耗時 3h20m30 個大文件里有 6 個失敗日志報超時第二輪2加大一倍不限總耗時 3h05m只有 1 個失敗整體反而更快第三輪2加大一倍夜間不限、白天 2MB/s夜間跑完 11.6GB白天無感知第一輪的結(jié)果很有意思并發(fā)高反而更慢。原因是大文件在并發(fā)搶占帶寬的情況下每個連接都拿不到足夠的時間片最容易在接近完成時超時中斷然后從頭重傳白燒帶寬。降到 2 之后單個連接能穩(wěn)定拿到一半的上行帶寬反而是最優(yōu)解。分片大小分塊上傳的塊大小這個參數(shù)調(diào)整的依據(jù)是文件體積分布。如果你的文件大多在幾十 M 以下默認值就行如果有一堆幾百 M 到幾個 G 的大文件把分片調(diào)大能減少請求次數(shù)降低被限流的概率。但如果分片調(diào)得太大單次請求超時的時間也會變長網(wǎng)絡不穩(wěn)時反而容易失敗。加大一倍是個比較保險的起點。限速這個設置純粹是為了家庭和睦。我家是百兆下行、五十兆上行晚上八點到十一點是全家刷視頻的時間這時候同步任務把上行占滿視頻通話就會卡。所以我設了白天限速 2MB/s、夜間00:00-07:00不限任務也安排在凌晨兩點。順便把帶寬的賬算一下方便你預估時間。假設你每天新增 15GB 數(shù)據(jù)上行 50Mbps 換算成字節(jié)是 6.25MB/s理論耗時 15×1024÷6.25 ≈ 2458 秒約 41 分鐘。但實際傳輸效率能到理論值的 30%~50% 就算不錯了TCP 開銷、服務端限流、小文件尋道都會吃掉時間所以真實耗時大概在 1.5 到 2.2 小時之間。這個量級放凌晨跑完全無感。5.3 首輪跑通后的校驗別只看“同步完成”任務跑完界面上會顯示一個綠色的勾和“同步完成”。別信這個自己驗一遍。第一步比對文件數(shù)量和總大小。在 NAS 上du -sh /volume1/cloud-bridge/photos看一下總量再去網(wǎng)頁端的云端目錄看“屬性”里的統(tǒng)計兩個數(shù)字應該很接近。差得多就說明有文件被跳過了。第二步看日志里的“已跳過”列表。這是最有價值的信息。跳過原因通常有三類文件名含非法字符、文件大小為 0、權(quán)限不足。前兩類需要手動處理第三類說明你的sync-bot權(quán)限配得不對。第三步抽查幾個大文件的完整性。挑三五個最大的文件在 NAS 上算一下哈希md5sum 文件名然后從云端下載回來再算一次兩個值一致才算真的傳對了。傳輸過程中連接中斷導致文件被截斷、但同步套件仍然標記成功的情況我遇到過不止一次。第四步觀察下一天的增量。第二天只改了三個文檔跑一輪看日志里是不是只傳輸了這三個文件。如果它把整個目錄重傳了一遍說明索引沒生效通常是時間不同步或者文件的 mtime 被別的東西改動了。6. 常見問題與排查實錄6.1 連接與鑒權(quán)類問題速查這一類占了所有問題的七成以上基本都是配置層面的小錯?，F(xiàn)象最可能的原因處理辦法401 未授權(quán)用了主登錄密碼而不是應用專用密碼回網(wǎng)盤重新生成應用密碼403 禁止訪問賬號權(quán)限不足或該接口未對本賬號開放確認開放接口開關已打開、賬號狀態(tài)正常404 未找到地址路徑多了或少了斜杠、路徑層級不對原樣復制官方給的地址別自己改連接超時出站 443 被攔或 DNS 解析失敗在 NAS 終端curl -I 地址測連通性證書不受信任服務端證書鏈不完整或本地 CA 庫太舊更新系統(tǒng)根證書別勾“忽略證書錯誤”421 或協(xié)議錯誤客戶端用了過時的 TLS 版本在同步套件里把最低 TLS 版本提到 1.2重點說最后一條。老版本 NAS 系統(tǒng)默認允許 TLS 1.0/1.1而現(xiàn)在的云服務基本只接 1.2 以上。表現(xiàn)是連接過程卡在“正在握手”然后報一個看不懂的 SSL 錯誤。排查方法是在電腦上openssl s_client -connect 域名:443 -tls1_2如果通了但 NAS 上不通那百分之百是 TLS 版本問題去系統(tǒng)設置里改。6.2 同步邏輯類的坑重復上傳、刪除傳播、垃圾文件重復上傳是最常見的“玄學問題”。表現(xiàn)是同一個文件每天都被重新傳一遍日志里明明寫著“同步完成”但流量一直跑。根本原因是修改時間對不上。三個檢查點NAS 的系統(tǒng)時間準不準、云端返回的 mtime 精度夠不夠有些服務只精確到秒、同步套件有沒有開“按修改時間判斷”而不是“按文件大小判斷”。刪除傳播前面提過。單向任務沒這個問題雙向任務必須重視。我的做法是如果確實需要雙向先在云端建一個_trash目錄把同步套件的“刪除操作”設成“移到指定目錄”而不是直接刪。這樣誤刪的東西還有得救。垃圾文件污染是 NAS 用戶最容易忽略的。你同步photos目錄上去結(jié)果云端多出一堆eaDir文件夾里面是幾百張小縮略圖配額嘩啦啦地掉。解決辦法就是在文件過濾里把這些目錄名加進去。除了eaDir還要排掉#recycle、.thumbnail、.DS_Store、Thumbs.db、*.tmp、*.part。還有一個隱藏的坑文件名里的特殊字符。NAS 上合法的文件名到了云端可能不合法。典型的是\ / : * ? |這幾個還有以點開頭或結(jié)尾的文件名。同步套件遇到這類文件會跳過并記一條日志不會報錯中斷所以你如果不去看日志永遠不知道有文件沒傳上去。我的處理辦法是同步前先在本地跑一遍重命名把特殊字符替換掉。6.3 性能、配額與長時間運行的問題速度突然變慢或者報 429。這是被限流了。處理方式是立刻停掉任務等半小時到一小時再開同時把并發(fā)降到 1把分片調(diào)大。事后回顧一下是不是最近把定時任務改成了每小時一次是不是同時跑了好幾個同步任務把頻率降下來問題自然消失。大文件傳到 90% 中斷。兩個原因網(wǎng)絡抖動或者服務端對單次請求有時長限制。前者靠調(diào)小分片每片傳完就落盤中斷了只重傳一片緩解后者看服務商的文檔有沒有相關說明。我遇到過一次 4GB 的虛擬機鏡像反復失敗最后是把分片調(diào)到較小值、并發(fā)降到 1 才過去。配額滿了。表現(xiàn)是傳輸中途報錯或者文件顯示大小不對。去網(wǎng)頁端看看已用容量。這里有個陷阱云端的刪除是進回收站的回收站也占配額。你以為刪了十個 G其實一個字節(jié)都沒釋放得去回收站里再清一次。任務突然全部失敗日志一片紅。先看是不是網(wǎng)盤那側(cè)改了接口地址或者強制更新了密碼策略。這類變化服務商不會專門通知你只能靠失敗告警發(fā)現(xiàn)。所以我在同步套件里把郵件通知打開了任務連續(xù)失敗三次就發(fā)信比每天手動看要省心。7. 長期運行的幾條經(jīng)驗7.1 定位成“異地冷備層”而不是“網(wǎng)盤替代品”這套方案最舒服的用法是把云端當成一份“平時用不到、出事能救命”的副本。我給它定的規(guī)矩是只放三類東西——照片視頻原始素材、重要文檔的月度歸檔、代碼倉庫的打包快照。不放的東西也很明確臨時下載的文件、正在編輯的大工程、頻繁改動的配置文件。為什么因為這三類東西的共同特點是“寫一次、讀很少、丟了很痛”正好是冷備的定義。而臨時文件放進同步目錄會導致同步任務頻繁觸發(fā)白白消耗請求次數(shù)和帶寬。我一開始圖省事把整個工作目錄都扔進去了結(jié)果一天之內(nèi)同步套件跑了四十多輪網(wǎng)盤那邊直接給我限流了半天。按目錄分頻率是個好辦法。照片目錄一季度動一次我給它設了每周同步文檔目錄天天變設每天歸檔目錄基本不動設每月。這樣總體上請求次數(shù)少被限流的概率低。7.2 監(jiān)控、告警與定期恢復演練無人值守的東西最怕的是“悄悄壞了你不知道”。我做了三層保障。第一層是同步套件自帶的郵件通知勾選“任務失敗時通知”收件箱設成一個你?？吹摹５诙邮敲總€月手動去網(wǎng)頁端看一眼目錄大小和最后修改時間對不上就立刻查。第三層是我認為最重要但幾乎沒人做的每季度做一次恢復演練。具體做法是隨便挑一個月的照片目錄從云端完整下載回本地的一個臨時目錄對比文件數(shù)和總量抽查幾張照片能不能正常打開。聽起來很傻但這是唯一能證明“備份真的可用”的方法。我第二次演練時就發(fā)現(xiàn)有一批 2023 年的照片在云端是 0 字節(jié)原因是那次同步時硬盤剛好有壞道讀出來的就是空文件同步套件照傳不誤。要不是演練這批照片就真的只剩個文件名了。7.3 哪些情況下該果斷放棄這套方案不是所有場景都適合。遇到下面幾種情況趁早換思路別硬扛。同步量超過免費容量。這是硬墻。你的數(shù)據(jù)一直在漲云端配額是固定的。一旦超過任務會一直失敗而且失敗得很難看傳一半斷掉留下殘缺文件。我的做法是提前設一條線容量用到 80% 就啟動清理或者停止同步不讓它撞墻。需要多人協(xié)作或者多端實時編輯。WebDAV 這套東西本質(zhì)是文件搬運沒有版本控制沒有鎖機制。兩個人在同一個文件上改最后就是互相覆蓋沖突文件堆一地。這種需求應該用真正帶版本管理的方案。需要在線預覽、秒傳、分享鏈接。這套方案提供不了因為它只是把文件推上去了走的是接口而不是網(wǎng)盤的原生功能。你就當它是個“便宜的大硬盤”別指望它有客戶端的體驗。家里上行帶寬太小。如果上行只有 10Mbps1.25MB/s同步 100GB 要跑將近一天一夜。這種情況下與其折騰自動同步不如定期手動拿移動硬盤拷一次再找機會傳上去反而省心。8. 我個人在實際操作中的幾點體會這套東西我陸陸續(xù)續(xù)調(diào)了小半年中間推倒重來過兩次。最深的體會是別追求一步到位先讓最小閉環(huán)跑起來。我一開始就想著把整個存儲池都同步上去參數(shù)調(diào)了又調(diào)結(jié)果一個都沒跑通。后來砍到只同步一個 2GB 的測試目錄一次就通了然后再逐步加目錄、調(diào)參數(shù)反而快。第二個體會是日志比界面誠實。同步套件的界面上那個綠勾只代表“這一輪沒有致命錯誤”不代表“所有文件都傳上去了”。真正有用的信息全在日志的“已跳過”“已忽略”列表里那些安安靜靜沒報錯的文件才是最容易丟的。第三個是給同步留出“不完美”的空間?？绻W(wǎng)傳文件丟一兩個文件、傳錯一兩個文件是常態(tài)。所以關鍵數(shù)據(jù)永遠要保留兩份以上云端那份只是其中一層不能當唯一。我現(xiàn)在是本地硬盤一份、NAS 一份、云端一份三層里任意一層出問題都不致命。這也算是這套方案帶給我最大的改變——不是為了省那點容量費而是養(yǎng)成了一個“數(shù)據(jù)總得有個異地副本”的習慣。最后分享一個小技巧如果你也在用這套方案可以在同步目錄里放一個幾十字節(jié)的README.txt寫上這個目錄的用途、最后更新時間、以及“云端副本僅供災備請勿在此目錄直接編輯”之類的提示。聽起來很無聊但半年后你自己回來看的時候會感謝當時寫下的這句話。