Postgresql 中文操作指南
26.2. File System Level Backup #
一种备选的备份策略是直接复制 PostgreSQL 用于在数据库中存储数据的文件; Section 19.2说明了这些文件的位置。你可以使用任何你首选的方法进行文件系统备份;例如:
tar -cf backup.tar /usr/local/pgsql/data
然而,有两个限制使得此方法不可行,或者至少劣于 pg_dump 方法:
另一种文件系统备份方法是制作数据目录的“一致快照”,如果文件系统支持该功能(且你愿意相信它已正确实现)。典型过程是制作包含数据库的卷的“冻结快照”,然后将整个数据目录(不仅仅是一部分,见上文)从快照复制到备份设备,然后释放冻结快照。即使数据库服务器正在运行,此方法也能正常工作。然而,使用此方法创建的备份将以数据库服务器未正确关闭的状态保存数据库文件;因此,当你在备份的数据上启动数据库服务器时,它将认为之前的服务器实例已崩溃,并将重放 WAL 日志。这不是问题;只需注意它(并确保在你的备份中包含 WAL 文件)。你可以在获取快照之前执行 CHECKPOINT 以缩短恢复时间。
如果你的数据库分布在多个文件系统中,则可能无法对所有卷获取完全同时的冻结快照。例如,如果你的数据文件和 WAL 日志位于不同的磁盘上,或者表空间位于不同的文件系统上,则可能无法使用快照备份,因为快照 must 是同时的。在此类情况下,在信任一致快照技术之前非常仔细地阅读文件系统文档。
如果无法同时建立快照,一种选择是关闭数据库服务器足够长的时间以建立所有冻结快照。另一种选择是执行连续归档基础备份 ( Section 26.3.2),因为此类备份对备份期间的文件系统更改免疫。这需要在备份过程中启用连续归档;使用连续归档恢复 ( Section 26.3.4)进行还原。
另一种选择是用 rsync 执行文件系统备份。这是通过在数据库服务器运行时首先运行 rsync,然后关闭数据库服务器(以允许执行 rsync --checksum),进而完成的。(—checksum 必须,因为 rsync 的文件修改时间粒度仅为一秒。) 第二个 rsync 将比第一个更快,因为它只需传输相对较少的数据,且最终结果将保持一致,因为服务器已关闭。此方法允许以最短的停机时间执行文件系统备份。
请注意,文件系统备份通常会大于 SQL 转储。(pg_dump 无需转储索引的内容,例如,仅需传输重新创建它们的命令。) 然而,执行文件系统备份可能会更快。