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