另一种备份策略是直接复制 PostgreSQL 用于在数据库中存储数据的文件；第 18.2 节 解释了这些文件的位置。 您可以使用任何您喜欢的方法来进行文件系统备份；例如
tar -cf backup.tar /usr/local/pgsql/data
然而，有两个限制使得这种方法不切实际，或者至少不如 pg_dump 方法
为了获得可用的备份，数据库服务器必须关闭。 禁止所有连接等半途而废的措施不起作用（部分原因是 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 不需要转储索引的内容，只需要重新创建它们的命令。）但是，进行文件系统备份可能会更快。
如果您在文档中发现任何不正确、与您使用特定功能的经验不符或需要进一步说明的内容，请使用此表单报告文档问题。