我正在尝试喜欢 PostGreSQL。我正在公司推广它。我希望我们在越来越多的项目中采用它。但我个人对备份/恢复问题感到困惑。我一直在想，如果这是 MS-SQL，这不会是个问题……
我们无法恢复数据库的备份 - 无法使用 pg_dump 和 pg_restore。它失败的原因有很多。我搜索了好几个小时 - 都没有解决办法。数据库的大部分内容确实恢复了，但关键部分没有恢复。
众所周知，在 MS-SQL 中，可以断开数据库，复制 MDB 和 LDB 文件，然后重新连接。然后我可以将这两个复制的文件带到任何其他计算机上并重新连接它们，除非可能缺少用户帐户，否则根据我们的经验，我们没有遇到任何问题。
但是 pg_dump 和 pg_dumpall（大多数情况下只是迭代调用 pg_dump）会转储 SQL 命令以重新创建数据库。而不是逐字节复制数据库的状态。鉴于通过运行 pg_dump 发出的命令来创建数据库无法恢复数据库，我可以使用 MS-SQL 世界中更接近字节级复制解决方案的替代方案吗？
目标是什么？除了显而易见的（能够在发生故障时恢复数据库）之外，我还在尝试部署 Vagrant 开发环境。因此，我们有一个数据库主副本，我们的数据库开发人员在她的虚拟开发环境中设置了该副本。然后，我和其他人希望能够在进行重大修改后定期获取数据库的快照，并将快照加载到我们机器上的 Vagrants 中。
如果我们可以轻松备份和恢复数据库，那么这将不是问题。它会运行得很好。我宁愿不必复制整个虚拟机来共享数据库更改。
我尝试过的唯一不同于摆弄 pg_dump[all] 和 pg_restore 的事情是 SymmetricDS，但它破坏了数据库……可能是由于配置错误，也可能是因为它试图做与 pg_dump 相同的事情。不确定。
我怀疑我会被问到为什么 pg_restore 会失败。因此，简单解释一下，这与第三方软件和我们安装到相互依赖的架构（ArcSDE 和 PostGIS）中的自定义数据类型、运算符和函数有关，这些自定义数据类型、运算符和函数没有按照 pg_dump 认为的正确顺序创建。我还认为（虽然无法证明）在 pg_dump 备份开始时设置的 search_path 是错误的，这对已经受到架构相互依赖性阻碍的恢复过程没有帮助。
答案1
您可以在 PostgreSQL 上进行物理/文件级备份，尽管这不是标准做法（我会尽力让 pg_dump 正常工作；您在邮件列表上问过吗？）
作为另一种选择，您是否考虑过复制设置，具有“实时”时间点备份/恢复？
无论如何，为了以最少的停机时间进行物理备份，您必须：
- 停止 PostgreSQL
- 拍摄 LVM 快照里面你的虚拟机
- 重启 PostgreSQL
- 将 LVM 快照挂载到虚拟机内的合适目录中
- 复制整个数据库集群目录（例如
/var/lib/pgsql：） - 卸载并删除 LVM 快照
由于拍摄快照非常快，这将最大限度地减少停机时间。
要在另一台 PostgreSQL 服务器上恢复数据库，请执行以下操作：
- 停止 PostgreSQL
- 删除/重命名数据库集群目录（例如
mv /var/lib/pgsql /var/lib/pgsql_original：） - 恢复数据库集群目录的副本（例如
mv mycopy /var/lib/pgsql：） - 如果启用了 SELINUX，请重新标记新目录（例如：`restorecon -RF /var/lib/pgsql）
- 重启 PostgreSQL
请注意，这种备份可用于仅有的同一 PostgreSQL 版本之间和相同的 arch（即：您无法在 x86_64/64 位机器上恢复 i386/32 位备份）。