實體主機資料卷升級：以 LVM 快照驗證離線回復

應用程式升級不只是替換程式，也可能變更索引、資源檔案與資料格式。只保留舊版安裝套件，並不能保證資料卷能夠回復。對於已採用 LVM（邏輯卷管理）的實體主機，可以在停止寫入後建立短期快照，再透過離線合併回復升級前的狀態。關鍵不在於快照指令是否執行成功，而在於寫入邊界、剩餘容量與回復驗收是否完整。

一、先確認目標資料卷與回復邊界

本文以 Debian 13、ext4 檔案系統和傳統 LVM 資料卷為例，不涵蓋根檔案系統、開機卷或精簡配置集區。CloudUDP 的標準配置為兩顆 1TB NVMe，各自直接連接，沒有硬體 RAID；這不代表系統已採用 LVM，實際儲存配置仍須在現場核對。

先記錄掛載來源、檔案系統類型、邏輯卷屬性，以及卷組的剩餘空間：

findmnt -T /srv/appdata -o SOURCE,TARGET,FSTYPE,OPTIONS
sudo lvs -a -o vg_name,lv_name,lv_attr,segtype,origin,data_percent
sudo vgs -o vg_name,vg_size,vg_free
sudo lsblk -f

若目標只是一般分割區，應立即停止套用本文流程。不要為了取得快照功能而格式化現有資料。若輸出包含精簡配置卷、快取層或其他複雜配置，應改用對應儲存方案的操作流程。

下文假設實際資料卷為 vgdata/appdata，掛載點為 /srv/appdata，相關服務為 app.service。這些名稱都必須替換成現場的實際值，並確認沒有巢狀掛載或其他寫入來源。指令應分階段執行，不宜複製整篇內容後一次執行。

快照不等於備份

傳統快照透過寫入時複製，保留原始卷中即將被改寫的資料區塊，因此仍依賴原始卷及其底層儲存。它既無法隔離硬碟故障，也不涵蓋資料卷以外的設定、程式或遠端資料。

合併快照會撤銷快照建立後，資料卷內的所有寫入。若升級後已接受正式業務請求，必須先匯出需要保留的新資料，並確認這些資料與舊版程式相容，不能直接回復。

二、停服後建立一致的回復點

升級前，先準備獨立備份，並記錄程式版本、設定摘要及應用程式的健康狀態。快照只能保證指定資料卷的區塊狀態；若涉及多個資料卷或外部資料庫，仍須規劃跨元件的一致性邊界。

停止服務前，應先暫停入口請求、佇列消費者與排程工作，避免服務停止後仍有程序改寫資料。以下指令以成功卸載作為資料卷已靜止的判定條件，不使用強制卸載或延遲卸載：

sudo systemctl stop app.service
sudo fuser -vm /srv/appdata
sudo sync
sudo umount /srv/appdata

若卸載時回報資源忙碌，請檢查目前工作目錄、已開啟的檔案及其他服務；在排除所有寫入來源之前，不要繼續。接著建立快照：

sudo lvcreate --snapshot --size 20G \
  --name preupgrade /dev/vgdata/appdata
sudo lvs -o lv_name,lv_attr,origin,data_percent vgdata
sudo mount /srv/appdata

這裡的 20G 是示範用的快照空間，不是產品配置，也不是通用建議值。執行前，請確認卷組有足夠的可用空間，且 preupgrade 尚不存在。快照容量應依回復觀察期間預期被改寫的資料區塊估算，而不是機械式地按原始卷總容量取固定比例。

重新掛載原始卷後，先建立一個小型驗收檔案，再進行受控升級。此時仍應阻止正式業務寫入，否則後續回復時還需要額外的資料交接步驟。

三、以唯讀方式核對快照並監控用量

快照建立成功後，必須驗證其內容確實可讀。以下選項僅適用於本文的 ext4 範例：ro 表示唯讀，noload 可阻止掛載時重播日誌；不能直接套用到其他檔案系統。

sudo mkdir -p /mnt/app-preupgrade
sudo mount -t ext4 -o ro,noload \
  /dev/vgdata/preupgrade /mnt/app-preupgrade
sudo sha256sum /mnt/app-preupgrade/manifest.json \
  | sudo tee /root/app-preupgrade.sha256
sudo umount /mnt/app-preupgrade

manifest.json 代表實際選定、內容穩定的業務檔案，必須事先確認檔案存在，且具有驗收意義。校驗清單存放在目標資料卷之外；回復後只比較檔案的雜湊值欄位，不比較掛載路徑。

依資料變更量判斷風險

sudo lvs -a -o lv_name,lv_attr,origin,data_percent vgdata
sudo vgs -o vg_name,vg_free

Data% 表示傳統快照空間的使用比例，不是原始卷的檔案系統使用率。升級前後應持續取樣，觀察用量增加的速度；批次重建索引、覆寫大型檔案等操作，都可能快速消耗快照空間。

接近預設警戒線時，應暫停後續寫入並評估擴充容量。若卷組仍有可用空間，且快照仍有效，可依評估結果增加容量：

sudo lvextend -L +10G /dev/vgdata/preupgrade

增加空間不會延長業務允許的回復期限。若快照已失效，不能將擴充容量視為修復方式，而應改走獨立備份的還原流程。若沒有告警接收與處理機制，快照監控就無法構成可靠的保護。

四、離線合併並驗證回復結果

決定回復後，先關閉業務入口，保存失敗證據及必須保留的新資料。資料卷以外的程式與設定也必須還原到相符版本；只還原資料卷，可能造成舊資料搭配新程式的錯誤組合。

確認快照有效，且快照掛載點已卸載，再停止所有相關服務並卸載原始卷。以下操作會變更資料，執行前請再次核對卷名：

sudo systemctl stop app.service
sudo umount /srv/appdata
sudo lvchange -an /dev/vgdata/appdata
sudo lvconvert --merge /dev/vgdata/preupgrade
sudo lvchange -ay /dev/vgdata/appdata
sudo lvs -a -o lv_name,lv_attr,origin,data_percent vgdata

若合併已排定在下次啟用時執行，應持續觀察狀態，直到合併完成；不能只因指令回報成功就啟動業務。合併成功後，快照卷會消失，此時再掛載原始卷並檢查：

sudo mount /srv/appdata
sudo sha256sum /srv/appdata/manifest.json
sudo cat /root/app-preupgrade.sha256

檔案雜湊值應與基準一致，快照建立後新增的驗收檔案則應消失。不過，這些結果只能證明指定檔案已回復，不能證明應用程式運作正確。還須核對程式版本、關鍵記錄筆數、讀取結果，並完成一次受控寫入，之後再啟動服務並檢查日誌。

五、將演練結果整理成升級檢查清單

先在非業務資料卷上演練一次完整流程，記錄快照建立、容量增長、合併狀態及應用程式檢查結果。正式環境升級前，至少應確認：

• 目標是既有的傳統 LVM 資料卷，掛載來源與卷名相互對應。
• 所有寫入來源都能停止，原始卷能正常卸載，且獨立備份已驗證。
• 快照空間有資料變更量作為估算依據，卷組也預留了擴充餘裕。
• 舊版程式、資料卷以外的設定及回復清單都能取得。
• 新寫入資料的保留方式與業務恢復條件已明確定義。

升級通過驗收，且回復觀察期結束後，先確認快照未掛載，再以 lvremove /dev/vgdata/preupgrade 清理仍然存在的快照；已合併的快照不必重複刪除。

最終交付物應是一份操作紀錄，包含資料卷配置、回復點、容量紀錄與業務驗收結果。快照只是短期回復工具；可靠性來自可重複執行的回復流程，而不是多保留一個卷名。

常見問題