另一种备份策略是直接复制PostgreSQL用来存储数据库数据的文件；Section 18.2解释了这些文件的位置。你可以使用自己喜欢的任何方法进行文件系统备份，例如：
tar -cf backup.tar /usr/local/pgsql/data
不过，这种方法有两个限制，使得它并不实用，至少也不如pg_dump方法：
为了得到可用的备份，数据库服务器必须关闭。像禁止所有连接这样的折中办法不起作用（部分原因是tar和类似工具不会对文件系统状态执行原子快照，另一部分原因是服务器内部也存在缓冲）。有关停止服务器的信息见Section 18.5。不言而喻，恢复数据前也必须关闭服务器。
如果你已经深入了解数据库文件系统布局的细节，可能会想尝试仅通过某些表或数据库各自的文件或目录来备份或恢复它们。这是行不通的，因为这些文件中的信息离开记录所有事务提交状态的提交日志文件pg_xact/*就无法使用。一个表文件只有和这些信息一起才可用。当然，也不可能只恢复一个表以及相关的pg_xact数据，因为那会让数据库集簇中的其他所有表都无法使用。因此，文件系统备份只适用于整个数据库集簇的完整备份与恢复。
另一种文件系统备份方法是对数据目录制作一个“一致快照”，前提是文件系统支持该功能（并且你愿意相信其实现是正确的）。典型流程是：对包含数据库的卷制作一个“冻结快照”，然后从该快照把整个数据目录（不是其中一部分，见上文）复制到备份设备，再释放这个冻结快照。即使数据库服务器正在运行，这种方法也能工作。不过，以这种方式创建的备份会把数据库文件保存为一种仿佛服务器没有被正确关闭的状态；因此，当你基于备份数据启动数据库服务器时，它会认为前一个服务器实例发生了崩溃，并重放 WAL 日志。这不是问题；只要意识到这一点即可（并且务必把 WAL 文件也包含在备份中）。你可以在获取快照之前执行一次CHECKPOINT，以缩短恢复时间。
如果数据库分布在多个文件系统上，就可能根本无法对所有卷获得完全同步的冻结快照。例如，如果数据文件和 WAL 日志位于不同磁盘，或者表空间位于不同文件系统上，就可能无法使用快照备份，因为这些快照必须同时获取。在这种情况下，在信任一致快照技术之前，一定要非常仔细地阅读文件系统文档。
如果无法获得同时的快照，一种选择是将数据库服务器关闭足够长的时间，以建立所有冻结快照。另一种选择是执行持续归档基础备份（Section 25.3.2），因为这种备份不受备份期间文件系统变化的影响。这要求只在备份过程中启用持续归档；恢复则使用持续归档恢复（Section 25.3.4）。
另一种选择是使用rsync进行文件系统备份。做法是先在数据库服务器运行时执行一次rsync，然后将数据库服务器关闭足够长的时间，再执行一次rsync --checksum。（之所以需要--checksum，是因为rsync对文件修改时间的粒度只有 1 秒。）第二次rsync会比第一次更快，因为它需要传输的数据相对较少，而最终结果会因为服务器已经关闭而保持一致。这种方法可以在最小停机时间下完成文件系统备份。
注意，文件系统备份通常会比 SQL 转储更大。（例如，pg_dump不需要转储索引内容，只需转储重建索引的命令。）不过，进行文件系统备份可能更快。
如果您发现文档中有不正确的内容、与您使用特定功能的经验不符或需要进一步说明，请使用此表单来报告文档问题。