数据库PostrageSQL-文件系统级别备份

25.2. 文件系统级别备份

另一种备份策略是直接复制PostgreSQL用于存储数据库中数据的文件，Section 18.2解释了这些文件的位置。你能够采用任何你喜欢的方式进行文件系统备份，例如：

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

可是这种方法有两个限制，使得这种方法不实用，或者说至少比pg_dump方法差：

1. 为了获得一个可用的备份，数据库服务器必须被关闭。例如阻止全部链接的半路措施是不起做用的（部分缘由是tar和相似工具没法获得文件系统状态的一个原子的快照，还有服务器内部缓冲的缘由）。关于中止服务器的信息能够在Section 18.5中找到。不用说，在恢复数据以前你也须要关闭服务器。
2. 若是你已经深刻地了解了数据库的文件系统布局的细节，你可能会有兴趣尝试经过相应的文件或目录来备份或恢复特定的表或数据库。这种方法也不会起做用，由于包含在这些文件中的信息只有配合提交日志文件（pg_xact/*）才有用，提交日志文件包含了全部事务的提交状态。一个表文件只有和这些信息一块儿才有用。固然也不可能只恢复一个表及相关的pg_xact数据，由于这会致使数据库集簇中全部其余表变得无用。所以文件系统备份值适合于完整地备份或恢复整个数据库集簇。

另外一种文件系统备份方法是建立一个数据目录的“一致快照”，若是文件系统支持此功能（而且你相信它的实现正确）。典型的过程是建立一个包含数据库的卷的“冻结快照”，而后从该快照复制整个数据目录（如上，不能是部分复制）到备份设备，最后释放冻结快照。

即便在数据库服务器运行时，这种方式也有效。可是，以这种方式建立的备份保存的文件看起来就像数据库没有被正确关闭时的状态。所以，当你从备份数据上启动数据库服务器时，它会认为上一次的服务器实例崩溃了并尝试重放WAL日志。这不是问题，只是须要注意（当
然WAL文件必需要包括在备份中）。你能够在拍摄快照以前执行一次CHECKPOINT以便节省恢复时间。

若是你的数据库跨越多个文件系统，可能没有任何方式能够对全部卷得到彻底同步的冻结快照。例如，若是你的数据文件和WAL日志放置在不一样的磁盘上，或者表空间在不一样的文件系统中，可能没有办法使用快照备份，由于快照必须是同步的。在这些状况下，必定要仔细阅读你的文件系统文档以了解其对一致快照技术的支持。

若是没有可能得到同步快照，一种选择是将数据库服务器关闭足够长的时间以创建全部的冻结快照。另外一种选择是执行一次连续归档基础备份（Section 25.3.2），由于这种备份对于备份期间发生的文件系统改变是免疫的。这要求在备份过程当中容许连续归档，恢复时使用连续归档恢复（Section 25.3.4）。

还有一种选择是使用rsync来执行一次文件系统备份。其作法是先在数据库服务器运行时执行rsync，而后关闭数据库服务器足够长时间来作一次rsync --checksum （–checksum是必需的，由于rsync的文件修改 时间粒度只能精确到秒）。第二次rsync会比第一次快，由于它只须要传送相对不多的数据，因为服务器是中止的，因此最终结果将是一致的。这种方法容许在最小停机时间内执行一次文件系统备份。

注意一个文件系统备份一般会比一个SQL转储体积更大（例如pg_dump不须要转储索引的内容，而是转储用于重建索引的命令）。可是，作一次文件系统备份可能更快.

本文同步分享在 博客“cwl_java”（CSDN）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。