另一种备份策略是直接复制 PostgreSQL 用于存储数据库文件的文件； 第 18.2 节 解释了这些文件的位置。您可以使用任何您喜欢的文件系统备份方法；例如
tar -cf backup.tar /usr/local/pgsql/data
然而，有两个限制，这使得这种方法不切实际，或者至少不如 pg_dump 方法 第 25.2.1 节
为了获得可用的备份，数据库服务器必须关闭。半途而废的方法，例如禁止所有连接，将不起作用（部分原因是 tar 和类似工具无法对文件系统状态进行原子快照，也因为服务器内部存在缓冲）。有关停止服务器的信息可以在 第 18.5 节 中找到。不用说，在恢复数据之前您也需要关闭服务器。
如果您深入研究了数据库的文件系统布局的细节，您可能会尝试仅从各自的文件或目录备份或恢复特定的单个表或数据库。这不起作用，因为这些文件中的信息在没有提交日志文件 pg_xact/* 的情况下是无法使用的，这些文件包含所有事务的提交状态。表文件仅与此信息一起可用。当然，这也无法仅恢复一个表以及相关的 pg_xact 数据，因为那样会让数据库集群中的所有其他表都变得无用。因此，文件系统备份仅适用于整个数据库集群的完整备份和恢复。
另一种文件系统备份方法是制作数据目录的“一致快照”，如果文件系统支持该功能（并且您愿意相信它已正确实现）。典型的过程是制作包含数据库的卷的“冻结快照”，然后将整个数据目录（不是部分，见上文）从快照复制到备份设备，然后释放冻结快照。即使在数据库服务器运行时，这也能正常工作。但是，以这种方式创建的备份会以数据库服务器未正确关闭的状态保存数据库文件；因此，当您在备份的数据上启动数据库服务器时，它会认为之前的服务器实例崩溃了，并会重放 WAL 日志。这不成问题；只需注意这一点（并确保将 WAL 文件包含在备份中）。您可以在拍摄快照之前执行 CHECKPOINT 以缩短恢复时间。
如果您的数据库分布在多个文件系统上，可能无法获得所有卷的完全同时的冻结快照。例如，如果您的数据文件和 WAL 日志在不同的磁盘上，或者表空间在不同的文件系统上，则可能无法使用快照备份，因为快照必须是同时的。在这种情况下，在信任一致性快照技术之前，请非常仔细地阅读您的文件系统文档。
如果无法进行同时快照，一种选择是关闭数据库服务器足够长的时间以建立所有冻结快照。另一种选择是执行连续归档基础备份（第 25.3.2 节），因为这类备份在备份过程中不受文件系统更改的影响。这需要在备份过程中启用连续归档；恢复使用连续归档恢复（第 25.3.5 节）。
另一种选择是使用 rsync 执行文件系统备份。这可以通过先在数据库服务器运行时运行 rsync，然后关闭数据库服务器足够长的时间以执行 rsync --checksum 来完成。（--checksum 是必需的，因为 rsync 仅具有一秒的文件修改时间粒度。）第二次 rsync 将比第一次更快，因为它需要传输的数据相对较少，并且由于服务器已关闭，最终结果将是一致的。这种方法允许以最小的停机时间执行文件系统备份。
请注意，文件系统备份通常比 SQL 转储更大。（例如，pg_dump 不需要转储索引的内容，只需重建它们的命令。）但是，进行文件系统备份可能会更快。
如果您在文档中看到任何不正确的内容、与您对特定功能的实际体验不符的内容或需要进一步澄清的内容，请使用 此表单 报告文档问题。