另一个备份的策略是直接拷贝PostgreSQL用于存放数据库数据的文件。 我们在 Section 16.2 里解释了这些文件的位置， 不过如果你想用这个方法，你早就找到它们的位置。 你可以用自己喜欢的任何常用文件系统备份的方法，例如
tar -cf backup.tar /usr/local/pgsql/data
不过，你要受到两个限制，令这个方法不那么实用，或者至少比 pg_dump 的方法逊色一些：
为了进行有效的备份，数据库服务器必须被关闭。 象拒绝所有联接这样的折衷的方法是不行的，因为总是有一些缓冲区数据存在。 （主要因为 tar 和类似的工具在做备份的时候并不对文件系统的状态做原子快照）。 有关关闭服务器的信息可以在 Section 16.6里面找到。 不用说，你在恢复数据之前，必须关闭服务器。
如果你曾经深入了解了数据库在文件系统布局的细节，你可能试图从对应的文件或目录里备份几个表或者数据库。 这样做是没用的，因为包含在这些文件里的信息只是部分信息。还有一半信息在提交日志文件 pg_clog/*里面，它包含所有事务的提交状态。 只有拥有这些信息，表文件的信息才是可用的。当然，试图只恢复表和相关的 pg_clog 数据也是徒劳的，因为这样会把数据库集群里的所有其他没有用的表的信息都拿出来。 所以文件系统的备份只适用于一个数据库集群的完整恢复。
另外一个文件系统备份的方法是给数据目录做一个"一致的快照"， 条件是文件系统支持这个功能（并且你愿意相信它是实现正确的）。 典型的过程是制作一个包含数据库的卷的"冻结快照"， 然后把整个数据库目录（不仅仅是部分，见上文）从快照拷贝到备份设备， 然后释放冻结快照。这样甚至在数据库服务器在运行的时候都可以运转。 不过，这样创建的备份会把数据库文件保存在一个没有恰当关闭数据库服务器的状态下； 因此，如果你在这个备份目录下启动数据库服务器， 它就会认为数据库服务器经历过崩溃并且重放 WAL 日志。这不是个问题，只要意识到它即可（并且确信在自己的备份中包含 WAL 文件）。
如果你的数据库分布在多个卷上（比如，数据文件和 WAL 日志在不同的磁盘上），那么可能就没有任何方法获取所有卷上准确的同步冻结快照。 在你新闻这样的情况下的一致性快照的技术之前，仔细阅读你的文件系统文档。 最安全的方法是关闭数据库服务器足够长的时间，以建立所有冻结快照。
还要说明的是，文件系统备份不会比SQL转储小。恰恰相反，大多数情况下它要大。 （比如pg_dump 不用倒出索引，只是创建它们的命令。）