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

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

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

（2）包含活动PostgreSQL数据目录的卷也将得到备份（每天一次）。在制作该卷的快照之前，我发出pg_dump并将生成的SQL文件保存在数据目录中。采取预防措施以确保实际数据库数据一致是否有意义？假设实时快照可以正确地（a）备份配置文件（postgresql.conf，pg_hba.conf，pg_ident.conf）和（b）备份SQL转储文件是否正确？备份这两个东西，即sql dump文件和config文件，将是对该卷进行快照的重点。数据库不是很大，因此我不介意数据文件将使此快照膨胀。在那种情况下，我可以做一个实时快照-对吗？

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

（3）至于上面带有代码的卷，是否还有一点要同步和冻结文件系统？还是只能拍摄实时快照？此数据应相当“静态”。

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

谢谢

请参阅精美的手册。如果我的建议与其“任何方式”相抵触，那是对的。

1. 同步并不是一个坏主意，除非您的复制工具fsync（）在复制下一个WAL文件之前先写入每个WAL文件及其所在的目录。上一个WAL文件不完整并不重要。最糟糕的是，您只需删除它。Pg通常会因不完整的WAL而阻塞-尽管没有校验和完成，所以您可以真的很倒霉，并尝试应用垃圾数据，而偶然的偶然机会恰好看起来像真实的WAL记录。在您的位置，我将在快照之前同步卷，以确保RAM中任何未写入的脏缓冲区都撞击磁盘上的文件系统映像。冻结将有助于避免出现混乱但并非致命的部分书面WAL，因此这不是一个可怕的想法，但也不是至关重要的。最重要的是要有一个完整的时间表，直到恢复点。就我个人而言，我将WAL写入一个临时文件名，并仅在完全复制后才将其重命名为其最终名称。如果这样做，则无需冻结。

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

3. 为什么还要快照您的代码量？纯文件级副本可能很好。当然，应该有一个实时快照。

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

   就个人而言，我建议您使用WAL运送或将数据库转储发送到另一台主机，最好是不在 Amazon EC2上或至少在其他地区的一台主机。该主机应执行自动还原测试，将结果报告发送给您，并且还应手动检查。

   尽管您的快照（包含转储）将位于S3上，并且在那里将是安全的，但这并不意味着当您急需它们时便可以访问它们。亚马逊的耐用性声明令人放心，但是在S3服务严重超时的情况下，您的数据仍然可以安全和完全无法访问。