我想要爱PostGreSQL。 我正在推动我的公司。 我希望我们能够接受越来越多的项目。 但是我个人被备份/恢复难题困扰着。 我一直在想，如果这是MS-SQL，这不会是一个问题…
我们无法恢复数据库的备份 – 不能使用pg_dump和pg_restore。 它失败了很多原因。 我搜查了很长时间 – 没有任何补救措施。 大部分数据库都得到了恢复，但关键部分却没有。
众所周知，在MS-SQL中，可以断开数据库，并复制MDB和LDB文件，然后重新连接它。 然后，我可以将这两个复制的文件复制到任何其他计算机并重新连接，并禁止可能缺less的用户帐户，根据我们的经验，我们没有任何问题。
但是pg_dump和pg_dumpall（大多数情况下只是最终迭代调用pg_dump）转储SQL命令来重新创build数据库。 不是数据库状态的字节对于字节拷贝。 假设通过运行命令pg_dump来恢复我们的数据库来创build它不起作用，是否有更接近于我可以使用的MS-SQL世界的字节级拷贝解决scheme呢？
目标是什么？ 除了显而易见的（能够在发生故障的情况下还原数据库），我正试图部署一个Vagrant开发环境。 所以我们有一个数据库的主副本，我们的数据库开发人员在她的虚拟开发环境中设置。 然后，我和其他人希望能够在重大修改后获得数据库的定期快照，并将快照加载到我们计算机上的“stream量”中。
如果我们可以轻松地备份和恢复数据库，这不会是一个问题。 这将工作得很好。 我宁愿不必复制整个虚拟机来共享数据库更改。
我试过的不同于pg_dump [all]和pg_restore的唯一的东西是SymmetricDS，但它打破了数据库…也许是通过configuration错误，或者是因为它试图做同样的东西pg_dump。 不确定。
我怀疑我会得到关于为什么pg_restore失败的问题。 因此，为了简单说明一下，第三方软件和我们安装的自定义数据types，操作符和函数与相互依赖的模式（ArcSDE和PostGIS）没有按照正确的顺序创build，因为pg_dump认为它们应该被创build。 我也相信（尽pipe不能certificate）在pg_dump备份开始时设置的search_path是错误的，这不利于恢复进程已经被模式相互依赖性所阻碍。
你可以在PostgreSQL上做一个物理/文件级别的备份，虽然这不是标准的做法（我会尽力让pg_dump工作， 你有没有在邮件列表上问过 ） ？
作为另一种select，您是否考虑过使用“实时”时间点备份/恢复进行复制的设置？
无论如何，要以最less的停机时间进行物理备份，您必须：
/var/lib/pgsql ） 由于拍摄快照速度非常快，这可以最大限度地减less停机时间。
要在另一个PostgreSQL服务器上恢复数据库，请执行以下操作：
mv /var/lib/pgsql /var/lib/pgsql_original ） mv mycopy /var/lib/pgsql ） 请注意，这种types的备份只能用于相同的PostgreSQL版本和相同的版本（例如：不能在x86_64 / 64位机器上恢复i386 / 32位备份）。