在PostgreSQL中，有三种备份方式：

SQL备份（逻辑备份） ：其实就是利用数据库自带的类似dump的命令，或者是你用图形化界面执行导入导出时，底层就是基于这个dump命令实现的。备份出来一份sql文件，谁需要就复制给谁。

优点：简单，方便操作，有手就行，还挺可靠。

缺点：数据量比较大，这种方式巨慢，可能导出一天，都无法导出完所有数据。

文件系统备份（物理备份） ：其实就是找到当前数据库，数据文件在磁盘存储的位置，将数据文件直接复制一份或多份，存储在不同的物理机上，即便物理机爆炸一个，还有其他物理机。

优点：相比逻辑备份，恢复的速度快。

缺点：在备份数据时，可能数据还正在写入，一定程度上会丢失数据。在恢复数据时，也需要注意数据库的版本和环境必须保持高度的一致。如果是线上正在运行的数据库，这种复制的方式无法在生产环境实现。

如果说要做数据的迁移，这种方式还不错滴。

归档备份：（也属于物理备份）

先了解几个概念，在PostgreSQL有多个子进程来辅助一些操作

BgWriter进程：BgWriter是将内存中的数据写到磁盘中的一个辅助进程。当向数据库中执行写操作后，数据不会马上持久化到磁盘里。这个主要是为了提升性能。BgWriter会周期性的将内存中的数据写入到磁盘。但是这个周期时间，长了不行，短了也不行。
- 如果快了，IO操作频繁，效率慢。
- 如果慢了，有查询操作需要内存中的数据时，需要BgWriter现把数据从内存写到磁盘中，再提供给查询操作作为返回结果。会导致查询操作效率变低。
- 考虑一个问题： 事务提交了，数据没落到磁盘，这时，服务器宕机了怎么办？
WalWriter进程：WAL就是write ahead log的缩写，说人话就是预写日志（redo log）。其实数据还在内存中时，其实已经写入到WAL日志中一份，这样一来，即便BgWriter进程没写入到磁盘中时，数据也不会存在丢失的问题。
- WAL能单独做备份么？单独不行！
- 但是WAL日志有个问题，这个日志会循环使用，WAL日志有大小的线程，只能保存指定时间的日志信息，如果超过了，会覆盖之前的日志。
PgArch进程：WAL日志会循环使用，数据会丢失。没关系，还有一个归档的进程，会在切换wal日志前，将WAL日志备份出来。PostgreSQL也提供了一个全量备份的操作。可以根据WAL日志，选择一个事件点，进行恢复。

查看一波WAL日志：

这些就是归档日志

wal日志的名称，是三块内容组成，

没8个字符分成一组，用16进制标识的

00000001 00000000 0000000A

时间线逻辑id 物理id

查询当前库用的是哪个wal日志

-- 查看当前使用的wal日志  查询到的lsn：0/47233270
select pg_current_wal_lsn();
-- 基于lsn查询具体的wal日志名称  000000010000000000000047
select pg_walfile_name('0/47233270');

归档默认不是开启的，需要手动开启归档操作，才能保证wal日志的完整性。

修改postgresql.conf文件

# 开启wal日志的内容，注释去掉即可
wal_level = replica
fsync = on

# 开启归档操作
archive_mode = on
# 修改一小下命令，修改存放归档日志的路径
archive_command = 'test ! -f /archive/%f && cp %p /archive/%f'

修改完上述配置文件后，记得重启postgreSQL进程，才会生效！！！！

归档操作执行时，需要保证/archive存在，并且postgres用户有权限进行w操作

构建/archive路径

# postgres没有权限在/目录下构建目录
# 切换到root，构建目录，将目录的拥有者更改为postgres
mkdir /archive
chown -R postgres. archive

在当前库中做大量写操作，接入到wal日志，重置切换wal日志，再查看归档情况发现，将当前的正在使用的wal日志和最新的上一个wal日志归档过来了，但是之前的没归档，不要慌，后期备份时，会执行命令，这个命令会直接要求wal日志立即归档，然后最全量备份。