在小團隊裡，災難復原通常只剩下一份從來沒人打開過的文件裡的一行字：備份已經開啟。這句話本身沒有錯，卻算不上任何問題的答案，因為它既沒有說明真正出事時救回來的資料會有多舊，也沒有說明還原一次要花多久，更沒有說明到今天為止究竟有沒有人完整地做過一次還原。

擁有備份和真的能復原之間存在一段明顯的距離，多數的服務中斷正是在這段距離裡升級成事故。一份存在、內容也夠新、卻從來沒有被還原過的備份，本質上仍然只是一個假設；而你第一次驗證這個假設的時刻，剛好是發現它其實是錯的最糟糕的時刻。

兩個數字能把意見變成計畫。 你承受得起丟多少資料，又承受得起停多久？這就是你的復原點目標與復原時間目標。只要營運那一側沒有人把這兩個數字說出口，關於備份頻率的一切技術爭論都收不了尾，因為根本不存在可以用來判斷對錯的標準。

用白話講清楚 RPO 與 RTO

復原點目標，也就是 RPO，指的是你允許遺失的資料量。只做夜間備份，代表 RPO 是 24 小時：下午 17 點出事，從前一晚到出事之間產生的一切都會消失。如果這個結果無法接受，那麼錯的是備份排程本身，在其他地方再怎麼細心打磨，都補不回這一段損失。

復原時間目標，也就是 RTO，指的是你允許停機的時間長度。它包含全部環節：發現異常、做出決定、準備資源、執行還原、驗證結果，以及把流量切回來。很多團隊只估算還原這一步，忘掉了另外五步，這正是真實復原往往比預期多花好幾倍時間的原因。

這兩項都是營運決策而不是技術決策，而且指標訂得越嚴格，要花的錢就越多。RPO 訂在 5 分鐘，就需要持續複寫。RTO 訂在 1 小時，就需要一套能自動重建的基礎架構，因為在高壓之下沒有人能在一小時之內用手工把一台伺服器設定完。

真正有產出的對話是關於取捨的對話。把每一個等級各自的成本告訴營運方，讓他們來選，而不是在工程這一側自己訂一個數字，然後祈禱這個數字剛好符合那些從來沒有被說出口的期待。

沒演練過的備份不算備份

真正讓人痛的失敗，很少是因為沒有備份。多數時候痛的是那些在最需要的時刻才發現根本用不了的備份。

常見的原因如下，而且全都要等到還原時才會現形：因為沒有人像盯失敗那樣盯著成功，工作已經安靜地失敗了好幾週；匯出檔只抓到結構描述卻沒有抓到資料，或者只抓到一部分資料表，因為有人在很久以前把其餘的加進了排除清單；檔案確實加密了，可是金鑰偏偏就放在那台已經掛掉的機器上；備份和它本該保護的對象放在同一個帳號、同一個區域裡。

最後一條在今天的分量比過去重得多。和正式環境放在一起的備份，只擋得住硬體故障，除此之外什麼都擋不住。它撐不過帳號遭入侵，撐不過帳號層級的誤刪除，也撐不過那種同一組認證資訊碰得到什麼就加密什麼的勒索軟體。

想知道一份備份到底能不能用，唯一的辦法就是真的還原一次。把這件事排進行事曆，至少每一季做一次，而且每次都計時。量出來的這個時間才是你真正的 RTO，而不是文件裡寫的那個數字。

災難復原必須涵蓋哪些東西

資料是所有人第一時間想到的部分，卻很少是拖慢復原的部分。真正把復原拖長的，幾乎總是那些沒有人列進清單的東西。

資料庫，這個所有人都記得。使用者上傳的檔案，通常單獨放在別處，而且往往根本沒有任何備份。設定與密鑰，很多時候只存在於正在運行的那台機器上。DNS 與憑證，如果保管它們的帳號剛好就是你弄丟的那一個，短時間內根本重建不出來。基礎架構本身，也就是伺服器、網路和各類規則，如果用程式碼定義過就能很快重建，如果是靠在管理介面上一路點出來的，那就慢得讓人痛苦。

還有關於這一切如何拼在一起的知識，在小團隊裡這是決定復原時間的最大單一因素。一套只有一個人能憑記憶重建的系統，它的復原時間就等於那個人有沒有空，而這稱不上是計畫。

先寫清單，再寫計畫。多數團隊在列清單的過程中，就會找到至少一個完全沒有備份的元件；用這種方式找到它，比用另一種方式便宜太多。

一頁就寫得完的計畫

事故正在進行的時候沒有人會去讀長文件。你要瞄準的是一份疲憊的人在凌晨三點也能照著做、而且不需要動腦筋的東西。

它需要包含：由誰宣布復原已經開始，因為在這到底算不算災難這個問題上猶豫，是最常見的延誤來源之一；備份放在哪裡、怎麼取得，包括一組不依賴已經倒下的系統的認證資訊；按順序排好的還原步驟，具體到不必臨場發揮就能照著執行；如何驗證真的成功了，也就是一項具體的檢查，而不是網站看起來打得開這種感覺；以及對內和對外分別該通知誰。

把它放在一個能在故障中存活下來的地方。只存在於它要復原的那套系統裡的復原計畫，是一種反覆出現、而且完全可以避免的錯誤。

同樣的道理也適用於存取權限。如果只有一個人掌握主機帳號的認證資訊，你的復原時間就取決於這個人接不接電話。我們的 Linux 伺服器強化指南 談的正是這一切所仰賴的存取控制。

合乎規模，而不是追求完美

小團隊不需要在第二個區域擺一套熱備援。成本是實實在在的，而多出來的複雜度本身又會帶來新的故障方式。

多數小團隊真正需要的東西便宜得多：放在獨立帳號裡、用正式環境無法使用的認證資訊存取的備份；按固定週期演練並計時的還原；用程式碼定義、不必考古就能重建的基礎架構；以及一份確實有人讀過的一頁式計畫。

這一組東西涵蓋了硬體故障、誤刪除、帳號遭入侵和勒索軟體，而現實中發生的事情大部分就是這幾類。超出這個範圍的部分，是在判斷再進一步縮短停機時間到底值多少錢，而這個問題應該由營運方回答，不該由工程這一側回答。

Mecanik 在伺服器安全分析 服務中會檢視並建置以上這些內容。第一個問題永遠一樣，而且跟技術無關：你能停多久，以及這個數字是誰決定的？

相關文章: 真正有意義的可用性 SLA 、小團隊的軟體供應鏈安全 、企業 AI 代理人：成本與失敗之處 、英國金融科技軟體開發：FCA、支付軌道與成本 。

常見問題

RPO 與 RTO 是什麼意思？ 復原點目標是你承受得起遺失的資料量，所以只做夜間備份就代表 RPO 是 24 小時。復原時間目標是你承受得起停機的時間長度，包含發現異常、做出決定、準備資源、執行還原、驗證結果以及把流量切回來。兩者都是營運決策，而且指標訂得越嚴格，成本就越高。

為什麼沒演練過的備份不算備份？ 因為這些故障型態只有在還原時才會現形。沒有人像盯失敗那樣盯著成功，工作就會安靜地失敗好幾週；匯出檔可能只有結構描述而沒有資料，或者漏掉被排除的資料表；加密金鑰就放在那台已經掛掉的機器上；副本和它保護的對象放在同一個帳號裡。請每一季還原一次，而且每次都計時。

備份應該放在哪裡？ 放在獨立的帳號或區域裡，並且使用正式環境無法使用的認證資訊。放在同一個環境裡的備份只擋得住硬體故障，除此之外什麼都擋不住：它撐不過帳號遭入侵，撐不過帳號層級的刪除，也撐不過那種同一組認證資訊碰得到什麼就加密什麼的勒索軟體。

災難復原裡大家最容易漏掉什麼？ 與資料庫分開存放的上傳檔案、只存在於運行中機器上的設定與密鑰、保管在一個本身也可能弄丟的帳號裡的 DNS 與憑證、靠滑鼠點出來而不是用程式碼定義的基礎架構，以及只有一個人掌握的、關於這一切如何拼在一起的知識。

小團隊需要熱備援嗎？ 通常不需要。成本是實實在在的，多出來的複雜度也會帶來它自己的故障方式。放在獨立帳號裡的備份、演練過並計過時的還原、用程式碼定義的基礎架構，再加上一份確實有人讀過的一頁式計畫，就能涵蓋硬體故障、誤刪除、帳號遭入侵和勒索軟體，也就是現實中發生的絕大部分情況。