伺服器備份到底該怎麼做？從"備了"到"能恢復"差多遠

伺服器出事，最讓人崩潰的從來不是"沒有備份"，是"明明備了，恢復的時候才發現不管用"。

盤壞了，翻出備份一看，和壞盤在同一個機櫃的同一臺機器上，一起走的；中了勒索，備份目錄因為和線上保持同步，被一起加密了；資料庫壞了，dump 檔案拉出來是半年前的——備份任務早就靜默失敗了幾個月，沒人知道；最冤的一種：備份好好的，恢復步驟沒人說得清，試著恢復了四個小時還沒起來，業務乾等著。

備份這件事，90% 的功夫花在"備"上，可它的價值 100% 體現在"恢復"上。這篇文章就把災備這件事按實戰的順序講清楚：備什麼、怎麼備、放哪裡、怎麼驗證——每一步都是能落地檢查的。

一、先想清楚兩個數：能丟多少，能停多久

動手之前先回答兩個問題，答案決定了備份方案怎麼做：

第一個：能接受丟多少資料？是丟一天可以接受，還是最多丟一小時？資料庫裡掛著客戶訂單和生產記錄，多數廠子的答案是"最多丟十幾分鍾到一小時"。這個答案直接決定備份頻率——天天備一次的方案，最壞情況要丟一整天的資料，和"最多丟一小時"的要求對不上。

第二個：能接受停多久？業務系統癱了，半天內恢復可以嗎？還是要分鐘級拉起？答案決定方案裡要不要留"最後一道底牌"（比如整盤映象、隨時可切換的備用機）。

把這兩個數寫在紙上，備份方案就不容易跑偏。所有後面講的方法，都是圍繞"丟得起多少、停得起多久"這兩個約束來配的——脫離這兩個數談備份，容易變成"天天全量拷一遍"的自我安慰。

舉個常見的取法，對上了就對號入座：一家二三十人的機械加工廠，業務系統是訂單、工單和生產記錄，老闆的底線是"丟一上午的資料沒法向客戶交代，停一天生意沒法做"。倒推出來就是：資料庫至少每小時留一個恢復點（上日誌歸檔），檔案資料每天同步一次，整機故障時四小時內恢復（所以要有另一臺能頂上的機器和一份夠新的備份）。這兩個數定了，後面每一層方案都是在兌現它們——備份頻率、保留策略、演練週期，全部跟著這兩個數走。反過來，如果一家廠的答案是"這批資料丟了可以重新錄，停三天也無所謂"，那方案可以簡單到每週一份全量加一份異地，沒必要上重灌備。方案沒有標準答案，只有和業務對不對得上。

二、備份什麼：資料、配置，還有那些容易漏的

很多廠的備份只做了一件事：把資料庫導一份。等真要恢復的時候，才發現缺的東西一籮筐。一份完整的清單要分三類：

第一類：業務資料——最核心，但備法有講究。

資料庫必須用官方匯出工具做邏輯備份（PostgreSQL 用 pg_dump，MySQL 用 mysqldump），不要直接複製資料目錄。資料庫在執行時資料檔案處於不斷變化的狀態，直接拷下來的是一份"前後不一致"的檔案，恢復時輕則報錯重則起不來。要物理級備份，也得先做快照凍結再拷（後面講）。

除了資料庫，還有檔案類資料：上傳的圖紙、附件、圖片。這些通常散在某個目錄下，逐個確認、列進清單。

第二類：配置——丟了最耗時的一類。

系統裝回來只要一小時，但配置調回來可能要三天。要備份的有：/etc 下改過的配置（nginx、防火牆規則）、crontab 定時任務、systemd 自定義服務單元、SSL 證書和私鑰、SSH 的 authorized_keys、應用的配置檔案和環境變數（注意：含密碼的檔案要加密存放）。

第三類：執行環境——恢復提速的關鍵。

程式碼的版本、執行時版本、依賴清單、容器編排檔案。恢復的時候最怕"裝了個新版本，跑不起來"，把版本資訊記下來（或用容器固化），恢復時間能省一大半。

反過來說，也有些東西不用備：日誌（留夠時長即可）、快取、臨時檔案。清單分清輕重，備份的體積和耗時才控得住——這也是很多廠的備份任務最後因為磁碟撐爆而悄悄失敗的原因。

三、怎麼備：方法選對，別拿一把錘子擰所有螺絲

1. 全量和增量的搭配。

全量備份恢復最簡單（一份檔案搞定），但體積大、耗時長；增量只備份變化，省空間，但恢復時要按順序疊加。實戰裡的常見搭配是：每週一次全量 + 每天增量，保留策略用階梯——最近 7 天都有、最近 4 周每週留一份、最近 12 個月每月留一份。保留多份的意義不止是防丟，更是防"壞版本覆蓋好版本"：資料某天被誤刪了，第二天備份把"刪完的狀態"覆蓋上去，如果只有一份備份，錯誤就成了永久。

2. 檔案級同步：rsync。

目錄類資料（附件、配置、程式碼）的主力工具。增量傳輸、可排除指定目錄，配合 --link-dest 引數還能做出"每天一份快照、但重複檔案不佔空間"的效果。注意一條：rsync 的 --delete 引數慎用——線上誤刪了檔案，帶 --delete 的同步會把備份裡的也刪掉，這就是"同步盤不是備份"的典型翻車點。

3. 資料庫的一致性：先快照再拷。

既要物理級速度、又要一致性，用 LVM 快照（或雲盤快照）：先給卷打快照，把資料庫"凍"在一個一致的時間點，再從快照裡拷。資料庫另有細法：開啟 binlog/WAL 歸檔後，定時 dump 加上日誌回放，可以恢復到一天的任意時刻——這對"誤刪了一張表想找回"的場景是救命的。

4. 整盤映象：最後的底牌。

dd 整盤映象能在新硬碟上原樣復原整個系統，適合作為低頻的兜底（比如每季度一次），不適合天天做——慢、佔空間，而且系統在執行時映象同樣有一致性問題，要在維護視窗或配合快照做。

5. 雲伺服器的快照：方便，但別隻靠它。

雲平臺快照一鍵開啟，確實省事。但要看清它的邊界：快照通常和主機在同一個雲賬戶、同一個地域裡——賬戶被盜、地域級故障、快照策略被誤關，快照就一起沒了。雲快照可以作為方案的一層，不能是全部。

6. 自動化與告警：靜默失敗最危險。

所有備份任務交給 crontab 或 systemd timer 定時跑，但必須配告警：任務失敗、輸出檔案比預期小很多、連續幾天沒有新檔案，都要能主動通知到人。一個沒人盯的備份任務，失敗三個月是常態——開頭說的"dump 是半年前的"就是這麼來的。

把這些拼起來，一套典型的小廠方案大概長這樣：

凌晨一點，資料庫定時匯出（全量 dump），導完檢查檔案大小是否符合預期，異常就發通知；凌晨兩點，檔案目錄增量同步到備份機，只增不刪；凌晨三點，把當夜的 dump 和變動檔案推到異地物件儲存，開版本控制；每週五，拷一份當週全量到離線硬碟，拔下鎖櫃；每月第一個週六，輕量演練：把最近的 dump 在測試環境導一遍，看資料對不對；每季度，完整演練：另起一臺機器，從備份把整套系統恢復起來，記錄耗時。

一行任務清單貼在伺服器邊上，每一步誰負責、失敗了找誰，寫得清清楚楚——災備這件事的全部難度，其實不在技術，在於有人對它負責、有人定期看它一眼。

四、存哪裡：3-2-1 原則和防勒索

3-2-1 一句話講完：重要資料留 3 份副本，放在 2 種不同介質上，其中 1 份在異地。

落到小廠的實況，大概是這樣：

第 1 份：本機另一塊盤/另一目錄——防手滑誤刪，防不了整機故障；第 2 份：另一臺機器（同機房的備用機或 NAS）——防單機故障；第 3 份：異地——同步到另一臺異地伺服器，或推到物件儲存（rclone 一條命令的事，成本一個月幾塊錢）。

防勒索是 3-2-1 的靈魂，兩條硬規矩：

其一，備份賬號的許可權要單向。線上機器往備份端寫資料可以，反過來備份端對線上"只增不刪"——勒索軟體拿到線上機器的許可權後，第一件事就是順著連線把備份一起加密或清掉。物件儲存開版本控制、備份目錄許可權收緊、備份賬號不給刪除權，都是這個思路。

其二，留一份夠不著的。定期（比如每週）把關鍵資料拷到一塊離線硬碟上，拷完拔下來鎖櫃子裡。離線介質是勒索軟體和誤刪都夠不到的終點——它不聯網、不掛載，誰也加密不了它。

五、沒驗證過恢復的備份，等於沒有備份

這是整篇文章最重要的一節。

備份檔案躺在那裡，不代表能恢復。檔案損壞、密碼失傳、版本對不上、缺了證書、恢復步驟沒人會——每一種都得在真出事前發現。所以要定期做恢復演練，做法不復雜：

第一步，選個低峰期，找另一臺機器（哪怕是臺舊電腦或臨時開的雲主機），把最近一份備份完整恢復一遍。

第二步，恢復完真把系統拉起來：服務能啟動、頁面能開啟、登入進得去。

第三步，抽查資料：看最新的記錄在不在、對不對——恢復到三天前的資料是"技術上成功、業務上失敗"。

第四步，記錄耗時：從開始恢復到業務可用花了多久，這就是你真實的"停機時長"。平時演練要兩小時，出事時只多不少——心裡有這個數，才知道該把演練週期縮短還是方案加碼。

演練十有八九會暴露問題，常見的有：dump 檔案其實早已損壞、資料庫密碼只有離職員工知道、新版本依賴和老備份對不上、證書私鑰沒備份過。每一個問題在演練裡發現，成本是一下午；在事故里發現，代價是業務停幾天。

最後，把恢復步驟寫成一張紙：按什麼順序起哪些服務、密碼和金鑰放在哪、找誰確認。半夜出事的時候，沒人有空翻五十頁文件。

給沒做過演練的廠一個預期：第一次演練幾乎必然卡殼，而且卡的往往不是備份檔案本身。常見的是這一串——拿到備份檔案後發現解壓密碼只有離職網管知道；資料庫導進去了，應用連不上，因為配置檔案裡寫的還是老機器的地址；服務起來了，頁面打不開，證書私鑰沒備過；終於都通了，一查資料，恢復到的是五天前的備份，中間四天的備份任務早失敗了。一整串問題暴露下來，一下午就過去了——但這恰恰是演練的價值：這些雷，每一個都可能在真出事的那天把恢復時間從小時級拖成天級。第一次演練過後，把暴露的問題逐條修掉，第二次就會順很多；到第三次，兩小時內從零恢復到業務可用，這套備份才算真正立住了。

六、最常見的幾個誤區

"備份放在伺服器另一塊盤上就安全了。"機器被偷、主機板燒了、勒索加密整個系統，另一塊盤一起沒。副本必須在另一臺機器上。

"雲主機開了快照就不用做備份了。"快照在同賬戶同地域，賬戶失守或誤操作都可能一起沒；而且快照不等於可獨立拉起的恢復點。快照是一層，不是方案。

"備份任務還在跑就說明沒問題。"任務在跑不等於備份成功——磁碟滿了它可能天天失敗，匯出檔案可能只有幾百位元組。要看結果和告警，不看任務存在。

"把資料目錄拷一份就是備了資料庫。"執行中的資料庫直接拷檔案，恢復時大機率起不來。用官方匯出工具，或先快照再拷。

"同步盤/網盤就是備份。"同步是映象：線上誤刪、被加密，同步端跟著變。同步可以有，但必須另有版本化的、單向的備份。

"保留越多份越好。"沒有階梯策略的無限保留，最後磁碟撐爆、任務失敗，反而害了整個備份體系。按 7 天/4 周/12 月的階梯來。

"等這陣子忙完再弄備份。"備份的價值在出事前就體現——你永遠不知道出事是哪天，而資料壞了沒有"下一次"。

七、這事可以交給專業的人做

災備搭建是典型的一次性短期專案：先按業務定"能丟多少、停多久"兩個數，再出方案（備什麼、怎麼備、放哪裡、保留策略），然後落地配置、做一輪完整恢復演練，最後交付一頁恢復手冊——有明確的起點和終點，做完驗收。

我們摩傑斯自己的核心業務系統（生產管理軟體）十四年來一直跑在 Linux 上，備份和恢復這套東西在幾百家制造客戶的現場一臺臺搭過、驗過。我們做災備就按本文的順序來：先定兩個數，再配三層副本，最後用一場真刀真槍的恢復演練收尾——備份靠不靠譜，不看備份了沒有，看恢復那天行不行。

想了解為什麼生產系統值得建在 Linux 上，可以看《系統為什麼從第一天就跑在 Linux 上》；半夜宕機怎麼分鐘級拉起，可以看《產線系統半夜宕機怎麼分鐘級拉起》；伺服器被黑了先做什麼，可以看《Linux 伺服器安全加固與入侵應急》——備份是那次處置裡"最後一道防線"的展開篇。災備搭建這類短期專案的服務範圍，見Linux 伺服器服務介紹。

結語

備份這件事，說穿了就是三句話：

備什麼想周全——資料、配置、環境三類列清單，資料庫用匯出工具不拷目錄；放在哪裡想清楚——3-2-1 分層，備份端單向可寫，留一份離線的；恢復這件事練過——沒演練過的備份等於沒有備份，演練發現的每個問題都是提前拆掉的雷。

伺服器和資料沒有"平安無事"的預設值，只有"出事那天你手裡有什麼"。備份是唯一一件現在做、將來才用得上，而且用得上時一切都來不及補的事——它值得排進這個月的日程，而不是躺在"等有空"裡。