我在亚马逊云中运行数据库服务器，数据库文件位于单独的 EBS 卷上。在备份/恢复操作方面，我发现执行文件系统级备份比执行 SQL 转储要简单得多，因为我可以几乎立即创建备份并从中恢复。
如果我坚持仅使用文件系统级备份，可能会忽略哪些问题？
在 Ubuntu 12.04 上运行 PostgreSQL 9.1（今年晚些时候将升级到 9.3）
答案1
如果我坚持仅使用文件系统级备份，可能会忽略哪些问题？
是的 - 但不是你想的那样。只要你执行文件系统级别的版权保护，那就安全了，依赖物理备份才是风险所在。
在撰写本文时，我注意到有关文件系统级备份的章节需要更新，以便向用户指出pg_basebackup和pg_start_backup()。虽然从技术上讲，这些工具是流式复制和 PITR 的一部分，但它们只是制作安全、一致的文件系统级副本的方法，应该在文档的该部分中引用。
安全地进行
每PostgreSQL 文件系统级备份的文档和制作基础备份只要遵循给出的规则，进行文件系统级复制是相当安全的，即执行以下操作之一：
在备份之前停止服务器并保持关闭状态直到备份完成；
使用
pg_basebackup;使用
pg_start_backup()和pg_stop_backup()并复制生成的文件pg_stop_backup(); 或者使用原子文件系统快照并从快照中复制，在这种情况下，由于它是快照，因此无法写入任何内容。
您也可以使用，这是我的偏好。它使用复制协议执行文件系统级复制，为您pg_basebackup -X stream处理等事宜。pg_start_backup()
物理备份的主要优势在于可以作为时间点恢复。
快照情况是安全的，因为它就像崩溃一样。没有写入操作，并且数据库状态是在特定时刻捕获的。预写日志包含所有已提交的事务数据，因此在数据库首次启动时，任何尚未刷新到堆的内容都会在恢复期间从 WAL 重放。这就像崩溃后启动一样。pg_start_backup()如果您正在复制一个在复制时仍在写入的实时数据库目录，则只需要和朋友；快照可以避免这种情况。
注意只有当快照确实是原子的时候，依赖快照才是安全的，即它捕获某一时刻的文件系统状态。而且，只有当只涉及一个卷/文件系统时，它才是安全的 - 您不能使用两个不同文件系统的两个快照进行备份，因为它们不是来自同一时刻。如果您使用表空间，快照备份因此不安全 - 但pg_basebackuprsyncpg_start_backup()仍然pg_stop_backup()是安全的。
这意味着，如果您的数据库文件系统是（比如说）mdRAID 阵列中的四个 EBS 卷，或者您有一个用于数据库，pg_xlog另一个用于数据库的其余部分，则您无法使用 EBS 快照进行一致备份。如果所有内容都在一个 EBS 卷中，则 EBS 快照是安全的。
您还可以在运行备份之前停止 PostgreSQL，然后在运行备份之后启动它。如果您是幸运儿之一，可以承受备份停机时间窗口，那么这很酷。无论如何，我个人更喜欢热备份。
风险
真正需要担心的问题是，当您进行物理备份时，您是在未经检查和验证的情况下复制数据库结构。如果存在未检测到的损坏，您的备份可能比您想象的要没那么有用。我个人也会使用逻辑转储。
一个有用的折衷方案是，在完成复制后启动文件系统级备份，然后pg_dump从文件系统级备份执行备份。这可确保其可读，并为您提供逻辑副本。如果您的逻辑转储失败，您的自动化系统应该会向您发送电子邮件并寻求帮助，因为这表明您的物理副本也可能已损坏。
顺便说一句，不久前我在我的旧博客上写了很多关于避免数据丢失/损坏问题的文章 - 请参阅避免 PostgreSQL 数据库损坏。
答案2
如果您完全关闭 Postgres，然后在 Postgres 关闭时进行备份，则可以进行可靠的文件系统备份。备份完成后，启动 Postgres。
如果 Postgres 在备份期间正在运行，则所有结果都将无效。
除了适当的“Postgres 内部”数据库备份之外，最好还执行上述操作。