一台工作 Mac 的災備方案備份鏈設計、推送閘門與五輪獨立審查

這台 Mac 上有記憶與規則檔案、幾十個程式碼儲存庫、二十多個定時任務、網站原始碼、路由器設定和各類 API token。開發者會面臨兩個風險：

1. 如果 Claude Code、Codex 這類訂閱制 AI 帳戶被封，工作還能接上多少？
2. 如果這台 Mac 壞了或丟了，還能找回多少？

前提是 Apple ID、iCloud、信箱和手機號碼都還在。

第一個問題答案很短：記憶和規則都是本機純文字，Claude 與 Codex 兩套設定早已並行維護，換一個 AI 當天就能接著幹。本文討論的是第二個問題。

01 · 現狀審計

審計的原則是實測，不信記憶。記憶檔案裡寫著「每天自動備份到 GitHub」，這只能說明有備份，說明不了備份涵蓋了多少。所以需要逐項掃描：每個儲存庫有沒有遠端、有多少提交沒推、Time Machine 狀態、iCloud 同步範圍、每個備份腳本實際做了什麼。

按資產性質可以把這台 Mac 分成四層：

記憶與規則層本來就有每日推送；問題集中在程式碼、環境和憑證三層。

審計報告本身也出過錯：初版寫「磁碟使用率 13%」，複查發現那是 APFS 唯讀系統卷宗的數字，資料卷宗實際已用 80%。此後報告裡的每個數字都要求能對應到一條命令輸出。

02 · 備份範圍：按資訊密度劃分

初版建議是把 AI 對話原始紀錄和影片專案的積壓提交都推上雲。複核後改為按資訊密度劃分：

按這條規則重新計算：

• AI 對話原始紀錄按設計只留本機，不再算缺口；從中提煉出的知識庫每天推送。
• 影片專案的 58 個積壓提交裡混有 969 個影音和圖片檔案，約 496MB。剝離媒體後，需要推送的程式碼只有 6.9MB。
• 知識庫儲存庫在 GitHub 上佔 470MB，大部分是三個月前一次歷史瘦身時留下的備份分支，原計畫觀察一週後刪除，一直沒刪。

這一步決定了後面所有腳本的邊界。如果先寫工具再定範圍，自動化會把不該上雲的東西也忠實地推上去。

03 · 架構：一小時內跑完的備份鏈

設計約束只有兩條：不增加常駐行程；盡量掛在已有的備份時間窗口上。

每個任務都由 launchd 排程，外面套一層等待網路就緒的包裝腳本，結束代碼非 0 時在本機儀表板告警。

git-sweep 的規則是只推不提交：什麼時候提交仍由開發者和各專案自己的規則決定，腳本只負責不讓已經提交的內容長期留在本機。它只推遠端已存在的同名分支；新分支首次推送需要手動 push -u，腳本記日誌但不代勞。

為了上線，開發者另外新建了 8 個私有儲存庫，並把 15 個儲存庫的積壓提交一次推平。批次推送前先查了一遍 Cloudflare，確認沒有網站設定了「推送即自動部署」，否則積壓的幾十個未發布提交會直接上線。

04 · 推送閘門

自動推送最大的風險是推錯東西。所以知識庫、書稿、對話、設定、git-sweep 這幾個推送入口都 source 同一個閘門函式庫 lib-backup.sh，不允許各自實作。

外層是儲存庫級互斥鎖。鎖用核心 flock，掛在 shell 持有的檔案描述子上，行程結束時自動釋放，不會留下過時的鎖。macOS 沒有 flock(1) 命令，這裡借用系統內建的 Perl：

exec 8>>"$gitdir/1984-backup.lock"
/usr/bin/perl -e '
  use Fcntl ":flock";
  open(my $fh, ">&=", $ARGV[0]) or exit 2;
  for (1 .. $ARGV[1]) { exit 0 if flock($fh, LOCK_EX | LOCK_NB); sleep 1 }
  exit 1;
' 8 300

鎖內依序過五道檢查：

1. push URL 白名單。git remote get-url --push --all origin 回傳的每一個位址都必須屬於自己的 GitHub 帳戶，第三方上游一律跳過。
2. 現查遠端。用 git ls-remote 對每個實際 push URL 查分支 tip，不信本機的 origin/* 快取，也不用 fetch URL 代替 push URL。遠端有本機沒有的提交、或已分叉，就跳過並記日誌。
3. 逐提交掃路徑。只看最終 diff 會漏掉「中間某次提交加入、之後又刪除」的大檔案。這裡用 git log -z -m --root --no-renames --name-only 列出待推範圍內每個提交觸及的路徑，合併提交對每個父提交分別展開，根提交也包含在內。影音副檔名、對話原始紀錄目錄命中即拒推。
4. 掃物件體積。git rev-list --objects --not 列出待推物件，再用 git cat-file --batch-check 取體積，任何 blob 超過 5MB 即拒推（GitHub 的硬上限是 100MB）。
5. 推送固定 OID。檢查的是某個提交 ID，推送的也是這個 ID：git push :refs/heads/。檢查之後才出現的新提交不會被一起帶上去。

閘門函式的回傳碼有三種：0 通過，1 策略拒推，2 無法判定。2 按失敗處理。

fail-closed 是這套設計裡最重要的約定。 備份系統最危險的狀態不是失敗，而是失敗了卻回報成功。dry-run 時就遇到過一次：腳本裡 $branch 後面緊跟一個全形括號，macOS 內建的 bash 3.2 把它當成變數名稱的一部分，set -u 判定變數未定義，子 shell 結束，整個掃描根被跳過，而彙總行依然回報一切正常。修復分兩層：變數一律寫成 ${branch}；每個掃描根跑完必須輸出一行 root_done，彙總時核對數量，少一個就計為失敗。

05 · 憑證：age 加密包

SSH 私鑰、API token、路由器設定不能以明文進 git，但 Mac 遺失後又必須能找回。這裡用 age 做非對稱加密。

• 公鑰只能加密。每週的定時任務只用公鑰，不需要互動輸入密碼。
• 私鑰存進 iCloud 鑰匙圈（「密碼」App 中的一筆紀錄）。存入後從 App 複製出來重新推導公鑰，與本機公鑰一致，確認儲存無誤。本機也保留一份權限為 600 的私鑰，用於下面的往返校驗。
• 加密包上傳到 GitHub 私有儲存庫的 Release，檔名帶時間戳記，遠端只保留最新兩份。

只拿到 GitHub 側只有密文；只拿到 iCloud 側只有金鑰沒有資料。兩邊同時可用，正好對應「Apple ID 和信箱還在」這個前提。

secrets-vault.sh 的流程：

tar -czf - --no-xattrs --no-mac-metadata -T "$LIST" | age -R "$PUB" -o "$OUT"
# 本機往返校驗：能解密、能列目錄、條目數 > 0；沒有私鑰就無法證明可恢復 → 失敗
age -d -i "$KEY" "$OUT" | tar -tzf - | wc -l
gh release upload "$TAG" "$OUT" "$OUT.sha256"
# 遠端體積與本機一致之後，才刪除除最新兩份以外的舊資產

幾個細節：

• 私鑰本身不進包，否則就是把鑰匙鎖在箱子裡。打包清單是明確列出的路徑，不用萬用字元，避免把 ~/.config/age/ 順手帶進去。
• 新版先上傳、核對遠端體積，再刪舊版，任何時刻遠端至少有一份完整副本。
• 空儲存庫不能建立 Release（GitHub 回傳 HTTP 422），首次執行先寫一個只含說明的 README。
• set -e 中途結束時由 ERR trap 寫日誌，避免「腳本退了但日誌裡什麼都沒有」。

06 · 設定鏡像的金鑰檢測

環境設定（SSH 主機表、~/.local/bin 下的腳本、LaunchAgent plist、Claude Code 設定、Brewfile、pipx 清單）需要以明文進入知識庫，這樣新機器上讀一遍就能重建環境。難點是其中可能夾著金鑰。

最終結構是：

1. 三份鏡像全部先在知識庫之外的私有暫存目錄（權限 700）中組裝。
2. 結構化匯出：settings.json 用 jq 按欄位白名單匯出；plist 用 plutil 改值，EnvironmentVariables 中敏感鍵的值改為 REDACTED，結果仍是合法 XML。
3. 能以自由格式藏金鑰的檔案（shell 啟動檔案、Codex 設定、secrets.env）不進入明文層，原件只進加密包。
4. 對暫存目錄逐檔案檢測：已知 token 前綴、PEM 私鑰標頭、長 base64 行、敏感鍵賦值、命令列密碼參數、plist 參數對、TOML 多行字串。JSON 檔案先用 jq -r '.. | strings' 把字串值解碼成純文字再檢測，否則 \" 跳脫會讓正規表示式失效。
5. 任一檔案可疑，整批不發布，知識庫保留上一版；檢測日誌只記錄檔案相對路徑和命中類型，不印出內容。

第 3 步是第二輪審查之後才加的，詳見下一節。

07 · 獨立審查：五輪紀錄

程式碼寫完後，開發者用 Codex（唯讀沙盒）通讀全部備份腳本做驗收。審查提示從第 4 輪起寫明了威脅模型：單人 Mac 的個人備份，防的是疏忽導致明文上雲和備份靜默失敗，不防已經控制本機的攻擊者。沒有這條邊界，審查會無限加碼。

三點體會：

• 第 2 輪的方向調整比任何單條修復都重要。 基於正規表示式的金鑰檢測不可能完備，與其繼續加規則，不如縮小需要檢測的範圍。
• 審查需要威脅模型。 寫明防什麼、不防什麼，審查意見才會收斂。
• 修復會引入新問題。 第 2 輪加的參數校驗在第 3 輪被發現與實際呼叫不符。每輪修復後都要全量重測，不能只測改動點。

08 · 過程中的失誤

掃描時洩露了憑證。 掃描設定檔案中的金鑰時，命令把比對行輸出到終端機，指望後面接的 sed 打碼。但 macOS 的 BSD sed 不支援 \s，正規表示式靜默失效，4 個 token 以明文進入對話紀錄，只能逐一輪替。規則改為：掃描金鑰只輸出計數和檔名，任何情況下都不印出比對內容。

備份檔案差點放錯位置。 遷移一個寫死的 key 時，原檔案備份放在了原目錄，而那個目錄每天鏡像上雲。及時發現並移走。

新檢測器發現了舊問題。 改造後的檢測器第一次在真實資料上執行，就攔下了兩個半年前寫死在 AI 指令檔案裡的憑證。隨後對知識庫的全部 git 歷史做了一次掃描，又找到幾個已刪除但仍留在歷史中的舊憑證。處理方式：目前檔案中的遷入本機 secrets.env，原處改為引用環境變數；只在歷史中的透過輪替使其失效，不改寫歷史（需要強制推送，不可逆，且無法控制 GitHub 側快取）。

不可逆和外傳操作由人執行。 過程中 Claude Code 的安全分類器攔下了兩次操作：刪除遠端分支（不可逆）和上傳加密憑證包（資料外傳）。兩次都改由開發者手動執行。這個分工是對的。

09 · 恢復演練

備份能恢復才有意義。最後一步是模擬換機：從 GitHub 下載加密包，核對校驗和，解密並清點內容。

gh release download vault-latest -R <owner>/<vault-repo> -p 'secrets-vault-*'
shasum -a 256 -c secrets-vault-<stamp>.tar.gz.age.sha256
age -d -i vault.key secrets-vault-<stamp>.tar.gz.age | tar -tzf - | wc -l

結果：

• 校驗和一致；解密後 745 個條目，與上傳時的本機往返校驗一致。
• SSH 金鑰、主機設定、各類 token、路由器設定（718 個檔案）、各專案 .env 均在包內。
• 用隨機產生的另一把 age 金鑰解密，失敗。
• 演練只列目錄，不把解密內容寫入磁碟。

實際耗時不到一分鐘。中間一次卡頓是演練裡一條列出檔案的命令在背景掛起，與備份系統無關。

10 · 已知局限

另外，「約 90% 可自動復原」是按重要性加權的估計，不是測量值。

11 · 可重用的做法

1. 先實測再判斷。 記憶裡的「每天備份」不等於涵蓋完整；32 個無遠端儲存庫是掃出來的，不是想出來的。
2. 先定範圍再寫工具。 一條資訊密度規則砍掉了約 496MB 的無效上雲。
3. 報告裡的數字要能追溯到命令輸出。 「磁碟 13%」就是反例。
4. 掛在已有時間窗口上，不加常駐行程。
5. fail-closed。 無法判定就當失敗；每個掃描單元必須交回執。
6. 縮小暴露面優於加強檢測。 敏感檔案不進明文層，比多寫十條正規表示式可靠。
7. 作者和審查者用不同的模型。 唯讀權限，多輪，直到阻斷項歸零。
8. 審查要有明確的威脅模型。
9. 不可逆和外傳操作由人執行。
10. 失誤寫成規則。 「掃描金鑰只輸出計數和檔名」現在是長期規則。

整個上午，AI 執行了幾百條命令、寫了約 500 行備份腳本、調度另一家模型做了五輪審查。真正改變方向的決定只有幾個：備份範圍按資訊密度劃定、哪些儲存庫值得新建遠端、哪些風險可以接受。實作和取證可以交給 AI，範圍和取捨需要開發者來定。