一种替代备份策略是直接复制 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 无需转储索引内容，只需转储重建索引的命令。）但是，执行文件系统备份可能会更快。