引言
本文面向那些已经具备一定数据库经验、但希望进一步学习 PostgreSQL 基础知识的初学者。假设已在 Ubuntu 环境中正确安装 PostgreSQL，本文的全部操作基于 PostgreSQL 16（开发版本）与 Ubuntu 22.10 系统完成。文章将介绍三种常用的数据恢复方法：
时间点恢复（Point-In-Time Recovery，简称 PITR）是一种通过重放预写日志（Write Ahead Logging，WAL）文件，将数据库恢复至指定时间点状态的技术手段。
为说明该过程，可构建两个数据库副本，在其中一个数据库中插入数据，并将生成的 WAL 文件进行归档，随后令另一数据库重放该日志文件，以实现状态同步。
此过程类似于数据库因故障导致部分数据丢失的情形，可依靠 WAL 文件将系统恢复至故障前状态。重放 WAL 文件相当于自上一次检查点起，按顺序重新执行全部数据库操作，直至指定时间点，从而实现数据库的精确恢复。
开始使用
首先，创建一个新的数据库，并建立用于存放归档文件的文件夹。
$ initdb -D data/
$ mkdir archive/
随后，编辑该数据库的 postgresql.conf 配置文件。
port = 5432
wal_level = replica
archive_mode = on
archive_command = \'cp %p $HOME/pg/archive/%f\'
archive_timeout = 60
接着，复制整个数据库集群（由于此时尚未创建任何表或数据，实际上并无可备份的内容）。
$ cp -rp data/* data.backup/
启动主数据库。
$ pg_ctl -D data/ -l data.log start
$ createuser -s postgres
在数据库中插入测试数据。
$ psql -U postgres -c \"create database test\"
CREATE DATABASE
$ psql -U postgres -d test -c \"create table t1 (id int, val text)\"
CREATE TABLE
$ psql -U postgres -d test -c \"insert into t1 values (1, \'hello\')\"
INSERT 0 1
$ psql -U postgres -d test -c \"insert into t1 values (2, \'world\')\"
INSERT 0 1
$ psql -U postgres -d test -c \"insert into t1 values (3, \'foo\')\"
INSERT 0 1
$ psql -U postgres -d test -c \"insert into t1 values (4, \'bar\')\"
INSERT 0 1
检查归档目录，确认归档命令执行是否正常。若未生成归档文件，可手动触发数据库生成未完成的 WAL 文件。但需注意，未完成的 WAL 文件与已完成文件大小一致，频繁执行可能导致数据库体积快速膨胀。
$ psql -U postgres -c \"select pg_switch_wal()\"
pg_switch_wal
---------------
0/187BBC8
(1 row)
$ ls -l archive/
total 16384
-rw------- 1 tristen tristen 16777216 Apr 1 09:49 000000010000000000000001
停止主服务器。
$ pg_ctl -D data stop
编辑副本数据库的 postgresql.conf 文件，将 recovery_target_timeline 参数设置为 \”latest\”，以便让该副本重放 WAL 文件到最新的状态。
port = 5433
archive_mode = off
restore_command = \'cp $HOME/pg/archive/%f %p\'
recovery_target_timeline = \'latest\'
创建 recovery.signal 文件，用于指示数据库以恢复模式启动。
$ touch data.backup/recovery.signal
启动副本服务器，此时系统将进入恢复模式并开始重放 WAL 文件。
$ pg_ctl -D data.backup -l data.backup.log start
$ tail data.backup.log
2023-04-14 09:50:16.459 PDT [21530] LOG: redo done at 0/2000060 system usage: CPU: user: 0.00 s, system: 0.01 s, elapsed: 0.03 s
2023-04-14 09:50:16.459 PDT [21530] LOG: last completed transaction was at log time 2023-04-14 09:49:13.53674-07
2023-04-14 09:50:16.468 PDT [21530] LOG: restored log file \"000000010000000000000002\" from archive
cp: cannot stat \'/home/tristen/pg/archive/00000002.history\': No such file or directory
2023-04-14 09:50:16.479 PDT [21530] LOG: selected new timeline ID: 2
cp: cannot stat \'/home/tristen/pg/archive/00000001.history\': No such file or directory
2023-04-14 09:50:16.496 PDT [21530] LOG: archive recovery complete
2023-04-14 09:50:16.497 PDT [21528] LOG: checkpoint starting: end-of-recovery immediate wait
2023-04-14 09:50:16.513 PDT [21528] LOG: checkpoint complete: wrote 905 buffers (5.5%); 0 WAL file(s) added, 0 removed, 2 recycled; write=0.006 s, sync=0.007 s, total=0.018 s; sync files=259, longest=0.001 s, average=0.001 s; distance=28136 kB, estimate=28136 kB; lsn=0/3000028, redo lsn=0/3000028
2023-04-14 09:50:16.515 PDT [21525] LOG: database system is ready to accept connections
最后，检查副本数据库中的数据。
$ psql -U postgres -d test -c \"select * from t1\" -p 5433
id | val
----+-------
1 | hello
2 | world
3 | foo
4 | bar
(4 rows)
结果显示，备份已成功重放 WAL 文件，并恢复至最新的变更状态。
使用 LSN 进行时间点恢复
按照前述步骤执行操作，但在关闭主服务器之前暂停。
随后，执行命令以获取主数据库当前 WAL 文件的日志序列号（LSN, Log Sequence Number）。
$ psql -U postgres -d test -c \"select pg_current_wal_insert_lsn()\"
pg_current_wal_insert_lsn
---------------------------
0/2000060
(1 row)
将获取的 LSN 值配置到副本数据库的 postgresql.conf 文件中。
port = 5433
archive_mode = off
restore_command = \'cp $HOME/pg/archive/%f %p\'
recovery_target_lsn = \'0/2000060\'
完成设置后，关闭主数据库，并按照前述方式执行恢复操作。
$ pg_ctl -D data stop
$ touch data.backup/recovery.signal
$ pg_ctl -D data.backup -l data.backup.log start
$ psql -U postgres -d test -c \"select * from t1\" -p 5433
id | val
----+-------
1 | hello
2 | world
3 | foo
4 | bar
(4 rows)
使用时间戳进行时间点恢复
基于时间戳的恢复方式相对复杂，因为需要明确指定数据库应恢复到的具体时间点。
在操作过程中，可参照默认示例的步骤执行，直至插入数据的阶段。
$ psql -U postgres -c \"create database test\"
CREATE DATABASE
$ psql -U postgres -d test -c \"create table t1 (id int, val text)\"
CREATE TABLE
$ psql -U postgres -d test -c \"insert into t1 values (1, \'hello\')\"
INSERT 0 1
$ psql -U postgres -d test -c \"insert into t1 values (2, \'world\')\"
INSERT 0 1
$ sleep 60
$ psql -U postgres -c \"select now()\"
now
-------------------------------
2023-04-14 12:54:23.160389-07
(1 row)
$ psql -U postgres -d test -c \"insert into t1 values (3, \'foo\')\"
INSERT 0 1
$ psql -U postgres -d test -c \"insert into t1 values (4, \'bar\')\"
INSERT 0 1
$ sleep 60
$ psql -U postgres -c \"select now()\"
now
-------------------------------
2023-04-14 12:55:23.184277-07
(1 row)
在插入数据时，可通过加入 sleep 延时命令来方便管理时间戳。同时，使用 select now() 命令获取数据库当前的时间戳。与前述步骤相同，需生成剩余的 WAL 文件，并创建用于恢复的 recovery.signal 文件。
$ psql -U postgres -c \"select pg_switch_wal()\"
$ pg_ctl -D data stop
$ touch data.backup/recovery.signal
在本次操作中，应在副本数据库的 postgresql.conf 文件中添加以下配置：
port = 5433
archive_mode = off
restore_command = \'cp $HOME/pg/archive/%f %p\'
recovery_target_time = \'2023-04-14 12:54:23\'
其中，recovery_target_time 参数对应于在插入前两条数据后、插入后两条数据之前获取的时间戳。随后，启动副本服务器并查看数据内容：
$ pg_ctl -D data.backup -l data.backup.log start
$ psql -U postgres -d test -c \"select * from t1\" -p 5433
id | val
----+-------
1 | hello
2 | world
(2 rows)
此时，数据库中仅包含前两条数据，符合预期。接着，可将恢复时间设置为比前一次时间戳晚 1 秒，并按以下方式修改 recovery_target_time 参数：
recovery_target_time = \'2023-04-14 12:54:24\'
由于系统在成功完成恢复后会自动删除 recovery.signal 文件，因此需重新创建该文件：
$ touch data.backup/recovery.signal
最后，重新启动副本服务器，并按前述步骤查询表中数据：
pg_ctl -D data.backup -l data.backup.log restart
psql -U postgres -d test -c \"select * from t1\" -p 5433
id | val
----+-------
1 | hello
2 | world
3 | foo
4 | bar
(4 rows)
根据向服务器执行插入命令的速度不同，可能需要调整recovery_target_time 参数以获得理想的恢复结果。若恢复时间设置过晚，可能在日志文件中出现如下错误信息：
FATAL: recovery ended before configured recovery target was reached
该错误表明指定的恢复时间超出了可恢复范围，即时间点设置过于靠后。应将恢复时间适当提前数秒后，再次启动服务器进行恢复。
结论
至此，本文完整演示了多种数据库时间点恢复方法的实现过程。我们依次介绍了三种典型方式：基于最新时间线的恢复、基于特定 LSN（日志序列号）的恢复，以及基于指定时间戳的恢复。
不同方法适用于不同场景。熟练掌握这些恢复技术，不仅有助于提升数据库运维与管理的效率，也能在突发数据问题时，确保系统具备更高的可控性与数据安全性。
