我按照 PostgreSQL 9 管理手册（Riggs/Krosing）中的“独立热物理数据库备份”方法编写了一个脚本来执行 Postgresql 9.0.8 数据库的物理备份，但我对其进行了修改以适应 Windows Server 2008 R2。
对于配方的第 4 步，使用 rsync 复制所有数据文件（不包括 pg_xlog 目录），我使用的是 robocopy.exe（因为 rsync 是一个 *nix 实用程序，而我使用的是 Windows）。问题是，通常其中一个文件无法复制，并导致“访问被拒绝”。手动复制文件失败，并显示“访问被拒绝”长的在备份脚本失败后 - 所以这不是可以重试的间歇性问题。只有在重新启动 PostgreSQL 进程后才能复制该文件。它始终是一个不同的文件。昨晚它是 %PGDATADIR%\5432\base\24609\38122 。
我很想听听您是否遇到过这种情况以及您如何解决此问题。我正在考虑：
- 在备份之前重新启动 PostgreSQL 服务器（我承认这是黑客行为）
- 使用某种可以复制打开文件的实用程序，例如 VSHADOW、DISKSHADOW 和 hobocopy（注意：不是 robocopy）
- 也许有某种方法可以指示 PostgreSQL 释放所有锁？
- [添加] 见下文 - 看起来定期进行“吸尘”可以消除症状
答案1
好的，首先要做的事情是——放下你的食谱。去读读吧Postgres 手册中有关备份的部分。阅读整章 - 它并不长。
（您可能会注意到本书与本书之间存在一些相似之处 - 大多数 Postgres 书籍只是手册的美化版本 - 但您应该始终以手册为主要参考。）
下面我将使用的所有术语均来自手册（因此，如果您认为您可以跳过阅读任务，那么您不能——如果您这样做，您可能会感到非常困惑）。
现在针对您的实际问题 - Unix 解决方案通常不能直接移植到 Windows，这是其中一种情况：*nix 系统会很乐意抓取正在操作的文件 - Windows 会抛出您看到的错误。
如何处理这个问题取决于您进行的备份类型。
文件系统级备份
如果你正在做“文件系统级备份”你必须关闭服务器。结束讨论，别无选择。必须完全关闭数据库才能使该类型的备份可靠（如果您获得的备份不可靠，那还有什么意义呢？）。
连续归档/时间点恢复和从属服务器
如果你正在做基地备份作为设置的一部分时间点恢复& 日志传送您有两个选择：
- 无论如何都要关闭服务器。
- 使用可以复制打开文件的工具（问题中的选项（2））
然后，按照时间点恢复/日志传送的其余文档继续操作，创建一个从属服务器。
当您想要将数据库服务器复制到磁盘时，只需停止从属服务器，备份它，然后重新启动它 - 主服务器上的世界会继续运转，从属服务器将在重新启动时补上它错过的内容。
您还可以使用基本备份加上通常发送给从服务器的滚动事务日志作为可靠数据库备份。这似乎是您在问题中试图实现的最接近的事情，但我建议改为使用我描述的从服务器备份 -- 好处更多（您有一个热备用服务器）并且主服务器的工作量更少（无需额外的检查点来滚动备份的事务日志）。
其他
如果以上都不吸引你，那么你只能使用SQL 转储。
缺点是：Postgres 必须在转储时锁定每个表（这意味着对数据库的写入将被阻止），并且 SQL 转储比其他选项慢。
如果您的数据库有实际大小，我不建议使用此方法。