0

在阅读了 Pinal Dave 关于恢复数据库的有用文章后，我计划使用以下设置...

  1. 我的 400mb 数据库位于 D:\databases\
  2. 恢复模式已满
  3. 在 C:\dbbackups 中创建备份设备
  4. 每天将在数据库上运行完整备份到 C 上的备份文件：
  5. 每 4 小时将在数据库上运行一次事务日志备份到 C 上的备份文件：
  6. 服务器主机每 24 小时对 C: 和 D: 进行一次差异文件备份，我希望它会完整地复制 SQL 数据库和备份设备文件
  7. 服务器主机每 24 小时对数据库文件进行一次 SQL 备份
  8. 每周我都会将备份设备文件下载到我们的异地办公室

我知道我可能会改进这一点（欢迎指点！）但成本始终是因素，所以我试图尽可能地限制风险。除了以上几点...

  • 考虑到上面的步骤 1-5，这是否意味着备份文件将随着新备份的执行而不断增长和增长？
  • 我是否认为我只需要一个完整备份加上以下日志备份才能恢复到最近的 4 小时备份？
  • 如果是这样，是否可以在三周的保留期内覆盖备份？如果没有，其他 DBA 如何限制这些文件大小？

拼命地试图避免成为下一个灾难故事...... :-)

4

1 回答 1

1

如果您不确定备份脚本中使用的选项，您可能想要研究的一种工具是Ola Hallengren 的维护脚本。即使它是一套工具，如果您愿意，您也可以只查看（和使用）备份部分。我推荐它是因为它考虑了您对空间不足和其他最佳实践的许多担忧。

对于第 3 点到第 5 点，我要说明一点，如果可能，请不要直接备份到 C: 驱动器。请记住：它托管 Windows。如果空间不足，您的服务器将崩溃。如果您唯一的驱动器选项是 C: 和 D:，则备份到 D: 驱动器。更好的解决方案是添加另一个磁盘。出于同样的原因，我们也不希望将数据库文件托管在 C: 驱动器上。

您可能要考虑的另一件事是将备份移动到网络存储（完成后），同时等待将它们移出现场。如果您的服务器崩溃，您仍然可以从网络存储访问它们，并且您可能不需要从异地调用一周前的备份。我确实建议继续在异地发送副本。

至于备份的轮换方案，它应该基于您与您支持的用户设置的任何 SLA（服务级别协议），并由您可用的资源来平衡。没有任何“正确”的答案需要找到适合您的情况并且您和您的用户都感到满意的答案。也就是说，在将它们添加到您的长期轮换之前，请务必恢复您的备份并对其进行测试。

至于您关于完整/日志备份的问题，这是正确的。每个日志备份都以完整备份为基础。所以在 F1 --> L1 --> L2 --> L3 --> L4 --> F2 --> L5 --> L6 --> L7 --> L8 的情况下...如果你愿意要恢复到 L3，您需要按顺序备份 F1、L1、L2 和 L3。如果您想恢复到您的第二个完整备份，您只需要 F2。

最后，如果您需要更多帮助，绝对可以使用 Google for SQL Server 备份。博主提供了大量的资源。当然，还有这个站点和dba.stackexchange.com可以解决特定于 DBA 的问题。

于 2013-02-27T13:17:04.007 回答