我们不介意我们的备份过程需要更长的时间;目前我们需要在WAN上移动30gig压缩备份,耗时超过10小时.
我们有2个选项可以获得较小的每日备份.
>记录运输,这意味着我们必须重组灾难恢复流程.
>从数据库中删除信息并在另一端重建(删除非聚簇索引,将聚簇索引打包为100％ – 在另一端重建)
两者都涉及我们的相当多的工作.我们使用的是sql Server 2008专业版,所有备份都经过压缩.
是否有任何商业产品可以为我们提供类似备份尺寸的选项(2)？
是否有一个全面的脚本可以让我们完成(2)？ (处理索引视图,过滤索引,外键等)
解决方法
每隔6小时使用差异备份,以减少备份FTP的大小/时间.然后将完整备份FTP减少到周末.这样可以避免日志传送的复杂性,操作简单,并且只会增加DR的轻微复杂性
我觉得差异备份被忽略了……我建议之前使用它们：
> How to back up a small database in SQL Server 2008 R2 Express Edition
使用DIFF备份来解决此问题
I’d like to keep everything as simple as possible from a recovery perspective whilst minimising the amount of lost data in the event of a failure
> Pros and Cons of SQL Server back up strategies and their appropriate usage scenarios
> Migrating large database
使用DIFF备份加速备份/还原服务器迁移
编辑：在jcolebrand的评论之后,我将尝试解释更多
差异备份仅占用已更改的页面.在任何索引维护之外(可能会影响很多数据库),只有几个页面会在一天内发生变化.因此,在进行任何压缩之前,差异备份比完整备份要小很多.
如果您有完整备份,比如每周一次,那么您可以进行每日差异并将其发送到网站外.具有差异的每日完整备份仍然需要两个文件都在场外.
您可能需要恢复完整和最新的差异以获取最新数据,但您可以使用NORECOVERY和STANDBY文件来解决这个问题(自从我上一次使用纯DBA以来,我没有尝试使用差异恢复工作).
另外一个好处是差异备份与正在进行的日志备份无关,因此您可以将任何高可用性/ DR要求与“获取数据到代码猴子”要求分开.
如果您通过策略或审计进行每日完整备份,我会看到一些问题,但可以在任何日志还原之前应用差异还原以缩短恢复时间.与备份不同,差异和日志恢复确实相互作用.
希望我已经覆盖了大多数基地……
