DBA 在那里，
我们有一个需要升级备份解决方案的 SQL 环境，我们正在寻找来自社区的一些意见。共有 8 个数据库分布在 4 个服务器上，总大小为 100GB，另外还有一个 450GB 的第 9 个数据库不包括在下面的数字中。所有这些都位于具有大量带宽（OC-3）的数据中心。
目前，备份是从 SQL Management Studio 维护计划运行到具有 DB 的数据中心的阵列。异地备份由一名员工每周插入一个 USB 驱动器并 x 复制数据并将该驱动器带回办公室进行。理想情况下，我们希望消除人类必须进入数据中心才能提取数据的情况。
目前，备份是每日完整的。Lite-speed 可用于压缩，为了舒适起见，我们可以继续每天运行，或者我们可以混合使用 1 个完整的 3 天 diff 加上 trans 用于某些 DB，而 1 个完整的 6 天 diff 加上 trans 用于另一个DBs，而不是全部。对此有什么想法吗？
一个异地选项是使用 DFS 或另一种复制机制，以在夜间通过 T1 将数据中心备份共享同步到办公室/异地位置的共享。如果我们要转移到差异计划，则在运行数据时，我们正在查看大多数晚上约 6GB 的备份数据，周六晚上约 19GB 的备份数据。如果完整的 T1 可用于同步过程，则大多数晚上为 9 小时，周六为 27 小时。
另一种选择是购买具有异地备份订阅的设备，以将数据从异地位置发送到第 3 方数据中心，但我们可能会面临高昂的成本。
每周大约有 59.5GB 的数据，所以如果我们想保留 2 个月，大约是 0.5TB。
有什么想法吗？
提前致谢！
肯定会使用差异备份，如果你能侥幸成功的话，如果备份窗口不允许有时间复制它们，则每月进行一次完整备份。
“吻”保持简单。
对于恢复 fulls/diffs/t-logs 的混合是更好的选择。数据丢失会更少，因为最多使用 t-log 会丢失一小时的数据，而不是一整天的数据。正如我之前所读到的，人们进行备份的原因是为了恢复。
每周我们都会进行两次完整的增量和 4 次增量（周日我们的系统几乎没有任何事情发生，所以这是运行清理的好时机）。1 个完整的保存在现场，我们设置它来旋转磁带（我们有一个非常好的磁带库，我们有 23 个磁带和 1 个清洁磁带装入其中）
1 个完整的被发送到场外。这个月的第一个完整的进入一个保险箱，其他人去一个供应商，铁山，他真的来这里接他们。
我们的备份总计约为 1.2Tb 完整备份和 140Gb 增量备份。使用差异对我们有很大帮助，因为填满需要将近 22 小时，而且每天都这样做是荒谬的。我们使用带有 HP MSL G3 磁带库的 Backup Exec 11d
我认为这一切都取决于你可以花多少钱以及你需要什么样的留存率。我们的基础设施组有一个 SAN，我们可以使用 TB 的存储空间。我们在 SAN 上的一个文件夹中有一个网络共享，我们将所有 SQL 备份都写入该文件夹。我们拥有超过 15 个 SQL 服务器和 150 多个数据库。我为每个数据库制定了 1 个完整备份（每天、下班时间）的维护计划和 1 个传输日志的计划（每 15 分钟）。这两个计划都删除了超过 24 小时的文件，以保持备份位置的清理。这使我可以在出现任何问题时访问几天的数据。然后，备份也会每晚备份到磁带上。只要我们需要，这些都可以保留。我们现在是3个月。
我绝对同意您需要像您所说的那样删除人的方面。理想情况下，您实际上不必触摸任何内容（可能磁带除外）。
我个人不喜欢场外选项，因为如果必须的话，我至少可以自己把磁带放进去。我知道你和他们有服务协议，但仍然...
希望对您有所帮助。
第五篇文章——我同意到目前为止发布的大部分内容，并且不会重复。
何时进行 Complete/Differential/TransactionLog 备份取决于您的系统执行的操作和时间。通常，这适用于每周周期，因为一天往往是休息日（周日，或者可能是周一，当您在周末业务后清理时）。我建议至少每周完成一次备份；如果该备份出现问题，您必须返回前一个备份，并且丢失最多两周的数据并不像丢失最多两个月的数据那么糟糕。（而且总是有一些事情......其他部门。在我工作的一个地方，我曾经遇到过“几个月没有有效的完整数据库备份”的情况[因为他们没有制作它们，但那是另一回事]。在恢复了数周的 t-log 备份后，他们发现了一个已损坏的备份，因此不得不执行 B 计划：挖出文书工作，重新输入几个月的所有工作。）
如果周日是缓慢的一天，那么在每周完整备份之前进行重新索引、每周归档等等是个好主意，这样所有忙碌的工作就不会被加载到差异备份中。（我对每周进行一次完整备份感到满意，但与以往一样，这在很大程度上取决于您的业务和数据使用模式。）
听起来确实像通过网络将数据复制到家庭办公室并不是很实用。当数据增长超出您在一夜之间复制的能力时会发生什么？
磁带备份很好，而且非常自动化（尽管它们确实要花钱）。异地存储服务也不错；他们要花钱，但既然他们无论如何都要拜访你，也许你可以让他们去服务器机房？（取决于安全性、访问权限等）
就我个人而言，我更喜欢每天进行完整备份并在磁盘上保留三代 - 我不倾向于使用完整/差异混合，因为完整备份存在无法成功恢复的风险。我知道如果您的数据库很大，这很困难 - 但如今 100GB 并不算太大。
确保您拥有最新版本的 LiteSpeed 并使用最高级别的压缩（除非用户可以在备份运行的同时访问系统）。
考虑删除任何冗余表。
检查并删除任何未使用的索引。
从表和索引中删除碎片。
考虑将旧数据归档到另一个数据库并减少备份频率。
这取决于您的预算，但我的公司刚刚从磁带转移到基于 SAN 的重复数据删除系统，在第二个数据中心有一个镜像 - 我喜欢它。完全摇滚。
我有任何小型数据库，每晚设置完全压缩备份，大型数据库设置每周两次或一次完整和每晚差异，全部到本地磁盘以促进恢复。任务关键的东西将事务日志备份和日志传送添加到场外的热故障转移 SQL 服务器。
从本地磁盘上的文件，自动磁带备份软件（虚拟磁带，不是真实的）将备份文件复制到重复数据删除镜像的一端，镜像自动复制到另一个数据中心。这就像魔术，只有更好。