真正讓我崩潰的不是恢復(fù)失敗，而是一次"成功"的恢復(fù)——它悄無(wú)聲息地把數(shù)據(jù)庫(kù)弄錯(cuò)了狀態(tài)。三個(gè)月前的Postgres備份導(dǎo)入到測(cè)試環(huán)境，應(yīng)用跑起來(lái)一切正常，直到同事發(fā)現(xiàn)少了兩列數(shù)據(jù)。遷移腳本在第六周加過(guò)這兩列，但備份文件里根本沒(méi)有遷移記錄。兩個(gè)東西完全分離，由不同的流程管理，沒(méi)人保證它們會(huì)一起出現(xiàn)。

如果你做過(guò)兩三個(gè)項(xiàng)目，一定見(jiàn)過(guò)那個(gè)文件夾。通常叫scripts/、db/，或者直接扔在倉(cāng)庫(kù)根目錄。里面塞著各種備份腳本、遷移記錄、手動(dòng)修復(fù)的SQL片段。

核心問(wèn)題不是懶，而是備份和遷移被當(dāng)成兩件事，實(shí)際上它們緊密耦合。沒(méi)有遷移狀態(tài)的備份是不完整的，你不知道快照拍下來(lái)時(shí)哪些遷移已經(jīng)跑過(guò)。三個(gè)月后恢復(fù)，你只能猜——要么全跑一遍，要么一個(gè)都不跑，兩種選擇都可能是錯(cuò)的。我見(jiàn)過(guò)這兩種錯(cuò)誤都在測(cè)試環(huán)境搞丟過(guò)數(shù)據(jù)，有一次甚至上了生產(chǎn)環(huán)境。

我真正需要的是把遷移狀態(tài)"烤"進(jìn)備份本身，恢復(fù)時(shí)自動(dòng)知道該跑哪些遷移、跳過(guò)哪些。不是手動(dòng)維護(hù)的約定，不是承諾會(huì)更新的README，而是工具層面的硬性保證。Portabase v1.13做的就是這件事，也是我切換的原因。注意：本文針對(duì)v1.13，如果你還在用v1.12，--migration-source參數(shù)改過(guò)名，快照格式也變了，直接升級(jí)不讀更新日志會(huì)搞壞現(xiàn)有恢復(fù)腳本。

Portabase最讓我意外的是它不做什么。它不想當(dāng)另一個(gè)遷移工具，不和Flyway或Liquibase競(jìng)爭(zhēng)。它只是讀取這些工具已經(jīng)寫(xiě)進(jìn)數(shù)據(jù)庫(kù)的遷移狀態(tài)，和SQL dump一起打包成單個(gè)歸檔。這個(gè)區(qū)別很實(shí)用——可惜README把它埋在三個(gè)段落的廢話后面。

本質(zhì)上Portabase就是一個(gè)Go寫(xiě)的單二進(jìn)制文件，沒(méi)有運(yùn)行時(shí)包袱。扔到服務(wù)器上，指一下數(shù)據(jù)庫(kù)連接字符串就能跑。唯一真正的依賴(lài)是DB客戶(hù)端庫(kù)——PostgreSQL要libpq，MariaDB要對(duì)應(yīng)的連接器。不用折騰Node運(yùn)行時(shí)，不用管JVM版本沖突，不用配Python虛擬環(huán)境。我把12MB的二進(jìn)制文件塞進(jìn)Docker鏡像的最終階段，幾分鐘就搞定了。