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

37

每天，我们都会通过WAN运送SQL Server备份。我们需要最小化这些备份的大小，以免花费很长时间。

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

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

日志传送，这意味着我们将不得不重组灾难恢复流程。
将信息剥离到db之外并在另一端重建（删除非聚集索引，将聚集索引打包为100％-在另一端重建）

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

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

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

sql-server sql-server-2008 backup

— 山姆藏红花
source

2

请问您当前的备份粒度和频率是多少（常规日志备份？每天完整吗？）您使用企业版还是标准版？更新：您是租用站点中的小公司DR还是具有永久DR站点的大公司？如果是第1个，则您是否有不在现场运行的文件服务器或SQL Server

— gbn

@gbn，我们需要优化每日供餐量，我们使用企业级设备，DR都是本地的，人们把这些东西带到异地。小备份是开发人员和我们第二个异地需要的。注意...开发人员不在现场，在带宽有限的其他国家/地区，我们需要从NY服务器到（例如）澳大利亚的服务器的最小传输大小。我们每几个月同步一次。

— 山姆·萨弗隆

1

对于任何没有意识到这一点的人，这都是针对SO团队的；）

— jcolebrand

1

@Sam Saffron：请问您是否采纳了我的建议？

— gbn

@gbn ...仍在决定该怎么做，我认为“常规”-使用您建议的解决方案将材料返回俄勒冈州工作是可行的。但是，“山姆每月需要下载一次SO db问题仍然非常非常痛苦，因为我需要将22gig迁移到澳大利亚-现实情况是，“真实”信息很容易就可以容纳10个演出。

— 山姆·萨弗隆

22

基于评论的第一个想法...

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

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

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

从恢复的角度来看，我想使一切尽可能简单，同时在发生故障的情况下将丢失的数据量降至最低
SQL Server备份策略的优缺点及其适当的使用方案
迁移大型数据库
使用DIFF备份来加快备份/还原服务器的迁移

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

差异备份仅包含已更改的页面。除了进行任何索引维护（这可能会影响很多数据库）之外，一天中只有几％的页面会更改。因此，差异备份比进行任何压缩之前的完整备份要小得多。

如果您有完整的备份（例如每周一次），则可以每天进行差异备份，然后将其运离现场。带有差异的每日完整备份仍将需要两个文件都在场外。

这应该解决快速将数据从A传送到B，C和D的问题。

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

另外一个好处是，差异备份与正在进行的日志备份无关，因此您可以将任何高可用性/灾难恢复要求与“获取数据到代码猴子”要求分开。

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

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

— gbn
source

Hyperbac是一种非常智能的压缩工具，它可以压缩备份并保留所有维护计划和作业不变，因为它可以在操作系统级别处理文件。如果他们不想更改任何东西，而只是在盒子中添加一个新工具，那么他们肯定应该尝试一下。我知道我曾经用过它并且喜欢它在SQL 2005中使用。但是对于更多的压缩，他们仍然应该做一些体力劳动……

— Marian

@Marian我很确定Brent O只是需要的顾问。

— jcolebrand

@Marian：压缩是有限制的，更多的压缩=更多的CPU /时间。最小的备份将是输入最少的备份=差异，而不管压缩工具/格式如何。关于时间/比率的链接一：您可以进行极端压缩，但是压缩时间更长，对于30 GB压缩文件，它可能比FTP花费的时间更长……

— gbn

我同意您的看法，事实是商用工具的压缩率比MS更好，并且它们是可配置的（通过不分配给操作的CPU），它们提供了加密和其他功能。我不一定赞美它们（它们并不便宜），我只是说它们中的一些可以与SQL Server的当前备份（完整，差异，日志）结合使用，而无需更改环境，这些家伙似乎需要/想要。@jcolebrand：知道了，谢谢！

— 玛丽安

13

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

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

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

— 玛丽安
source

RedGate FTW !!!!

— 霍根

@霍根：如果你不能击败他们，那就买它们。这是一个很好的例子:-)。无论如何，现在属于Redgate并处理数据库压缩的两种产品都可以成功共存。

— 玛丽安

12

问题1：是否有商业备份产品能够提供与备份之类的非备份数据类似的备份大小？

否。那里有许多备份压缩产品（Quest LiteSpeed，Red Gate SQL备份，Idera SQLSafe，Hyperbac等），但是它们全部仅通过压缩SQL Server常规备份过程的输出即可发挥作用。他们中的一些人以棘手的方式做到这一点-HyperBac和LiteSpeed的Engine选项是文件系统过滤器驱动程序，这意味着它们在截取磁盘的过程中正在拦截输出-但所有这些产品的最终结果只是压缩的备份输出。

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

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

你不应该这样做。

但是，如果您确实想要这样做（不，我不会帮助您），则可以使用文件组备份来做到这一点。像这样设置数据库文件组：

主文件组（必需，但保留为空）
ClusteredIndex文件组（将您的聚集索引放在此处）
ExtraneousCrap文件组（将其他所有内容都放在这里）

开始只执行前两个的压缩文件组备份，然后将较小的备份复制到DR服务器。您可以使用SQL Server 2008的文件组备份和还原功能来还原主要和ClusteredIndex文件组，然后它们将立即可用于查询。在您在线获取ExtraneousCrap文件组之前，它们实际上是不可行的，但是这也有一个讨厌的窍门-在MVP Deep Dives书中，有一章介绍了编辑系统表以使ExtraneousCrap文件组以及所有相关索引的消失。这个把戏很危险，完全不受支持，真是个坏主意-但是，嘿，您要的。

— 布伦特·奥扎尔
source

10

我建议切换到日志传送之类的东西。本质上，如果您选择在24小时内发送30 Gig，而不是在较短的时间范围内在一天结束时发送，则网络速度对您来说就不是一个问题。

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

除了sql server压缩外，您还可以实现第三方工具，如litespeed或redgate sqlbackup等具有更高压缩率的工具。

此外，在网络端，您可以安装网络设备，以优化您到灾难恢复站点的吞吐量。过去，我成功使用Riverbed Appliance在不到3小时的时间内成功地将90GB的备份从FL备份到VA。

另一种选择是备份特定文件组（不包括索引等），但是您仍然受簇索引的约束，根据您的数据库结构，您可能会获得更多成本/麻烦，而无法从该方法中受益。

谢谢

— 约翰达科斯塔
source

7

如果您有足够的钱，并且您的体系结构允许这样做，请查看类似Riverbed技术（http://www.riverbed.com/cn/）的内容。最好将这样的设备与复制或日志传送方案结合使用。

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

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

— SQLChicken
source

你能再解释一下吗？我知道这是针对StackExchange团队的，所以我确定他们会喜欢更深入的演练;）

— jcolebrand

哈哈，这里有很多要考虑的问题。您想让我详细解释哪一点？

— SQLChicken 2011年

复制/日志传送是我的初衷，但这就像两个星期前一样，因此我怀疑它现在是否同样重要。另外，我只是重新阅读并看到了有关Citrix的部分，然后我可以（现在）告诉您他们不这样做。他们只是使用DVCS基础结构进行本地开发，只希望数据用于测试/播放/确认。也可能用于数据转储。

— jcolebrand

知道了然后，正如其他人已经说过的那样，Redgate和Quest等第三方供应商拥有非常好的备份压缩工具，可以帮助您满足他们的需求。另一个潜在的解决方案是SQL Azure。目前，数据库大小限制为50GB，但他们提高了加载任何数据的费用，因此这可能是一种经济高效的解决方案。

— SQLChicken 2011年

4

我将使用SQL事务复制。您的初始负载会花费一些时间，但是一旦启动并运行，您就只能发送所需的信息。例如，如果您只有3或4个要更新的表，则只能发送这3或4个表。

您还可以选择要运送的物品。FK，集群/非集群索引，表分区方案，存储的proc和TONS等。

http://www.sql-server-performance.com/2010/transactional-replication-2008-r2/

如果这不是一个选择，则可以使用REDGATE SQL BACKUP- http://www.red-gate.com/products/dba/sql-backup/。我以前使用过它，压缩率高达90％。比SQL小很多。

— SqlSandwiches
source