同步不是備份：一則雲端災難教會的四層防線#
起因是一位使用者的雲端相簿從一萬五千多張變成五千多張、最後救不回來。他的結論很值得記住——這件事不能證明那家雲端不安全，因為在幾億使用者裡出一個案例，機率極低；但正因為誰都可能是那個萬分之一，所以「沒有絕對安全的備份方式，唯一能做的就是多備份幾份」。而最多人搞錯的一件事是：把檔案上傳到雲端然後刪掉本機，那不是備份，那是搬家。
往下讀之前先問自己 你現在最重要的那批檔案，實際上存在幾個互相獨立的地方？如果其中一份被誤刪，另一份會不會因為同步而跟著消失？
（預設關閉：點連結跳回原片體驗較好，也把流量還給原作者）
01
單一災難案例不能證明某家雲端不安全——分母是幾億人
strong
機轉：為什麼會這樣
面對「這證明了 iCloud 不安全」的說法，他的回應是不能。理由是使用者基數以億計，出現一個檔案遺失案例的比例低到難以計算。他也點名相反的謬誤——看到某家大廠當機就說「你看它就是爛」，那是見獵心喜而非分析。
實證查核
這是正確的統計素養：從單一顯著案例推論整體可靠度，屬於以軼事取代基本率（base rate neglect）。而顯著案例會被報導、無事發生不會被報導，使得可得性偏誤進一步放大感受到的風險。
查證來源
- 由單一案例推論整體屬基本率忽略
- 顯著事件的可得性偏誤放大風險感受
要補一句
但反方向也要小心：分母大不代表個別使用者的風險可忽略——對那個檔案全毀的人來說，機率是 100%。正確的推論是「不必因此換平台」，而不是「不必額外備份」。他接下來講的正是這一點，兩條要合起來讀。
可帶走的做法
看到「某某雲端出包」的新聞，先問這是系統性問題還是個案。是個案的話，該調整的是你的備份層數，不是你的服務商。
02
他的核心結論：沒有絕對安全的備份方式，唯一能做的是多備幾份
strong
機轉：為什麼會這樣
他把結論建立在自身經驗上而不是新聞事件：某天他發現一個資料夾裡的照片全部消失、只剩資料夾名稱，而垃圾桶、時光機備份、雲端的版本歷程通通找不到。從那次之後他的認知就變成——沒有任何單一手段是絕對的，能做的只有增加份數。
實證查核
這與備份實務的共識一致，也就是常被引用的 3-2-1 原則：至少三份副本、兩種不同媒體、其中一份異地。其邏輯基礎是各種失效模式（硬體故障、誤刪、軟體錯誤、災害、帳號問題）不會同時擊中彼此獨立的儲存。
查證來源
- 3-2-1 原則：三份副本、兩種媒體、一份異地
- 備份有效性取決於失效模式是否獨立
要補一句
關鍵字是獨立——多份副本若共用同一個失效路徑（同一顆硬碟的不同分割、同一個帳號下的多個資料夾、會即時同步的兩個位置），實際上仍是一份。這一點他在後面的建議裡有隱含處理，但沒有明講，而這正是最多人做錯的地方。
可帶走的做法
檢查你的備份時問一句：有沒有哪一個意外會同時毀掉兩份？答案是有的話，那兩份只能算一份。
03
他的親身經歷：資料夾裡的照片全消失，只剩下資料夾名稱
moderate
機轉：為什麼會這樣
他描述得很具體：檔案在雲端硬碟與磁碟陣列之間搬來搬去，某天發現一個資料夾裡的照片全部不見，只留下空的資料夾。三個救援管道全部落空——系統垃圾桶沒有、時光機備份沒有、雲端的版本歷程也沒有。
實證查核
這個失效樣態符合同步型儲存的典型風險：刪除或損毀會被同步傳播到所有連動位置，而版本歷程有保留期限，超過即無法回溯。頻繁在同步資料夾之間搬移檔案，正是最容易觸發此類問題的操作。
查證來源
- 同步型儲存會將刪除傳播至所有連動位置
- 版本歷程有保留期限，逾期無法回溯
要補一句
他沒有說明根本原因（片尾表示真相錄在付費會員影片裡），所以無法判斷是同步衝突、軟體錯誤還是操作失誤。這削弱了它作為技術案例的價值——知道「有可能消失」有用，知道「為什麼消失」才能預防，而後者被放在付費牆後。
可帶走的做法
重要檔案不要在同步資料夾之間搬移。要整理就先複製一份到不同步的位置，整理完再放回去。
04
銀行比喻：連銀行都會倒，而存款保障有上限
moderate
機轉：為什麼會這樣
他用金融的例子說明「相對安全」不等於「不會出事」：把錢放銀行確實比放床底下安全，但銀行倒閉時存款保障有理賠上限——存一億也只賠得到上限那個數。所以投資講的雞蛋不要放同一個籃子，同樣適用於備份。
實證查核
類比恰當：兩者都是「把風險委託給機構」的情境，而機構的可靠度再高也不是無限責任。存款保險確實有每人每機構的理賠上限，這個機制的存在本身就證明了機構會倒。
查證來源
要補一句
具體的保障金額會隨制度調整，引用前應查證當期規定；本站不列出數字以免過期。另外這個類比有一處不對稱：分散存款是為了規避單一機構倒閉，而備份要防的失效模式更多元（誤刪、勒索軟體、帳號被盜），分散的方式也需要對應不同威脅。
可帶走的做法
把備份當資產配置：問自己「哪一種災難會讓我全損」，再針對那一種補一層。
05
⭐⭐⭐ 最多人犯的錯：以為雲端是備份，上傳後就把本機檔案刪掉
strong
機轉：為什麼會這樣
他列舉過去雲端出事的案例時指出，多數其實是使用者造成的——最典型的就是把照片上傳雲端後，很開心地把手機裡的檔案全部刪掉；結果雲端上也沒有、手機也沒有，照片全部消失。
實證查核
這是備份觀念中最重要的一條區分：同步（sync）不是備份（backup）。同步的設計目標是讓所有位置保持一致，因此刪除、覆寫、加密勒索都會被忠實地複製到每一個位置；而備份的定義特徵是保留「過去某個時間點的狀態」，與現況脫鉤。上傳後刪除本機，只是把單一副本搬到別處，份數並未增加。
查證來源
- 同步將刪除與覆寫傳播至所有位置
- 備份的定義特徵為保留過去時間點狀態
- 雲端刪除通常有回收桶保留期限
要補一句
延伸提醒他沒說到：許多雲端服務的「刪除」有回收桶保留期（通常三十天），過期就真的沒了；而空間不足時的「最佳化儲存」會自動移除本機原檔只留縮圖，使用者往往不知道自己已經沒有本機副本。這兩點是實務上最容易踩的。
可帶走的做法
分辨同步與備份只要問一題：我在 A 刪掉檔案，B 會不會跟著消失？會的話，B 不是備份。
06
他給的層數建議：至少兩份以上，理想是四層
moderate
機轉：為什麼會這樣
他把建議拆成遞進的四層：第一層是裝置本身；第二層是對應平台的雲端備份（用哪家手機就開哪家）；第三層是自己的儲存，例如電腦或家用網路儲存裝置；第四層是異地備份，可以是放在別處的第二台機器，或另一家不同的雲端。
實證查核
這個層級劃分與 3-2-1 原則相容，且對一般使用者足夠具體可執行。特別是「用哪家手機就開哪家雲端」這個建議降低了設定門檻——原生整合的備份最不容易因為使用者忘記操作而失效。
查證來源
要補一句
但第一層（裝置本身）嚴格說不算備份，它是原始資料；把它算成一層會讓人高估自己的防護。真正的層數應從第二層起算。另外四層之中若有三層互相同步，實際的獨立副本仍然不足——層數要數的是獨立性，不是位置數。
可帶走的做法
數自己的備份時把原始檔排除，只數「就算原始檔沒了也還在」的份數。多數人數完會發現只有一份。
07
異地備份的具體做法：他在兩個城市各放一台，每天自動同步
strong
機轉：為什麼會這樣
他說明自己的配置：工作地點一台網路儲存裝置，另一台較入門的放在老家由家人保管，作為前者的備份。每天拍完影片上傳之後，資料會自動傳到另一個城市再存一份。他強調就算傳到一半掛掉，之前的備份都還在。
實證查核
異地備份要防的是區域性災害（火災、水災、竊盜、停電）——這類事件會同時摧毀同一地點的所有副本，無論份數多少。把第二份放在不同建築物是唯一有效的做法，而利用親友住處是成本最低的實作方式。
查證來源
- 區域性災害會同時影響同一地點的所有副本
- 即時鏡像會將誤刪與加密勒索傳播至異地
- 異地存放應考慮傳輸與靜態加密
要補一句
兩個要點他沒提：一是異地副本若採即時鏡像，誤刪與勒索軟體同樣會被同步過去，因此應保留版本或設定延遲；二是資料離開自己掌控範圍時的隱私考量——含個人或敏感資料者應先加密再傳輸與儲存。
可帶走的做法
異地那份要設版本保留或延遲同步。即時鏡像擋得住火災，擋不住你自己按錯的刪除鍵。
08
⭐ 同步延遲曾意外救了他：手機與雲端都沒了，某台電腦還沒同步完
strong
機轉：為什麼會這樣
他講了一次驚險經驗：手機上的檔案誤刪、雲端上的也跟著不見，結果剛好有一台電腦不知為何同步延遲、還留著舊狀態，照片才從那裡救回來。他因此建議電腦的儲存空間買大一點，讓照片能多同步幾個地方。
實證查核
這個案例精準示範了為什麼同步不等於備份：救回檔案的不是同步機制，而是同步的失效（延遲）。換句話說，那次能救回來純屬僥倖——如果同步正常運作，那台電腦上的檔案也會一起消失。
查證來源
- 同步位置共享同一失效路徑
- 版本保留機制可回溯至刪除前狀態
要補一句
所以他從中導出的結論（買大容量讓檔案多同步幾處）方向不對——多同步幾個位置並不增加防護，因為它們共享同一個失效路徑。正確的做法是設置不會自動同步的副本，或啟用具有版本保留的備份機制。這一條的價值在於它的故事，而非他的推論。
可帶走的做法
把「多開幾台裝置同步」換成「開啟版本歷史」。前者是多幾個複本，後者才是多一個時間點。
09
他把雲端定位成最初階的備份：那只是幼稚園等級
moderate
機轉：為什麼會這樣
他在結尾重申立場：即使是他最信任的那幾家大型雲端，也只能算是最基礎的一層，你仍然需要第二甚至第三個備份，才能確保檔案不會消失。他同時說明自己信任那幾家的理由是當機機率極低，而非它們不會出事。
實證查核
把雲端定位成起點而非終點，方向正確——雲端解決的是裝置遺失與硬體故障，但對誤刪、帳號問題與服務方錯誤的防護有限。要求額外層級是合理的。
查證來源
- 主流雲端服務通常跨地理區域做冗餘
- 雲端的主要風險在帳號層級而非硬體層級
要補一句
「幼稚園等級」有點低估了雲端的實際保障：主流服務通常在多個地理區域做冗餘，其硬體層面的可靠度遠高於一般家用設備。雲端的弱點不在硬體，而在帳號層級的單點失效（密碼外洩、誤刪同步、服務條款終止）。把它講成不可靠會誤導讀者往錯的方向補強。
可帶走的做法
補強雲端不必再買一朵雲。開啟兩步驟驗證、保留版本歷史、加一份離線副本，這三件事擋掉的風險最多。
本單元集中引用 1 支公開影片（2020-12-28），有官方字幕可查證時間碼。⚠️ 該影片前段有一段完整的自家商品出貨公告，且片尾說明「檔案消失那件事的真相」錄在付費會員影片中——公開版本只有結論、沒有細節，這與 T21〈為什麼音響界幾乎沒有對照比較〉第 6 條指出的模式一致。引句均在 15 字以內，僅作定位使用。