簡介
PostgreSQL 在執行過程中不斷地在叢集資料目錄 ( 安裝位置的 data 資料夾下) 的 pg_wal/ 子目錄中維護一個交易日誌（Write Ahead Log, WAL）。
日誌記錄了對資料庫資料檔案所做的所有變更，該日誌主要用於意外災難還原的目的：如果系統意外損毁，則可以透過「重播」自上一個檢查點以來所建立的日誌項目來恢復資料庫的一致性。
我們可以將檔案系統級備份與 WAL 檔案備份結合在一起。 如果需要復原，我們將還原檔案系統備份，然後從備份的 WAL 檔案中重播以使系統進入當下的狀態。
WAL 概要
可以把它想像成操作的紀錄檔案。
從抽象的意義上講，執行中的 PostgreSQL 系統會產生無限長的 WAL 記錄序列。
系統從物理上將此序列劃分為 WAL 分段檔案，每個檔案通常為16MB。
分段檔案被賦予數字名稱，以反映它們在抽象的 WAL 序列中的位置。
而根據我們的設定可以分成以下兩種歸檔模式:
- 不使用 WAL 歸檔時 (預設):
系統通常只建立幾個分段檔案，然後透過將不再需要的分段檔案重新命名為較高的分段號號來「回收」它們。
假設其內容在最後一個檢查點之前的分段檔案不再受關注時，即為可以回收。
- 使用 WAL 歸檔時: 我們需要在每個 WAL 分段檔案填滿 (接近 16 MN) 後取得其內容， 並將該資料保存在某個位置。 而這個位置，可以是磁帶，可以是另一台主機上 NFS 掛載目錄，PostgreSql 基本上不對歸檔做限制
啟用 WAL 歸檔模式
要啟用此歸檔模式，需要前往
postgresql.conf 進行以下設定- wal_level 參數設定為 replica 或更高的等級
- archive_mode 設定為 on
- archive_command 設定 wal 檔案寄送指令 (%p: 預設為 wal 檔案目錄, %f 預設為檔案名稱)
- window :
'copy "%p" "D:\\back\\postgresql\\archive\\%f"'(實際上要有路徑!!!) - linux :
'cp /mnt/server/archivedir/%f "%p"'
- archive_timeout 來設定時段歸檔 wal ( 因為有可能流量很小讓 wal 會有很長的延遲)
可以使用 gzip 壓縮這些檔案：
archive_command = 'gzip < %p > /var/lib/pgsql/archive/%f’在還原過程中使用 gunzip：
restore_command = 'gunzip < /mnt/server/archivedir/%f > %p'檔案目錄備份: pg_basebackup
可以使用 pg_basebackup 命令來幫助資料庫檔案進行備份
您需要保留檔案系統備份期間和之後產生的所有 WAL 段檔案。
為了幫助您完成此操作，基本備份過程會建立備份歷史文件，該文件會立即儲存到 WAL 存檔區域。該檔案以檔案系統備份所需的第一個 WAL 段檔案命名。
例如，如果起始 WAL 檔案是
0000000100001234000055CD ，則備份歷史檔案將命名為類似 0000000100001234000055CD.007C9330.backup 。
-Ft ⇒ 指定輸出 format 為 tar
-z ⇒ 壓縮 tar 為 gz
-w ⇒ 指定不需要密碼，但是要設定 .pgpass
完整還原
- 停止 postgresql 服務 (非常重要!!!!)
- 刪除 叢集資料目錄 下的檔案
- 將 pg_basebackup 產生的 base.tar.gz 檔案解壓縮到 叢集資料目錄 下
tar -xvzf your-file.tar.gz -C path-to-extract x表示解壓縮（extract）。v表示顯示過程中的詳細訊息（verbose）。z表示檔案使用 gzip 壓縮。f指定要解壓縮的檔案。C指定解壓縮到的目錄。
- 確保資料目錄及其內容的擁有者是 PostgreSQL 使用者（通常是
postgres），並且權限設置正確，可使用下列指令設定:icacls "[資料目錄]" /grant postgres:F /t
- 修改 postgres.conf 底下的 restore_command 跟 recovery_target 相關配置
- restore_command window 指令:
'cp "[archive_command 指定目錄]" %p'
- 新增 recovery.signal 檔案在 叢集資料目錄 下
New-Item -Path "[資料目錄]\recovery.signal" -ItemType File- 重新啟動 postgresql 服務