Categories
Database Backup

** Discover how DevOps engineers and DBAs can detect corrupted database backups before disaster strikes. Learn advanced techniques for PostgreSQL, SQL Server, and MySQL, including automated restore testing and checksum validation.

在資料庫管理與網站可靠性工程的高風險領域中，有一個眾所周知的公理：薛丁格的備份 (Schrödinger’s Backup)。在您嘗試還原之前，任何備份的狀態都是未知的。直到那一刻，它都處於一種既完美可用又完全損毀的量子疊加態。

對於 DevOps 工程師和資料庫管理員 (DBA) 而言，在發生緊急事件時發現關鍵資料庫備份已損毀，是終極的噩夢場景。這會將例行的復原操作轉變為災難性的資料遺失事件。這種資料完整性的「隱形殺手」往往難以察覺，因為即使底層負載已損毀，備份作業通常仍會回報成功的 Exit Code 0。

在本綜合指南中，我們將剖析備份損毀的結構、探索資料庫專屬的驗證技術，並示範如何為生產環境建立自動化且萬無一失的還原管線。

備份損毀的結構

要偵測損毀，您必須先了解它是如何發生的。備份損毀通常分為兩類：實體（基礎架構層級）與邏輯（應用程式層級）。

實體損毀

實體損毀發生在儲存媒體上的實際位元被更改時。這可能發生在從來源磁碟讀取過程中、網路傳輸期間，或在目標儲存裝置上靜態儲存時。
* 位元衰減 (Bit Rot)：儲存媒體的逐漸退化可能會導致位元無聲地翻轉。
* 傳輸錯誤：雖然 TCP 具有校驗和，但它們非常薄弱（16 位元）。高吞吐量環境可能會在傳輸過程中經歷 TCP 無法偵測到的靜態資料損毀。
* 儲存控制器故障：RAID 控制器或 SAN 架構中的硬體錯誤可能會在向作業系統回報成功時寫入垃圾資料。

邏輯損毀

邏輯損毀可以說更危險，因為備份檔案本身完好無損，但內部的資料卻已損壞。
* 垃圾進，垃圾出 (GIGO)：如果您的即時資料庫有損毀的索引或損壞的頁面，您的備份工具可能會忠實地複製該損毀頁面。備份作業成功了，但還原將會失敗或產生一個損壞的資料庫。
* 交易未完成：在未正確凍結資料庫 I/O 的情況下（例如在 MySQL 中未使用 FLUSH TABLES WITH READ LOCK）進行檔案系統層級的快照，會導致頁面損壞和無法復原的狀態。

主動偵測：校驗和與加密雜湊

防禦實體損毀的第一道防線是加密驗證。僅依賴檔案大小或修改日期是不夠的。

啟用資料庫層級的校驗和

現代關聯式資料庫管理系統 (RDBMS) 支援頁面層級的校驗和。啟用後，資料庫會在將每個頁面寫入磁碟之前計算校驗和。當讀取該頁面時（無論是透過查詢還是備份程序），都會驗證校驗和。

對於 PostgreSQL，您可以在叢集初始化期間啟用資料校驗和：

# 初始化一個已啟用校驗和的新 PostgreSQL 叢集
initdb --data-checksums -D /var/lib/postgresql/data

注意：如果您已有現有的 PostgreSQL 叢集，可以使用 pg_checksums 工具離線啟用它們。

對於 Microsoft SQL Server，請確保 PAGE_VERIFY 設定為 CHECKSUM（這是現代版本中的預設值，但在舊系統上值得確認）：

ALTER DATABASE [ProductionDB] SET PAGE_VERIFY CHECKSUM;
GO

驗證靜態備份

一旦備份到達您的儲存目標，必須對其完整性進行加密驗證。像 CloudSave 這樣的企業級備份平台會在傳輸和靜態儲存期間自動計算並驗證備份區塊的 SHA-256 雜湊。如果您正在管理自訂指令碼，則必須手動實作此功能：

# 在備份建立後產生 SHA-256 雜湊
sha256sum prod_db_backup.tar.gz > prod_db_backup.tar.gz.sha256

# 在儲存伺服器上驗證雜湊
sha256sum -c prod_db_backup.tar.gz.sha256

資料庫專屬的驗證技術

不同的資料庫引擎提供原生工具來驗證其備份產物的完整性。

PostgreSQL: pg_verifybackup

pg_verifybackup 於 PostgreSQL 13 引入，對於使用 pg_basebackup 進行的實體備份來說是一項重大變革。它會讀取備份期間產生的 backup_manifest 檔案，並驗證所有檔案是否存在且其校驗和相符。

# 針對實體基礎備份目錄執行驗證
pg_verifybackup /mnt/backups/postgres/base_backup_20231025/

如果任何資料檔案中有一個位元翻轉，pg_verifybackup 將會拋出致命錯誤，讓您的監控系統能立即向 DBA 團隊發出警報。

Microsoft SQL Server: RESTORE VERIFYONLY

SQL Server 提供了一個原生指令，可在不實際還原的情況下驗證備份檔案的實體完整性。它會檢查備份標頭並驗證頁面校驗和（如果備份期間已啟用）。

RESTORE VERIFYONLY 
FROM DISK = 'Z:BackupsProdDB_Full.bak' 
WITH CHECKSUM;

警告： RESTORE VERIFYONLY 僅確認備份檔案可讀且實體校驗和相符。它無法保證邏輯完整性。若要確保邏輯完整性，您必須執行完整還原並執行 DBCC CHECKDB。

MySQL / InnoDB: Percona XtraBackup

對於 MySQL 環境，實體備份通常由 Percona XtraBackup 處理。備份過程包含複製檔案，但在套用交易記錄（重做記錄）之前，備份並不一致。--prepare 階段充當內建的完整性檢查。

# 準備備份會套用重做記錄。
# 如果備份已損毀，此步驟將會失敗。
xtrabackup --prepare --target-dir=/data/backups/mysql/

黃金標準：自動化還原測試

校驗和與驗證指令是必要的，但還不夠。證明備份可行的唯一方法是實際還原它。在現代 DevOps 環境中，此過程必須完全自動化。

透過將備份視為程式碼，您可以為資料庫還原建立 CI/CD 管線。此管線應配置臨時基礎架構、執行還原、執行驗證查詢，並拆除該環境。

建立自動化還原管線

以下是一個 Bash 指令碼範例，可由 cron 作業或 CI 執行器（如 GitLab CI 或 GitHub Actions）每日觸發，以驗證 PostgreSQL 邏輯傾印。

#!/bin/bash
set -e

BACKUP_FILE="/mnt/storage/prod_db_latest.dump"
DB_NAME="prod_db"
CONTAINER_NAME="pg_restore_test"

echo "[INFO] 開始自動化還原測試..."

# 1. 啟動一個臨時的 PostgreSQL 容器
docker run --name $CONTAINER_NAME 
  -e POSTGRES_PASSWORD=testpass 
  -d postgres:15

# 等待 PostgreSQL 就緒
echo "[INFO] 等待資料庫初始化..."
until docker exec $CONTAINER_NAME pg_isready -U postgres; do
  sleep 2
done

# 2. 建立目標資料庫
docker exec $CONTAINER_NAME psql -U postgres -c "CREATE DATABASE $DB_NAME;"

# 3. 執行還原
echo "[INFO] 正在還原備份..."
docker cp $BACKUP_FILE $CONTAINER_NAME:/tmp/backup.dump
docker exec $CONTAINER_NAME pg_restore -U postgres -d $DB_NAME -1 /tmp/backup.dump

# 4. 執行邏輯驗證查詢
echo "[INFO] 正在執行驗證查詢..."
# 檢查 users 資料表是否有超過 10,000 筆記錄
USER_COUNT=$(docker exec $CONTAINER_NAME psql -U postgres -d $DB_NAME -t -c "SELECT COUNT(*) FROM users;")

if [ "$USER_COUNT" -lt 10000 ]; then
    echo "[ERROR] 邏輯驗證失敗。預期 >10000 位使用者，實際找到 $USER_COUNT"
    # 在此處觸發 PagerDuty / Slack 警報
    exit 1
else
    echo "[SUCCESS] 邏輯驗證通過。使用者數量: $USER_COUNT"
fi

# 5. 拆除臨時環境
echo "[INFO] 正在清理..."
docker rm -f $CONTAINER_NAME

echo "[INFO] 自動化還原測試成功完成。"

您應該驗證什麼？

執行自動化還原測試時，不要只檢查資料庫是否啟動。請執行應用程式專屬的驗證查詢：
1. 資料列計數：確保核心資料表具有預期的資料列數（例如 users 資料表不應為空）。
2. 近期資料：查詢過去 24 小時內建立的記錄，以確保備份不是過時的。
3. 參照完整性：執行指令碼檢查孤立的外鍵，這通常表示邏輯損毀。

備份異常的監控與警報

在災難發生前偵測損毀需要強大的可觀測性。除了二進位的成功/失敗狀態外，您還應監控備份作業的中繼資料以偵測異常。

啟發式監控

將您的備份中繼資料整合到 Prometheus 中，並使用 Grafana 進行視覺化。為以下啟發式規則設定警報：
* 大小突然下降：如果您的每日備份通常為 500GB，而今天的備份只有 50MB，則該作業可能已成功完成（Exit Code 0），但它很可能只備份了一個空架構。
* 持續時間異常：如果通常需要 2 小時的備份在 5 分鐘內完成，則表示有東西被跳過了。相反地，如果需要 10 小時，則可能存在磁碟 I/O 退化，這可能會導致損毀。
* WAL/封存記錄累積：如果您的資料庫正在產生預寫式記錄 (WAL)，但備份系統封存它們的速度不夠快，您將面臨時間點復原 (PITR) 鏈中出現缺口的風險。

實作具備完整性檢查的 3-2-1 規則

業界標準的 3-2-1 備份規則（3 份資料、2 種不同媒體、1 份異地存放）只有在所有副本都經過驗證時才有效。

這就是利用像 CloudSave 這樣的企業級解決方案能大幅降低營運開銷的地方。CloudSave 無需為每個資料庫節點編寫和維護複雜的 bash 指令碼，而是直接與您的基礎架構整合，以自動化 3-2-1 生命週期。它提供不可變儲存（防止勒索軟體），並具備內建的自動化還原驗證排程。CloudSave 可以自動啟動隔離的沙盒環境、掛載備份、執行您的自訂 SQL 驗證指令碼，並將健康狀態回報給您的中央儀表板。

結論

損毀的資料庫備份是一個可能摧毀企業的隱形殺手。僅僅依賴備份指令碼的 Exit Code 0 是一場危險的賭博。

為了真正保護您的生產環境，您必須採取縱深防禦策略：
1. 在您的資料庫引擎中啟用頁面層級校驗和。
2. 在備份建立後立即使用原生驗證工具 (pg_verifybackup, RESTORE VERIFYONLY)。
3. 監控備份中繼資料（大小、持續時間）以偵測啟發式異常。
4. 將自動化、臨時還原測試實作為您每日營運管線的一部分。

透過從被動的「設定後即忘」備份心態轉變為積極的「持續還原驗證」模型，您可以確保當災難不可避免地發生時，您的資料已準備就緒、可靠且可完全復原。

分類