EC2 - 如何正确备份 PostgreSQL 数据？

Question

设置如下：1 个小型 Amazon Linux（EBS 支持）EC2 实例和 3 个额外的卷。这既是 Web 服务器又是数据库服务器。一卷用于代码，一卷用于 PostgreSQL (8.4) 数据目录，一卷用于存储来自 PostgreSQL 的 WAL 文件。

(1) 带有 WAL 文件的卷也将有数据目录的基本备份，它在执行 pg_start_backup() 后被复制。然后它将存储来自 PostgreSQL（WAL 文件）的连续存档输出。要对该卷进行快照，发出同步并冻结文件系统是否有任何意义（如果是 XFS，则使用 xfs_freeze，如果是 EXT4，则使用 dmsetup）？或者我可以拍摄实时快照吗？WAL 文件将以每分钟一个的速度发送。是否有可能在复制单个 WAL 文件并导致数据损坏时启动快照？

(2) 包含实时 PostgreSQL 数据目录的卷也将被备份以进行良好的测量（每天）。在做这个卷的快照之前，我发出一个 pg_dump 并将生成的 SQL 文件保存在数据目录中。采取预防措施以确保实际数据库数据的一致性有什么意义吗？假设拍摄实时快照将正确 (a) 备份配置文件（postgresql.conf、pg_hba.conf、pg_ident.conf）和 (b) 备份 SQL 转储文件是否正确。备份这两件事，sql 转储文件和配置文件，将是对该卷进行快照的主要内容。数据库不是很大，所以我不介意数据文件会使这个快照膨胀。在这种情况下，我可以做一个实时快照——对吗？

(2a) 将数据目录保留在根卷上，并有一个备份脚本将 sql 转储文件和配置文件复制到另一个卷上，并在复制完成后对该卷进行快照会更好吗？

(3) 至于上面有代码的卷，还有同步和冻结文件系统的意义吗？或者可以只拍摄实时快照？这些数据应该是相当“静态的”。

(4) 这是一个可靠的备份方案吗？根卷不会定期备份，因为我只会在设置和配置后保留机器映像。

谢谢

Answer 1

参见精美手册。如果我的建议与它有任何冲突，那是对的。

1. 同步并不是一个坏主意，除非您的复制工具 fsync() 在复制下一个 WAL 文件之前对其写入的每个 WAL 文件及其所在的目录进行了复制。不完整的最后一个 WAL 文件无关紧要；最坏的情况是，您只需删除它。Pg 通常会在不完整的 WAL 上窒息 - 尽管没有完成校验和，所以你可以真的很不走运，让它尝试应用垃圾数据，这些垃圾数据碰巧看起来像真正的 WAL 记录。在您的位置，我会在快照之前同步卷，以确保 RAM 中任何未写入的脏缓冲区命中磁盘上的文件系统映像。冻结将有助于避免混乱但非致命的部分编写的 WAL，因此这不是一个糟糕的主意，但并不重要。至关重要的是在恢复之前有一个完整的时间表。就我个人而言，我将我的 WAL 写入一个临时文件名，并在完全复制后将它们重命名为最终名称；如果你这样做，你就不需要冻结。

2. 听起来是对的。实时快照就像在具有直写缓存的实时系统上进行插拔测试。从实时快照恢复时，您的数据库应该可以正常恢复，与插入后相同。我建议您自动测试从快照还原。（注意：快照恢复测试并不能完全替代插拔测试，因为它不考虑可能的磁盘、RAID 控制器等写入缓存）。不仅配置文件和转储，而且数据库本身在你的快照之后应该没问题。考虑在快照之前同步卷，以确保所有转储数据等都实际命中磁盘。
   
   2a. 可能会节省一些磁盘空间。否则差别不大。您将可以将快照保留更长时间，而不会受到实时数据库的所有搅动。

3. 为什么还要对代码量进行快照？一个普通的文件级副本可能就好了。当然应该是实时快照。

4. 这不是一个可靠的备份方案。它在一个关键领域失败：没有执行恢复测试和验证。您应该始终定期测试您的备份，以确保您真的可以恢复它们。

   就个人而言，我建议您使用 WAL 传送或将数据库转储发送到不同的主机，最好是不在Amazon EC2 上或至少在不同区域的主机。该主机应该执行自动恢复测试，向您发送结果报告，并且还应该进行手动检查。

   虽然您的快照（包含转储）将在 S3 上，并且在那里是安全的，但这并不意味着在您迫切需要它们时可以访问它们。Amazon 的持久性声明令人放心，但在 S3 服务严重定时中断期间，您的数据仍然是安全的并且完全无法访问。