我们不介意我们的备份过程是否花费更长的时间；就目前而言，我们需要在WAN上移动30gig压缩备份，这需要10多个小时。
我们有2种选择来获取较小的每日备份。
日志传送，这意味着我们必须重组DR流程。
将信息从数据库中提取出来并在另一侧进行重建（删除非聚集索引，将聚集索引打包为100％-在另一侧进行重建）
两者都将涉及大量我们的工作。我们正在使用SQL Server 2008 pro，所有备份均已压缩。
是否有任何商用产品可以为我们提供与选项（2）相似的备份大小？
是否有一个完善的脚本可以让我们完成（2）？ （处理索引视图，过滤的索引，外键等）
#1 楼
首先基于注释的想法...每6个小时使用差异备份，以减少备份+ FTP的大小/时间。然后将完整备份+ FTP减少到仅周末。这避免了日志传送的复杂性，操作简单，并且仅对DR增加了一点复杂性。
我觉得差异备份被忽略了。我建议以前使用它们：
如何在SQL Server 2008 R2 Express Edition中备份小型数据库
使用DIFF备份解决此问题
我想要从恢复的角度来看，使一切都尽可能简单，同时在发生故障的情况下最大程度地减少数据丢失量
SQL Server备份策略的优缺点及其适当的使用方案
迁移大型数据库
使用DIFF备份加快备份/还原服务器的迁移速度
编辑：在jcolebrand发表评论后，我将尝试解释更多信息
差异备份仅包含已更改的页面。除了进行任何索引维护（这可能影响很多数据库）之外，一天中只有几％的页面会更改。因此，差异备份比进行任何压缩之前的完整备份要小得多。
如果您具有完整备份（例如每周一次），则可以进行每日差异并将其运离现场。每天使用差异进行的完整备份仍然需要将两个文件都保存在异地。
这应该可以解决将数据从A快速获取到B，C和D的问题。
需要还原完整差异和最新差异以获取最新数据，但是您可以使用NORECOVERY和STANDBY文件来解决此问题（自从我上一次从事纯DBA工作以来，多年来我都没有尝试使用差异还原） 。
另外一个好处是，差异备份与正在进行的日志备份无关，因此您可以将任何高可用性/灾难恢复要求与“将数据获取到代码猴子”要求分开。
如果您通过策略或审核每天进行完整备份，我会看到一些问题，但是差异还原可以在任何日志还原之前应用，以缩短恢复时间。与备份不同，差异还原和日志还原可以交互。
希望我涵盖了大多数基础知识...
评论
Hyperbac是一种非常智能的压缩工具，因为它可以在操作系统级别处理文件，因此它可以压缩备份并保留所有维护计划和作业不变。如果他们不想更改任何东西，而只是在盒子中添加一个新工具，那么他们肯定应该尝试一下。我知道我曾经用过它，并且在SQL 2005中很喜欢它。但是对于更多的压缩，他们仍然应该做一些体力劳动...
–玛丽安
2011年6月7日20:52
@Marian我很确定Brent O只是需要的顾问。
–jcolebrand♦
2011年6月7日在21:15
@Marian：压缩是有限制的，更多的压缩=更多的CPU /时间。最小的备份将是输入最少的备份=差异，而不管压缩工具/格式如何。关于时间/比率的链接一：您可以进行极端压缩，但是它需要更长的时间，而对于30 GB的压缩文件，它可能比FTP花费的时间更长...
– gbn
2011年6月8日下午4:46
我同意您的看法，事实是商用工具的压缩率比MS的压缩率高，并且它们是可配置的（通过不分配给操作的CPU），它们提供了加密和其他功能。我不一定赞美它们（它们并不便宜），我只是说它们中的一些可以与SQL Server的当前备份（完整，差异，日志）结合使用，而无需更改环境，这些家伙似乎需要/想要。 @jcolebrand：知道了，谢谢！
–玛丽安
2011年6月8日下午6:56
#2 楼
有一些商业产品可以比本地2008年压缩更好地帮助您压缩备份。例如RedGate备份，Hyperbac，Idera SQL备份，Litespeed备份。它们伴随着高CPU和文件类型的额外成本，而MS附带的工具则需要使用这些工具来处理。 Hyperbac（现在由Redgate收购）压缩除外，它可以透明地处理文件并允许创建zip兼容文件（并且不需要任何第三方工具）。
但是有没有工具可以为您提供通过手动清理将获得的文件大小。
请仔细阅读Brent Ozar的文章：如何真正压缩SQL Server备份，他将建议您执行与步骤相同的步骤点号2.
评论
RedGate FTW !!!!
– Hogan
2011年6月7日15:42
@霍根：如果你不能击败他们，那就买它们。这是一个很好的例子:-)。无论如何，现在属于Redgate并处理数据库压缩的两种产品都可以成功共存。
–玛丽安
2011年6月7日18:13
#3 楼
问题1：是否有商用备份产品能够提供与备份之类的备份大小类似的备份大小，例如从数据库中剥离诸如索引之类的非必需数据？否。有很多备份压缩产品（Quest LiteSpeed，Red Gate SQL备份，Idera SQLSafe，Hyperbac等），但是所有这些压缩产品只能通过压缩SQL Server常规备份过程的输出来发挥作用。其中一些以棘手的方式完成操作-HyperBac和LiteSpeed的Engine选项是文件系统过滤器驱动程序，这意味着它们在截取磁盘的过程中正在拦截输出-但所有这些产品的最终结果只是压缩的备份输出。 />
问题2.是否有完善的脚本可以转储所有这些额外的数据？
随着时间的流逝，您在数据库中保留了更多历史记录（4、5、8、10年），您将不想提取所有索引数据并在WAN的另一端重建它。相反，您只想传输修改后的数据，这就是日志传送的地方。
您不应该这样做。
但是，如果您真的想要这（不，我不会帮您），您可以使用文件组备份来做到这一点。像这样设置您的数据库文件组：
主文件组（必需，但留空）
ClusteredIndex文件组（在此处放置聚簇索引）
ExtraneousCrap文件组（将其他所有内容都放在这里）
开始仅执行前两个的压缩文件组备份，然后将较小的文件复制到灾难恢复服务器。您可以使用SQL Server 2008的文件组备份和还原功能来还原主要和ClusteredIndex文件组，然后它们将立即可用于查询。在您在线获取ExtraneousCrap文件组之前，它们实际上是不可行的，但是这也有一个讨厌的窍门-在MVP Deep Dives书中，有一章介绍了编辑系统表以使ExtraneousCrap文件组以及所有相关索引的消失。此技巧很危险，完全不受支持，真是个坏主意-嘿，您要的。
#4 楼
我建议切换到日志传送之类的方式。基本上，如果您可以选择在24小时内发送30 Gig，而不是在较短的时间范围内在一天结束时发送，则网络速度对您来说就不那么重要了。
慢速网络上的开发人员还可以通过FTP或任何适当的过程下载大小更方便的文件。他们还可以设置一整天下载的作业。
除了sql server压缩，您还可以实现一个第三方工具，例如litespeed或redgate sqlbackup，其压缩率更高。
此外，您可以在网络端安装网络设备，以优化您到灾难恢复站点的吞吐量。过去，我成功地使用Riverbed Appliance在不到3小时的时间内成功地将90GB的数据从FL备份到VA。
另一种选择是备份特定文件组，但不包括索引等，但是仍然停留在聚集索引上，并且根据您的数据库结构，您可能会从使用该方法中受益，而获得更多的成本/麻烦。
感谢
#5 楼
如果您有足够的钱，并且您的体系结构允许这样做，请使用Riverbed技术（http://www.riverbed.com/us/）。最好将这样的设备与复制或日志传送方案结合使用。如果没有，那么要问几个问题。如果您仅需要每隔几个月刷新一次，为什么还要担心带宽？您唯一需要担心的转移是一次，在那里获得完整备份以在本地进行还原，还是我误认为是您的设置？
另一种可能性是担心将所有数据都提供给他们，设置Citrix环境并将其远程访问您。使用Citrix，您在客户端/主机之间的带宽需求最低，并且能够在本地执行所需的操作，而不必担心必须将这些更改复制到其他位置。只是我的$ 0.02
评论
你能再解释一下吗？我知道这是适合StackExchange团队的，所以我确定他们会喜欢更深入的演练;）
–jcolebrand♦
2011年6月7日14:22
哈哈，这里有很多要考虑的问题。您到底想让我解释什么？
– SQLChicken
11年6月28日在12:54
复制/日志传送是我的初衷，但这就像两个星期前一样，因此我怀疑它现在是否同样重要。另外，我只是重新阅读并看了有关Citrix的部分，然后（现在）我可以告诉您他们不这样做。他们只是使用DVCS基础设施进行本地开发，只希望数据用于测试/播放/确认。也可能用于数据转储。
–jcolebrand♦
2011-6-28 at 16:05
知道了然后，正如其他人已经说过的那样，Redgate和Quest这样的第三方供应商拥有非常好的备份压缩工具，可以帮助您满足他们的需求。另一个潜在的解决方案是SQL Azure。目前，数据库大小限制为50GB，但他们提高了加载任何数据的费用，因此这可能是一种经济高效的解决方案。
– SQLChicken
2011年6月28日20:31
#6 楼
我将使用SQL事务复制。您的初始负载会花费一些时间，但是一旦启动并运行，您就只能发送所需的信息。例如，如果您只有3或4个要更新的表，则只能发送这3或4个表。还可以选择要发送的内容。 FK，集群/非集群索引，表分区方案，存储的proc和TONS等。
http://www.sql-server-performance.com/2010/transactional-replication-2008-r2/
如果这不是一个选择，则可以使用REDGATE SQL备份-http://www.red-gate.com/products/dba/sql-backup/。我以前使用过它，压缩率高达90％。比SQL小得多。
评论
请问您当前的备份粒度和频率是多少（常规日志备份？每天完整吗？）您使用企业版还是标准版？更新：您是租用站点中的小公司DR还是具有永久DR站点的大公司？如果是第一个，那么您是否有在站点外运行的文件服务器或SQL Server@gbn，我们需要优化每日填充量，我们使用企业级设备，DR都是本地的，人们把这些东西带到异地。小备份是开发人员和我们第二个异地需要的。注意...开发人员不在现场，在带宽有限的其他国家/地区，我们需要从NY服务器到（例如）澳大利亚的服务器的最小传输大小。我们每几个月同步一次。
对于没有意识到这一点的任何人，这都是针对SO团队的；）
@Sam Saffron：请问您是否采纳了我的建议？
@gbn ...仍在决定该怎么做，我认为“常规”-使用您建议的解决方案将材料返回俄勒冈州工作是可行的。但是，“ Sam每月需要下载一次SO db问题仍然非常非常痛苦，因为我需要将22gigs迁移到澳大利亚-现实情况是，“真实”信息很容易就可以容纳10个演出。”