Figuren

24.2. 文件系统级别的备份

另一个备份的策略是直接拷贝PostgreSQL用于存放数据库数据的文件。 Section 17.2里解释了这些文件的位置，不过如果你想用这个方法，你应该早就找到它们的位置了。你可以用任何自己喜欢的方法备份文件系统，例如:

tar -cf backup.tar /usr/local/pgsql/data

不过，你要受到两个限制，令这个方法不那么实用，或者至少比pg_dump的方法逊色一些：

为了进行有效的备份，数据库服务器必须被关闭。像拒绝所有连接这样的折衷的方法是不行的，(一部分是因为tar和类似的工具不能对文件系统的状态做原子快照，但也会是因为服务器的内部缓冲问题) 有关关闭服务器的信息可以在Section 17.5里面找到。不用说，你在恢复数据之前，同样必须关闭服务器。
如果你曾经深入了解了数据库在文件系统布局的细节，你可能试图从对应的文件或目录里备份几个表或者数据库。这样做是没用的，因为如果不提交日志文件包含在这些文件里的信息是不可用的， pg_clog/*，它包含所有事务的提交状态。只有拥有这些信息，表文件的信息才是可用的。当然，试图只恢复表和相关的pg_clog数据也是徒劳的，因为这样会把数据库集群里的所有其它没有用的表的信息都拿出来。所以文件系统的备份只适用于完整备份和一个数据库集群的完整恢复。

另外一个文件系统备份的方法是给数据目录做一个"一致的快照"，条件是文件系统支持这个功能(并且你愿意相信它是实现正确的)。典型的过程是制作一个包含数据库的卷的"冻结快照"，然后把整个数据库目录(不仅仅是部分，见上文)从快照拷贝到备份设备，然后释放冻结快照。这样甚至在数据库服务器在运行的时候都可以运转。不过，这样创建的备份会把数据库文件保存在一个没有恰当关闭数据库服务器的状态下；因此，如果你在这个备份目录下启动数据库服务器，它就会认为数据库服务器经历过崩溃并且重放WAL日志。这不是个问题，只要意识到它即可(并且确信在自己的备份中包含WAL文件)。

如果你的数据库分布在多个文件系统上，那么可能就没有任何方法获取所有卷上准确的同步冻结快照。比如，你的数据文件和WAL日志在不同的磁盘上,或者表空间在不同的文件系统上，这种情况下就不可能使用快照，因为快照必须是同时的。在你信任这样的情况下的一致性快照的技术之前，仔细阅读你的文件系统文档。

如果同步快照是不可能的，一个选择就是关闭数据库足够长的时间以便建立所有的冰冻快照。另一个选择是执行连续归档基础备份(Section 24.3.2)这样的备份可以避免在备份时对文件系统产生变更。这需要在备份时启用连续归档；用连续存档恢复存储。

另外一个选择是使用rsync执行一次文件系统备份。这是通过在数据库服务器正在运行的时候运行第一次rsync，然后关闭数据库服务器一段足够的时间长度，用于运行第二次rsync。第二次rsync会比第一次快很多，因为它要传输的数据相对较少，并且最后的结果是一致的，因为服务器已经停止运行了。这个方法允许用很少的时间执行一次文件系统备份。

还要说明的是，文件系统备份通常会比SQL转储大。（比如pg_dump不用转储内容索引，只是创建它们的命令。）然而，让一个文件系统备份可能会快点。

Vorheriger Artikel： Nächster Artikel：