探索

pgBackRest參數設定

閱讀時間約 14 分鐘

🌿Sapling

生產環境最佳實踐與強化設定

基礎設定雖然功能完備，但生產環境對效能、安全性與自動化有著更高的要求。

生產級設定檔範本

[global]
# --- 效能優化 ---
# 用於壓縮與傳輸的平行程序數量；建議設為 CPU 核心數的 25% 左右
process-max=4
# 使用 zst 壓縮以獲得更快的速度與良好的壓縮比
compress-type=zst
# 執行WAL歸檔時立即觸發檢查點以快速啟動備份
start-fast=y
# 將小檔案打包傳輸
repo-bundle=y
 
# --- 安全性強化 ---
# 啟用 AES-256-CBC 加密
repo1-cipher-type=aes-256-cbc
# 使用 'openssl rand -base64 48' 產生的加密金鑰
repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO
 
# --- 儲存庫與保留策略 ---
repo1-path=/var/lib/pgbackrest
# 保留最近 7 份完整備份
repo1-retention-full=7
# 保留最近 4 份差異備份
repo1-retention-diff=4
 
# --- 日誌設定 ---
log-level-console=info
log-level-file=detail
log-path=/var/log/pgbackrest
 
[cg_test_prodcut]
pg1-path=/var/lib/postgresql/17/main

並行處理優化：process-max

這是影響備份速度最關鍵的參數。預設值為 1，這意味著壓縮、加密和傳輸都只使用單一核心，通常無法發揮現代伺服器的效能。

  • 設定建議：建議設為 CPU 總核心數的 25% 左右（例如 16 核主機設為 4）。

  • 作用：啟用多個 worker process 進行平行運算。

  • 效益：顯著縮短備份與還原所需的時間。請注意不要設定過高，以免備份作業佔用過多資源，影響資料庫原本的服務效能。

高效壓縮演算法：compress-type

雖然 gzip 是通用標準，但在備份場景中，追求的是速度與壓縮率的最佳平衡。

  • 設定建議：compress-type=zst
  • 作用：切換使用 Facebook 開發的 Zstandard (zstd) 演算法。
  • 效益：相較於預設的 gz，zstd 在相同的壓縮比下能提供更快的壓縮與解壓縮速度，這意味著更短的備份窗口與更快的災難復原速度。

快速啟動備份：start-fast

預設情況下，當您執行備份指令時，pgBackRest 會等待 PostgreSQL 下一次排程的「檢查點 (Checkpoint)」觸發後才開始備份。這個等待時間可能長達數分鐘。

  • 設定建議：start-fast=y
  • 作用：強制 PostgreSQL 在備份指令下達時，立即執行一個檢查點。
  • 效益：消除不必要的等待時間，讓備份排程能準時且迅速地啟動。

檔案打包傳輸：repo-bundle

PostgreSQL 資料庫目錄中包含成千上萬個小檔案（如 pg_clog, pg_stat 等）。逐一傳輸這些檔案非常缺乏效率。

  • 設定建議：repo-bundle=y
  • 作用：將多個小檔案「打包」成一個較大的檔案（Bundle）再進行傳輸與儲存。
  • 效益：
    • 雲端環境 (S3/GCS)：這是必備選項。因為雲端儲存通常依賴 API 請求計費，且高延遲會讓傳輸大量小檔案變得極慢。打包能節省昂貴的 API 費用並大幅提升速度。
    • 地端環境 (Local/NFS)：強烈建議開啟。這就像搬家時先將書本「裝箱」再搬運，而不是一本一本拿。這能減少檔案系統的 I/O 負擔、降低 Inode 消耗，並減少網路儲存 (NAS/NFS) 的來回通訊次數。
  • 例外情況：若您的儲存設備本身具有硬體級去重複化功能 (如 Dell Data Domain)，打包可能會干擾設備效率，此時才考慮關閉。
場景建議設定原因
雲端 (S3/GCS)務必開啟節省昂貴的 API 請求費與解決高延遲問題,。
地端 (Local Disk)建議開啟減少檔案數量，管理更乾淨，效能亦有提升。
地端 (NFS/NAS)強烈建議減少網路通訊次數，顯著提升備份速度。
地端 (去重設備)評估後關閉避免干擾硬體本身的去重複化演算法。

防止磁碟爆滿的洩壓閥：archive-push-queue-max

這是一個生產環境中的安全閥設定，用於處理儲存庫連線異常時的緊急狀況。

  • 設定建議：archive-push-queue-max=4GiB (依磁碟空間調整)
  • 原理：當 pgBackRest 無法將 WAL 日誌推送到備份儲存庫時，這些 WAL 檔案會堆積在資料庫主機的 pg_wal 目錄中。若不加以限制，最終會撐爆磁碟，導致資料庫崩潰 。
  • 作用：
    • 異常情況：當堆積的 WAL 大小超過此設定值（例如 4GB），pgBackRest 會主動丟棄超出的舊 WAL 檔案。
  • 重要權衡：
    • 代價：丟棄 WAL 會導致備份鏈斷裂，您將暫時無法進行時間點還原 (PITR)，直到下一次完整備份完成。
    • 收益：確保了資料庫主機不會因為磁碟空間耗盡而停止服務，保障了生產環境的存活。

安全性強化：儲存庫加密

為了防止備份資料外洩，對備份儲存庫進行加密是生產環境中的標準安全措施。

  1. 啟用加密 在 pgbackrest.conf 的 [global] 區段中，設定 repo1-cipher-type 參數來啟用 AES-256-CBC 加密。
  2. 設定加密金鑰 使用 openssl 工具產生一個高強度的隨機密碼作為加密金鑰。
  3. 將產生的字串設定給 repo1-cipher-pass 參數。

加密設定 必須 在首次執行 stanza-create 之前完成。您無法對一個已經存在的、未加密的 Stanza 直接追加加密設定。如果您需要為現有 Stanza 啟用加密，必須先刪除舊的備份儲存庫 (/var/lib/pgbackrest)，然後重新初始化。

管理備份保留策略：repo-retention

為了有效管理儲存空間，避免備份無限制地增長，設定清晰的保留策略至關重要。

  • repo-retention-full: 此參數定義了要保留的完整備份的數量。例如，設為 7 表示系統會保留最近的 7 個完整備份集。當第 8 個完整備份成功完成後，最舊的那個完整備份及其相關的所有差異和增量備份將被自動刪除。
  • repo-retention-diff: 此參數定義了要保留的差異備份的數量。這讓您可以建立一個「滾動式」的備份窗口，例如，保留最近 4 份差異備份，以在節省空間的同時，提供較近的還原點。

pgBackRest 的 expire 指令負責執行過期備份的清理工作。此指令預設會在每次成功的 backup 指令執行後自動運行，因此您通常無需手動干預。

還原指令解析與策略

還原的方法

如何處理現有的資料庫檔案

  • 當前設定 (—delta )：
    • 行為：使用 Checksum 比對硬碟上現有的檔案與備份庫的檔案。只下載有差異的檔案，並刪除多餘的檔案。
    • 適用情境：資料庫目錄還在，但可能部分損壞（如誤刪檔案、設定檔錯亂），或者您想讓資料庫回到過去某個時間點，且不想刪除整個目錄重拉資料。
    • 優勢：速度極快（只傳輸異動量），且能自動清理目錄 。
  • 可替換的選項 / 替代方案：
    • 不加參數 (Clean Restore)：
      • 行為：這是預設行為。pgBackRest 預期目標目錄（Data Directory）是 空的。如果目錄內有檔案，還原會失敗並報錯
      • 操作方式：您必須先手動執行 rm -rf /var/lib/pgsql/14/data/* 清空目錄，然後執行不帶 --delta 的 restore 指令。
      • 適用情境：硬碟壞軌換新硬碟、資料庫目錄嚴重損毀（Corruption）或想確保絕對乾淨的環境。
    • —force：
      • 行為：強制覆蓋現有檔案。這通常不建議使用。
  • 衝突/限制：
    • --delta 與「手動清空目錄」不衝突（空目錄用 delta 效果等於全量還原），但若您不加 --delta 卻不清空目錄，指令會失敗。

還原的目標類型

這個參數決定了 「資料庫要還原成什麼狀態」 或 「由什麼基準點停止」。

  • 當前設定 (--type=time)

    • 行為：時間點還原 (PITR)。配合 --target 指定的時間，重放 WAL 日誌直到該時刻。

    • 適用情境：人為錯誤（如誤刪 Table、錯誤更新資料），需要回到錯誤發生前的那一刻。

  • 可替換的選項 (Alternatives)

    • --type=default (或不寫)

      • 行為：還原到備份後的 最新狀態（End of WAL）。它會把歸檔中所有的 WAL 全部重放完畢。

      • 適用情境：硬體故障導致主機掛掉，需要用備份救回所有能救的資料。

    • --type=immediate

      • 行為：還原到「資料庫一致性（Consistency）」達成的最早時刻就立刻停止。

      • 適用情境：緊急搶修，只想確認資料庫能開機，不在乎遺失備份後產生的新資料。

    • --type=standby

      • 行為：不停止重放，而是將資料庫設定為 「唯讀待命模式 (Hot Standby)」。它會自動在 postgresql.auto.conf 寫入 standby_mode 相關設定，讓這台機器變成從庫。

      • 適用情境：建立 Replication 從機、測試環境搭建。

    • --type=xid / --type=lsn / --type=name

      • 行為：分別依據「交易 ID」、「Log Sequence Number」或「還原點名稱 (Restore Point)」來還原。

      • 適用情境：DBA 進行精密除錯，知道具體哪個 Transaction 出問題時使用。

還原的目標值

這個參數是 --type 的具體數值。

  • 當前設定 (--target="2025-12-12 08:30:00")

    • 行為：告訴 pgBackRest 停止重放 WAL 的精確時間。

    • 注意：時間格式建議包含時區（如 timestamp with time zone），否則可能會因 UTC/Local time 差異導致還原點錯誤。

  • 衝突 / 限制

    • 如果 --type 是 default (不指定) 或 standby，通常不需要 --target（除非您想建立一個「延遲 standby」）。

    • --target 的格式必須與 --type 對應（例如 type=xid 時 target 必須是交易 ID 數字）。

其他還原指令參數

為了讓操作更精確，以下參數經常與上述指令搭配使用：

  • --target-action

    • 說明：決定還原到達目標時間點後要做什麼動作。

    • 選項：

      • promote (預設值)：還原完成後，直接切換為主機 (Primary)，允許寫入。

      • pause：還原到目標點後 暫停，維持唯讀狀態。方便檢查資料是否救回。若確認無誤，再手動執行 pg_wal_replay_resume() 提升為主機。

      • shutdown：還原後直接關機。

    • 建議：如果不確定時間點是否抓得準，建議加上 --target-action=pause。

  • --set

    • 說明：指定要使用哪一個備份集 (Backup Set) 開始還原。

    • 情境：pgBackRest 通常會自動選擇最適合的備份集。但在複雜情況下（如多條 Timeline），可能需要手動指定備份標籤 (Backup Label) 強制使用特定備份。

  • --db-include / --db-exclude

    • 說明：只還原特定的資料庫。

    • 情境：若大資料庫有 5TB 但只要救其中一個 50GB 的 test_db，使用 --db-include 可節省大量時間與空間。未選中的資料庫會變成空殼。

reference

  1. 官方指令參數

關係圖譜

1

目錄