mysql数据库的备份和灾难管理计划

发布于 2024-07-10 16:44:22 字数 93 浏览 8 评论 0原文

我有一个多用户应用程序,其中包含用户的一些关键数据。 我正在制定该应用程序的备份和灾难恢复计划。

想了解一些与此相关的最佳实践。

谢谢。

I've got a multi-user application having some critical data of the users. I am working on the backup and disaster recovery plan for the application..

Would like to know some best practices regarding this..

Thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

温柔戏命师 2024-07-17 16:44:22

注意:您可能希望在关键数据管理中包含故障转移。

备份通常用于复制准备恢复的数据。

故障转移和 DRP 恢复服务(不是只是数据),因为新服务器可用:

  • 在几分钟内进行故障转移,因为它通常位于同一网络上,并且在 DRP 的情况下,其名称不必
  • 在几个小时内

发布在各个 DNS 上对于纯备份策略,我采用每日增量备份和每周完整备份。

但是,我们还有一个 SRDF 连接,允许与我们的远程数据中心进行实时数据复制用于 DRP。

现在,备份 + 故障转移 + SRDF(用于 DRP)对于开发数据可能有些过大,但对于生产数据(需要恢复在生产中运行的服务)来说是合理的。

因此,为了更好地完善您的政策,您需要清楚地分析您的数据代表什么。

Note: you may want to include failover in your critical data management.

Backup is often used for copy of your data ready to be restored.

Failover and DRP restore the service (not just the data), since a new server is available:

  • within few minutes for failover, since it is generally on the same nettwork, and its name does not have to be published on the various DNS
  • within a few hours in case of DRP

For pure backup strategy, I go with daily incremental backup, and weekly full backup.

However, we also have a SRDF connection allowing a real-time data replication with our remote data center used for DRP.

Now, backup + failover + SRDF (for DRP) might be overkill for development data, but can be justified for production data (needed to restore the service running in production).

So to better refine your policies, you need to clearly analyze what your data represent.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文