>背景：
我已经为我的公司构建了一个文档管理系统来管理公司文档(~1TB，文件表中有 100 万+ 行(。
该应用程序是使用 .net 4.8 和 EF6 构建的。DB是SQL Server 2017。文件在 SQL Server 中保存为 FileStream BLOB。文件可以通过网络前端/API 下载/上传。
数据库大小约为 1TB，其中 95% 是文件流 blob，每年的增长率约为 20%。
我们当前的备份策略是：
- 全量备份(每周(
- 差异备份(每日(
- 传输日志备份(每 15 分钟一次(
我们面临的挑战：
- 完整备份将需要 7-8 小时 - 由于备份操作的 I/O 容量消耗，正常操作可能会受到影响。
- 如果发生任何灾难，数据库还原将需要很长时间(这是我们最大的担忧(。 备份
- 文件大小太大(完整备份文件约为900GB(
- 所有历史数据都需要可访问，因此我们无法真正存档数据。
问题：
- 考虑到这种情况，关于SQL备份，我们的最佳策略是什么？
- 我见过有人使用文件组来分离冷/热数据。由于所有已上传的文件都是只读的，因此有没有办法在系统中使用文件组？
考虑到这种情况，关于SQL备份，对我们来说最好的策略是什么？
我相信，当前的备份策略(您提到的(在您的情况下似乎很好。
完整备份将需要 7-8 小时 - 由于备份操作的 I/O 容量消耗，正常操作可能会受到影响。
您可能希望找到正确的时间窗口来执行完整备份，以减少服务器上的开销。
识别备份期间的 IO 延迟(无论是读/写(将帮助您更好地规划，即由于读取备份或将备份写入共享位置的 IO 延迟而导致的延迟(7-8 小时(。由于您已经有完整的持续时间，因此您可以识别读取操作延迟执行BACKUP TO DISK = 'null'。写入操作的概率(延迟(更大，在这种情况下，您可以通过将其保存在本地/更快的存储驱动器来减少备份时间，并在备份完成后移动到常规共享位置。
如果发生任何灾难，数据库还原将需要很长时间(这是我们最大的担忧(。
考虑完整备份在备份期间很慢，在恢复期间更快，这在LO备份情况下完全相反。因此，提到您的备份策略很好。
但是，对于DR，最佳选择是日志传送，它会定期还原辅助服务器上的 LOG 备份，因为完整备份仅还原一次，两端(主站点和 DR 站点(都不会有太多负载。请考虑常规日志备份(15 分钟(将替换为日志传送作业。
使用 LS 作为灾难恢复解决方案时，恢复时间等于最近的 LOG 还原可能需要的时间。
备份文件大小太大(完整备份文件约为900GB(
我相信，这是标准压缩级别，在SQL引擎中可以达到最大值，并且不会有太多选择来减小备份的大小。