25.2. 文件系统级备份

另一种备份策略是直接复制 PostgreSQL 用于将数据存储在数据库中的文件。 Section 18.2说明了这些文件的位置。您可以使用自己喜欢的任何方法进行文件系统备份。例如：

tar -cf backup.tar /usr/local/pgsql/data

但是，有两个限制使该方法不切实际，或者至少不如 pg_dump 方法逊色：

• 必须关闭数据库服务器才能获得可用的备份。诸如禁止所有连接之类的中途措施将“不起作用”(部分原因是tar和类似工具没有对文件系统状态进行原子快照，而且还因为服务器内部存在缓冲)。可以在Section 18.5中找到有关停止服务器的信息。不用说，您还需要在还原数据之前关闭服务器。

• 如果您已深入研究数据库的文件系统布局的详细信息，则可能会尝试尝试仅从其各自的文件或目录中备份或还原某些单独的表或数据库。这将不起作用，因为如果没有包含所有事务的提交状态的提交日志文件pg_xact/*，这些文件中包含的信息将无法使用。表文件仅可用于此信息。当然，仅还原表和关联的pg_xact数据也是不可能的，因为这会使数据库集群中的所有其他表失效。因此，文件系统备份仅适用于完整数据库集群的完整备份和还原。

另一种文件系统备份方法是，如果文件系统支持该功能(并且您愿意相信它已正确实现)，则为数据目录创建“一致性快照”。典型的过程是为包含数据库的卷创建“冻结快照”，然后将整个数据目录(不仅仅是部分，请参见上文)从快照复制到备份设备，然后释放冻结快照。即使数据库服务器正在运行，这也将起作用。但是，以这种方式创建的备份会将数据库文件保存在某种状态下，就好像数据库服务器未正确关闭一样。因此，当您在备份的数据上启动数据库服务器时，它将认为先前的服务器实例崩溃了，并且将重播 WAL 日志。这不是问题;请注意这一点(并确保在备份中包含 WAL 文件)。您可以在拍摄快照之前执行CHECKPOINT以减少恢复时间。

如果您的数据库分布在多个文件系统中，则可能无法以任何方式获取所有卷的完全同步的冻结快照。例如，如果数据文件和 WAL 日志位于不同的磁盘上，或者表空间位于不同的文件系统上，则可能无法使用快照备份，因为快照必须同时进行。在这种情况下，请先仔细阅读文件系统文档，然后再使用一致快照技术。

如果不可能同时创建快照，则一种选择是关闭数据库服务器足够长的时间以构建所有冻结的快照。另一种选择是执行连续归档基础备份(Section 25.3.2)，因为此类备份不受备份期间文件系统更改的影响。这要求仅在备份过程中启用连续归档。使用连续存档恢复(Section 25.3.4)完成还原。

另一种选择是使用 rsync 来执行文件系统备份。这是通过首先在数据库服务器运行时运行 rsync，然后关闭数据库服务器足够长的时间来完成rsync --checksum来完成的。 (--checksum是必需的，因为rsync仅具有一秒钟的文件修改时间粒度.)第二个 rsync 将比第一个 rsync 快，因为它要传输的数据相对较少，并且最终结果将是一致的，因为服务器已关闭。此方法允许在最少停机时间的情况下执行文件系统备份。

请注意，文件系统备份通常比 SQL 转储大。 (例如，pg_dump 不需要转储索引的内容，只需转储重新创建索引的命令.)但是，进行文件系统备份可能会更快。