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