DBA 们，
我们的 SQL 环境需要升级备份解决方案，我们正在寻求社区的意见。共有 8 个数据库分布在 4 台服务器上，大小总计为 100GB，另外还有一个第 9 个数据库，大小为 450GB，未包含在下面的数字中。所有数据库都位于带宽很大的数据中心（OC-3）。
目前，备份是从 SQL Management Studio 维护计划运行到数据中心的数据库阵列。异地备份由员工每周插入 USB 驱动器并复制数据并将该驱动器带回办公室进行。我们理想情况下希望消除人工必须进入数据中心才能提取数据的环节。
目前备份是每日全量备份。可以使用 Lite-speed 进行压缩，我们可以继续运行每日全量备份，以方便使用，或者我们可以将某些数据库的 1 个全量 3 天差异加转换备份和将其他数据库的 1 个全量 6 天差异加转换备份混合使用，而不是全部使用全量备份。对此有什么想法吗？
一种异地选项是使用 DFS 或另一种复制机制，在夜间通过 T1 将数据中心备份共享同步到办公室/异地位置的共享。在计算数字时，如果我们要转向不同的计划，我们会看到大多数晚上的备份数据约为 6GB，周六晚上的备份数据约为 19GB。如果完整的 T1 可用于同步过程，那么大多数晚上需要 9 个小时，周六需要 27 个小时。
另一种选择是购买具有异地备份订阅的设备，将数据从异地位置发送到第三方数据中心，但我们可能会看到高昂的成本。
每周大约有 59.5GB 的数据，所以如果我们想保留 2 个月，那大约就是 0.5TB。
有什么想法吗？
提前致谢！
答案1
我认为这完全取决于您可以花多少钱以及需要哪种类型的保留。我们的基础设施组有一个 SAN，提供 TB 的存储空间。我们有一个网络共享到 SAN 上的一个文件夹，我们将所有 SQL 备份都写入该文件夹。我们有超过 15 个 SQL 服务器和 150 多个数据库。我为每个数据库制定了 1 个完整备份维护计划（每日，非工作时间）和 1 个事务日志计划（每 15 分钟）。这两个计划都会删除超过 24 小时的文件，以保持备份位置的整洁。这样，如果出现任何问题，我就可以访问一天的数据。然后，备份也会每晚备份到磁带上。我们可以根据需要保留这些文件。我们目前的保存时间为 3 个月。
我完全同意你需要去除人为因素，正如你所说。理想情况下你不应该触及任何方面（除了磁带）。
我个人不喜欢场外选项，因为如果有必要，我至少可以自己去放磁带。我知道你与他们有服务协议，但仍然......
希望这能给你一些想法。
答案2
绝对会使用差异备份，如果可以的话，每月进行一次完整备份，如果备份窗口没有足够的时间进行复制，则需要手动进行。
“KISS” 保持简单。
答案3
对于恢复来说，全量/差异/t-logs 的混合是更好的选择。数据丢失会更少，因为使用 t-log 最多会丢失一小时的数据，而不是一整天的数据。正如我之前读到的，人们进行备份的原因是为了恢复。
答案4
第五篇帖子——我同意迄今为止发布的大部分内容，并且不会重复。
何时进行完整/差异/事务日志备份取决于您的系统执行的操作和时间。通常，这适用于每周周期，因为其中一天往往是休息日（周日，或者可能是周一，因为您要在周末业务结束后进行清理）。我建议至少每周进行一次完整备份；如果该备份出现问题，您必须返回到上一次备份，丢失最多两周的数据远不如丢失最多两个月的数据那么糟糕。（而且总是有些事情……我工作过的地方的其他部门曾经遇到过“数月来没有有效的完整数据库备份”的情况 [因为他们没有制造它们，但那是另一个故事]。在恢复了几周的 t-log 备份后，他们发现一个已损坏的备份，因此必须执行 B 计划：找出相关文件并重新输入几个月来的所有工作。）
如果周日比较空闲，可以重新索引、每周存档等等前每周进行一次完整备份是个好主意，这样所有的繁琐工作就不会被加载到差异备份中。（我习惯于每周进行一次完整备份，但一如既往，这在很大程度上取决于您的业务和数据使用模式。）
听起来，通过网络将数据复制到家庭办公室确实不太实际。如果数据量在一夜之间增长到超出您的复制能力，会发生什么情况？
磁带备份很好，而且可以自动化（尽管需要花钱）。外部存储服务也不错；它们需要花钱，但既然他们无论如何都要拜访你，也许你可以让他们去服务器机房？（取决于安全性、访问权限等。）