另一种备份策略是直接复制 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 不需要导出索引的内容，而只需要重新创建它们的命令。）但是，执行文件系统备份可能会更快。
如果您在文档中发现任何不正确的内容、与您对特定功能的体验不符的内容或需要进一步澄清的内容，请使用此表单 报告文档问题。