最小的备份可能......使用 SQL Server

Question

我们每天通过 WAN 运送我们的 SQL Server 备份。我们需要最小化这些备份的大小，这样它就不会花很长时间。

我们不介意我们的备份过程是否需要更长的时间；目前，我们需要在 WAN 上移动 30gigs 的压缩备份，这需要 10 多个小时。

我们有两种选择来获得较小的每日备份。

1. 日志传送，这意味着我们必须重构 DR 流程。
2. 从数据库中剥离信息并在另一侧重建（删除非聚集索引，100% 打包聚集索引 - 在另一侧重建）

两者都涉及我们的大量工作。我们使用的是 SQL Server 2008 pro，所有备份都是压缩的。

是否有任何商业产品可以为我们提供与选项 (2) 类似的备份大小？

是否有一个全面的脚本可以让我们完成（2）？（处理索引视图、过滤索引、外键等）

Answer 1

根据评论的第一个想法......

每 6 小时使用一次差异备份，以减少备份 + FTP 的大小/时间。然后将完整备份 + FTP 减少到周末。这避免了日志传送的复杂性，操作简单，并且只为 DR 增加了轻微的复杂性

我觉得差异备份被忽略了......我之前建议使用它们：

• SQL Server 2008 R2 Express Edition中如何备份小型数据库
  使用DIFF备份解决这个问题

  我想从恢复的角度让一切尽可能简单，同时最大限度地减少发生故障时丢失的数据量

• SQL Server 备份策略的优缺点及其适当的使用场景
• 迁移大型数据库
  使用 DIFF 备份加快备份/恢复服务器迁移

编辑：在 jcolebrand 发表评论后，我将尝试解释更多

差异备份仅使用已更改的页面。除了任何索引维护（这会影响很多数据库），一天中只有百分之几的页面会发生变化。因此，在任何压缩之前，差异备份比完整备份小得多。

如果你有一个完整的备份，比如说每周一次，那么你可以做每日差异并将它们运送到现场。带有差异的每日完整备份仍然需要异地两个文件。

这应该可以解决从 A 到 B、C 和 D 快速获取数据的问题。

您可能需要同时恢复完整和最新差异以获取最新数据，但您可以使用 NORECOVERY 和 STANDBY 文件解决此问题（自从我上次担任纯 DBA 以来，我多年来一直没有尝试过差异恢复工作）。

一个额外的好处是差异备份与正在进行的日志备份无关，因此您可以将任何高可用性/DR 要求与“将数据发送给代码猴子”要求分开。

如果您按策略或审计进行每日完整备份，我会看到一些问题，但可以在任何日志还原之前应用差异还原以缩短恢复时间。与备份不同，差异和日志还原会交互。

希望我已经涵盖了大多数基础......

Answer 2

有一些商业产品可以帮助您比原生 2008 压缩更好地压缩备份。例如RedGate Backup、Hyperbac、Idera SQL Backup、Litespeed Backup。

它们带来了高 CPU 和文件类型的额外成本，需要使用 MS 附带的工具之外的工具进行处理。除了Hyperbac（现在被Redgate收购）压缩，它透明地处理文件并允许创建与 zip 兼容的文件（并且也不需要任何第三方工具）。

但是没有任何工具可以为您提供通过手动清理获得的大小的文件。请查看 Brent Ozar 的文章：如何真正压缩 SQL Server 备份，他会建议您执行与第 1 点相同的步骤。2.

Answer 3

问题 1：是否有商业备份产品可以提供类似的备份大小，以从数据库中剥离非必要数据（如索引）？

没有。有很多备份压缩产品（Quest LiteSpeed、Red Gate SQL Backup、Idera SQLSafe、Hyperbac 等），但所有这些产品都只是通过压缩 SQL Server 常规备份过程的输出来运行。他们中的一些人以棘手的方式做到这一点——HyperBac 和 LiteSpeed 的引擎选项是文件系统过滤器驱动程序，这意味着它们在发送到磁盘的途中拦截输出——但所有这些产品的最终结果只是压缩的备份输出。

问题 2. 是否有一个全面的脚本来转储所有这些额外的数据？

随着时间的推移，当您在数据库中保留更多历史记录（4、5、8、10 年）时，您将不想撕掉所有索引数据并在 WAN 的另一端重建它。相反，您只想传输修改后的数据，这就是日志传送的用武之地。

你不应该这样做。

但是，如果您真的非常想这样做（不，我不会帮助您），您可以使用文件组备份来完成。像这样设置你的数据库文件组：

• 主文件组（必需，但留空）
• ClusteredIndex 文件组（将您的聚集索引放在这里）
• ExtraneousCrap 文件组（把其他的都放在这里）

开始只对前两个文件组进行压缩备份，然后将那些较小的文件组复制到您的 DR 服务器。您可以使用 SQL Server 2008 的文件组备份和恢复功能来恢复主文件组和 ClusteredIndex 文件组，然后它们将立即可供查询。在您将 ExtraneousCrap 文件组联机之前，它们不会真正可行，但是也有一个令人讨厌的技巧 - 在MVP Deep Dives 书中，有一章关于编辑系统表以创建 ExtraneousCrap 文件组和所有的关联索引消失。这个把戏很危险，完全没有支持，而且是个坏主意 - 但是嘿，你要求它。

Answer 4

我建议切换到日志传送之类的东西。基本上，如果您可以选择在 24 小时内发送 30 Gig 与在更短的时间窗口内在一天结束时发送，那么网络速度对您来说就不是问题。

您在慢速网络上的开发人员也将能够通过 FTP 或您拥有的任何进程下载更方便大小的文件。他们还可以设置全天下载的作业。

除了 sql server 压缩之外，您还可以实现一个 3rd 方工具，例如 litespeed 或 redgate sqlbackup 等具有更高压缩率的工具。

此外，在网络方面，您可以安装网络设备，以优化 DR 站点的吞吐量。过去，我成功地使用 Riverbed Appliance 在不到 3 小时的时间内成功地从 FL 到 VA 获得了 90GB 的备份。

另一种选择是备份特定的文件组，不包括索引等，但您仍然坚持使用聚集索引，并且根据您的数据库结构，您可能会获得更多的成本/麻烦，而不是从该方法中获益。

谢谢

Answer 5

如果您有钱，并且您的架构允许这样做，请查看 Riverbed 技术 (http://www.riverbed.com/us/) 之类的东西。将这样的设备与复制或日志传送方案结合使用可能是您最好的选择。

如果没有，那么几个问题。如果您只需每隔几个月刷新一次，为什么还要担心带宽？您唯一需要担心传输的是一次，在那里获取完整备份以在本地进行还原，或者我是否误认为您的设置是这样？

另一种可能性是不必担心将所有数据提供给他们，而是设置一个 Citrix 环境并让他们远程访问您。使用 Citrix，您可以将客户端/主机之间的带宽要求降至最低，并且您能够在本地执行所需的操作，而不必担心必须在其他地方复制这些更改。只是我的 0.02 美元