備份真正的能力是「出事時還原得回來」，不是「有沒有在備」。這推翻了對備份最常見的誤解：以為「有排程在跑 backup」就安全了。還原能不能成功，只有真的試過才知道。

為什麼「沒測過還原的備份等於沒有」

備份會無聲地失敗：排程壞了沒人發現、備出來的檔案是空的或損毀、備了但少備了關鍵那張表、加密備份的金鑰弄丟了解不開。這些在你「需要還原」的那一刻才會爆——而那一刻通常是最糟的時刻（資料已經沒了）。

所以該有的紀律是：定期真的做一次還原演練——把備份拉到一個乾淨環境、還原、確認資料完整、app 接得上。演練同時量「還原花多久」——一份要跑半天才還原完的備份，對某些服務等於不可用，這個還原耗時就是還原時間目標（RTO）。演練過的備份才是資產，沒演練過的只是「你以為有」的安全感。各資料庫的還原演練實作見 vendor drills，如 PostgreSQL PITR 演練、MySQL 備份還原演練。

該備什麼、不該備什麼

備份的對象是「弄丟了重建不回來的東西」，不是全部：

• 要備：資料庫內容、使用者上傳的檔案、以及不在版控裡的 secret / 設定值來源（依十二要素 secret 不簽進 git、第三方 key 撤了就撤了，重建不回來）——這些是唯一副本，沒了就真沒了。
• 不用備：你的 app code（在 git 裡）、container image（在 registry 這個 image 倉庫裡）、能重跑一次就長回來的東西。這些有別的來源，備份它們是浪費。

判準：問「這東西弄丟了，我能不能從別的地方重建？」能 → 不用備；不能 → 要備。這也呼應十二要素的「process 無狀態、資料放外面」——正因為狀態集中在少數幾個地方（DB、物件儲存），要備份的範圍才清楚。

幾條地基原則

• 多久一次，看你賠得起丟多少：每天備 = 最多丟一天的資料。丟一天能接受就每天；不能接受就要更頻繁、或用能還原到任意時間點的機制（point-in-time recovery）。這個「能容忍丟多少」就是還原點目標的白話版。
• 備份別跟正本放一起：跟資料庫放同一台機器的備份，機器掛了兩個一起死。要放到不同機器 / 不同區域 / 不同供應商。常見的口訣是「3 份副本、2 種媒介、1 份異地」。
• 舊備份要留一段時間：只留最新一份的問題是——如果資料是幾天前就悄悄壞了、才發現，你最新的備份也已經是壞的。留一段歷史才能還原到「壞掉之前」。

這也是「自架 vs 託管」的一個關鍵差異

託管資料庫（RDS / Cloud SQL）把上面這些大部分自動化了：自動排程、異地儲存、point-in-time recovery、還原按幾個鍵。自己在 VPS 上跑 DB，這些全是你的工作——這正是自架 vs 託管那筆「帳單外成本」裡最重的一項。常被低估的就是這塊：DB container 跑起來很容易，備份、測還原、異地、保留策略才是難的部分。

下一步

備份是你自己顧任何有狀態元件時的底線。往上，接手一個別人留下的環境時，第一件事往往就是盤點「它到底有沒有能還原的備份」——見 Infra 接手：舊資料庫備份與遷移。

備份是自己顧任何有狀態元件的底線。往上的深度內容見各系列：服務選型理論 Backend 模組零、雲端地基 Infra、運維與成本 DevOps。