Gor*_*oro 2 postgresql amazon-ebs amazon-web-services database-backup
我在亚马逊云中运行我的数据库服务器，并且我在单独的 EBS 卷上有数据库文件。在备份/恢复操作方面，我发现只进行文件系统级别的备份而不是 sql 转储要简单得多，因为我几乎可以立即创建备份并从中恢复。
如果我坚持只使用文件系统级备份，是否有任何我可能会忽略的问题？
在 Ubuntu 12.04 上运行 PostgreSQL 9.1（今年晚些时候更新到 9.3）
如果我坚持只使用文件系统级备份，是否有任何我可能会忽略的问题？
是的 - 但不是你想的那些。只要您执行安全的文件系统级复制权限，风险就在于对物理备份的依赖。
在写这篇文章时，我注意到文件系统级备份一章需要更新以将用户指向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_basebackup还是pg_start_backup()，rsync的，pg_stop_backup()仍然是安全的。
这意味着，如果您的数据库文件系统是（比如说）mdraid 阵列中的四个 EBS 卷，或者您有一个用于pg_xlog数据库的其余部分，另一个用于数据库的其余部分，则无法使用 EBS 快照进行一致备份。如果一切都是一个 EBS 卷，那么 EBS 快照是安全的。
您还可以在运行备份之前停止 PostgreSQL，然后再启动它。如果您是能够负担得起备份停机时间窗口的幸运者之一，那太好了。反正我个人更喜欢热备份。
真正需要关注的问题是，当您进行物理备份时，您正在复制未经检查和未经验证的数据库结构。如果存在未检测到的损坏，您的备份很可能没有您想象的那么有用。我个人也会使用逻辑转储。
一个有用的折衷办法是在完成副本后启动文件系统级备份，然后pg_dump从文件系统级备份开始。这确保了它的可读性，并为您提供了一个逻辑副本。如果您的逻辑转储失败，您的自动化应该给您发送电子邮件并寻求帮助，因为它表明您的物理副本也可能已损坏。
顺便说一句，我不久前在我的旧博客上写了一堆关于避免数据丢失/损坏问题的文章 - 请参阅避免 PostgreSQL 数据库损坏。