如何在沒有 pg_control 但使用文件系統備份和 wal 文件的情況下恢復 Postgresql？

作業系統：Ubuntu 16.04，Docker

PostgreSQL：10

我正在使用另一種文件系統備份，它每 24 小時對數據目錄進行“一致快照”。我遇到了來自 Postgresql 文件的警告。見上面的連結。

並且您願意相信它已正確實施…

問題是 1 週後文件不完整。無論出於何種原因，我的pg_control文件只備份了 6 天。這會導致恢復超過 6 天的文件系統備份會引發pg_control文件失去錯誤的問題。

我備份的一個積極方面是我擁有 WAL 文件的完整歷史記錄。所以不僅是6天，而且是無盡的過去。

所以我的計劃是使用 6 天前的副本，並嘗試重播 WAL 日誌，直到達到我想要的狀態。讓我們處理一個真實的日期。

我的數據庫在 2019 年 1 月 27 日開始正常，我現在想重播 WAL 文件以使數據庫狀態為 2018 年 12 月 18 日。

---

先決條件 我將伺服器文件從 2019-01-27 複製到執行相同版本 Postgresql (10) 的本地電腦。在 Postgresql 執行時進行了備份。無論如何，正如文件中所解釋的，它只是給出一個簡短的警告並在本地開始正常。

意圖 1：將 WAL 文件複製到 pg_wal 並啟動

1. 清除主目錄：rm -rf /var/lib/postgresql/10/main/*
2. 提取工作正常的副本。更改所有權和權限。刪除 postmaster.pid。
3. 將所有 pg_wal 文件複製到 pg_wal
4. 作為 postgres 使用者：/usr/lib/postgresql/10/bin postgres -D /.../main
5. 一切正常。

日誌：

LOG: database system was interrupted; last known up at 2019-01-27 20:00:00 UTC
LOG: database system was not properly shut down; automatic recovery in progress
LOG: redo starts at 1/D160878
LOG: invalid record length at 1/D160958; wanted 24, got 0
LOG: redo done at 1/D160920
LOG: database system is ready to accept connections

對我來說奇怪的是，pg_wal 中的 WAL 文件總數已減少。

6. 停止伺服器。
7. 創建一個 recovery.conf

restore_command = 'cp /dir/with/all_wal_files_backup/%f "%p"'
recovery_target_time = '2018-12-18 20:00:00 UTC'
recovery_target_inclusive = false

8. 啟動伺服器

日誌：

LOG: starting point-in-teim recovery to 2018-12-18 20:00:00+00
cp: cannot stat /dir/with/all_wal_files_backup/00010001D: No such file or dir
consisten recovery state reached at 1/D160a70
redo is not required
db is ready to accept read only connections
cp: cannot stat /dir/with/all_wal_files_backup/00010001D: No such file or dir
cp: cannot stat /dir/with/all_wal_files_backup/0002.history: No such file or dir
LOG: selected new timeline ID: 2
Archive recovery complete
cp: cannot stat /dir/with/all_wal_files_backup/0001.history: No such file or dir
db is ready to accept read only connections

現在，當我嘗試選擇要搜尋的數據時，它們不存在。我的錯誤在哪裡？

我已經嘗試過 pg_basebackup 然後恢復和無數其他形式但總是沒有成功所以我希望這裡有人可以幫助我。

提前致謝

---

更新

我嘗試了評論中解釋的過程，結果如下：我仍然無法選擇我期望的數據。儘管它告訴我成功，但恢復似乎已被打破。有任何想法嗎？

2019-02-04 14:08:16.330 UTC [12412] LOG:  database system was interrupted; last known up at 2019-01-27 20:04:15 UTC
2019-02-04 14:08:18.181 UTC [12412] LOG:  starting point-in-time recovery to 2018-12-15 08:00:00+00
2019-02-04 14:08:18.181 UTC [12412] LOG:  database system was not properly shut down; automatic recovery in progress
2019-02-04 14:08:18.185 UTC [12412] LOG:  redo starts at 1/D160878
2019-02-04 14:08:18.185 UTC [12412] LOG:  invalid record length at 1/D160958: wanted 24, got 0
2019-02-04 14:08:18.188 UTC [12412] LOG:  consistent recovery state reached at 1/D160958
2019-02-04 14:08:18.188 UTC [12411] LOG:  database system is ready to accept read only connections
2019-02-04 14:08:18.200 UTC [12412] LOG:  restored log file "00000001000000010000000D" from archive
2019-02-04 14:08:18.242 UTC [12412] LOG:  invalid record length at 1/D160958: wanted 24, got 0
2019-02-04 14:08:18.242 UTC [12412] LOG:  redo done at 1/D160920
2019-02-04 14:08:18.266 UTC [12412] LOG:  restored log file "00000001000000010000000D" from archive
cp: cannot stat '/var/lib/postgresql/10/main/archivedir/00000002.history': No such file or directory
2019-02-04 14:08:18.313 UTC [12412] LOG:  selected new timeline ID: 2
2019-02-04 14:08:18.393 UTC [12412] LOG:  archive recovery complete
cp: cannot stat '/var/lib/postgresql/10/main/archivedir/00000001.history': No such file or directory
2019-02-04 14:08:18.532 UTC [12411] LOG:  database system is ready to accept connections

我的數據庫在 2019 年 1 月 27 日開始正常，我現在想重播 WAL 文件以使數據庫狀態為 2018 年 12 月 18 日。

重放只能向前，從不向後。

如果 pg_control 是舊備份中唯一缺少的東西，則可以使用較新的副本作為模板手動重新創建 pg_control 的合適副本。但很可能其他文件也失去了。

你的情況似乎沒有希望了。如果這些數據真的很寶貴，您應該聘請數據恢復專業人員。您已經超越了“網際網路上的免費幫助”領域。

我可能錯了，但這似乎是一種冒險且過於復雜的備份方式，我認為 Postgres 文件需要升級以防止人們走這條路……我強烈建議您重新考慮您的選擇。

但是，當您啟動伺服器時，它將執行恢復，因為您複製了不一致的數據。在恢復結束時，它將執行一個檢查點（因此，這意味著它將在磁碟上寫入數據並註冊在 WAL 中發生的檢查點。）當您停止它並重新啟動它時，它無法在頂部執行 PITR那是因為您的實例處於新的“現實”中（最後一個 WAL 在記錄檢查點時有所不同）。

要執行 PITR，您需要復製文件，添加恢復文件，然後才啟動伺服器。

但是，我不確定您是否能夠做到這一點，因為您的備份中的 WAL 似乎已損壞（LOG: invalid record length at 1/D160958; wanted 24, got 0）。

引用自：https://dba.stackexchange.com/questions/228796