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