小编Pet*_*rey的帖子

我们有一个 SQL Server 2008 数据库服务器（它恰好在 MS 故障转移群集下运行，但我认为这与此处无关）。

我们的应用程序运行 Hibernate 以进行数据库访问，自从我们最近从 v3.1 升级到 3.6 以来，我们经常遇到 SQL Server 崩溃（每 24-48 小时，但有时更频繁）。

有问题的具体问题似乎与内存有关。就在服务器崩溃之前（然后似乎由故障转移集群管理器自动重新启动），我们收到了这些错误的负载：

Error: 701, Severity: 17, State: 130.
There is insufficient system memory in resource pool 'internal' to run this query.

也偶尔（但定期）的消息

Error: 17300, Severity: 16, State: 1. (Params:). The error is printed in terse mode because there was error during formatting. Tracing, ETW, notifications etc are skipped.

错误：17312，严重性：16，状态：1。（参数：）。错误以简洁模式打印，因为格式化过程中出现错误。跟踪、ETW、通知等被跳过。

我还收到一些应用程序级别的错误，例如

java.sql.SQLException: A time out occurred while waiting to optimize the query. Rerun …

我们在 RDS 上运行 Postgres，这非常棒。然而，它的一个大问题是与 AWS 的安全模型有关，该模型允许具有各种权限的任何人删除所有内容——您的数据库、您的备份，以及所有内容。

特别是，您无法阻止有权创建 IAM 用户和组的人向新用户授予比他们自己更多的权限，因此如果您依赖 RDS ，无论是凭证泄露还是心怀不满的员工都可能毁掉一切自己的备份。

编辑：

以防万一您想知道可能是什么问题，请快速阅读http://www.infoworld.com/article/2608076/data-center/murder-in-the-amazon-cloud.html

因此，“明智”的做法似乎是拥有一个单独的 AWS 帐户，您基本上没有任何人可以访问该帐户，并且拥有一个可以将内容写入到 S3 的密钥（如果您愿意，可以读回它，虽然这可能是可选的）。

通过这种方式，您可以将内容备份到您的主要 AWS 管理员无法意外或设计删除内容的帐户，然后使用生命周期规则对其进行管理。

很抱歉长时间的积累 - 我真的很惊讶人们之前似乎没有问过/回答过这个问题，因为对于几乎任何使用 RDS（或实际上只是 AWS）的人来说，这似乎是一件显而易见的事情，但是。 ..

为此，我如何以明智的方式备份 Postgres？

需要考虑的一些事项：

• 存储空间等不是无限的，所以理想情况下不要做一个完整的 pg_dump/gzip/encrypt/upload 到 S3，这是显而易见的解决方案，因为这意味着每天有数百 Gb 到达那里可能是矫枉过正。
• 我们无权访问“核心”服务器，因此不能像更“正常”那样进行差异类型备份

做一个pg_dump，然后使用某种差异程序来只上传/存储差异是否可行？由于我认为 pg_dump 不会按特定顺序生成事物，因此我不确定这会起作用（以预期的方式）？

还有其他想法吗？

我通过使用手动快照共享的方式知道 - https://aws.amazon.com/blogs/aws/amazon-rds-update-cross-account-snapshot-sharing/ -如果你这样做很好重新使用未加密的 RDS - 但我们不是，原因我无法完全解释，除了“听起来不错”。