# 24.2\. 文件系统级别备份 另一个备份的策略是直接拷贝PostgreSQL用于存放数据库数据的文件。 我们在[Section 17.2](#calibre_link-976)里解释了这些文件的位置， 你可以用自己喜欢的任何常用文件系统备份的方法， 例如： ``` tar -cf backup.tar /usr/local/pgsql/data ``` 不过，你要受到两个限制，令这个方法不那么实用，或者至少比pg_dump的方法逊色一些： 1. 为了进行有效的备份，数据库服务器_必须_被关闭。 像拒绝所有连接这样的折衷的方法是_不行_的， （部分因为`tar`和类似的工具在做备份的时候并不对文件系统的状态做原子快照。 但也因为服务器内部缓冲数据）。 有关关闭服务器的信息可以在[Section 17.5](#calibre_link-634)里面找到。 不用说，你在恢复数据之前， 同样必须关闭服务器。 2. 如果你曾经深入了解了数据库在文件系统布局的细节， 你可能试图从对应的文件或目录里备份几个表或者数据库。 这样做是_没用_的，因为包含在这些文件里的信息只是部分信息。 还有一半信息在提交日志文件`pg_clog/*`里面， 它包含所有事务的提交状态。 只有拥有这些信息，表文件的信息才是可用的。当然， 试图只恢复表和相关的`pg_clog`数据也是徒劳的， 因为这样会把数据库集群里的所有其它没有用的表的信息都拿出来。 所以文件系统的备份只适用于一个数据库集群的完整恢复。 另外一个文件系统备份的方法是给数据目录做一个"一致的快照"， 条件是文件系统支持这个功能(并且你愿意相信它是实现正确的)。 典型的过程是制作一个包含数据库的卷的"冻结快照"， 然后把整个数据库目录(不仅仅是部分，见上文)从快照拷贝到备份设备， 然后释放冻结快照。这样甚至在数据库服务器在运行的时候都可以运转。 不过，这样创建的备份会把数据库文件保存在一个没有恰当关闭数据库服务器的状态下； 因此，如果你在这个备份目录下启动数据库服务器， 它就会认为数据库服务器经历过崩溃并且重放WAL日志。 这不是个问题，只要意识到它即可(并且确信在自己的备份中包含WAL文件)。 在采用快照减少恢复时间之前，你可以执行`CHECKPOINT`。 如果你的数据库分布在多个文件系统上， 那么可能就没有任何方法获取所有卷上准确的同步冻结快照。比如， 你的数据文件和WAL日志在不同的磁盘上，或者表空间在不同的文件系统上， 这种情况下就不可能使用快照，因为快照_必须_是同时的。 在你信任这样的情况下的一致性快照的技术之前，仔细阅读你的文件系统文档。 如果同步快照是不可能的，该选项关闭数据库服务器足够长的时间来建立所有冰冻的快照。 另一种选择是执行一个连续归档基础备份([Section 24.3.2](#calibre_link-1632)) 因为这样的备份在备份过程中免于文件系统变化。这需要在备份过程中启动连续归档。 恢复是通过使用连续存档恢复([Section 24.3.4](#calibre_link-1634))完成的。 另外一个选择是使用rsync执行一次文件系统备份。 这是通过在数据库服务器正在运行的时候运行第一次rsync， 然后关闭数据库服务器一段足够的时间长度，用于运行第二次rsync。 第二次rsync会比第一次快很多，因为它要传输的数据相对较少， 并且最后的结果是一致的， 因为服务器已经停止运行了。这个方法允许用很少的时间执行一次文件系统备份。 需要注意的是文件系统备份往往比SQL转储大。 比如pg_dump不用导出索引， 只是创建它们的命令。然而，文件系统备份可能会更快。