可以将多少个备份附加到单个文件是否有限制？

Question

最近的一个问题让我看着 MS 文档并感到疑惑。

可以将多少个备份附加到单个文件是否有限制？

默认情况下，SQL Server 用于NOINIT将新备份附加到旧备份文件。

{ NOINIT | INIT } 控制备份操作是附加到还是覆盖备份介质上的现有备份集。默认是附加到媒体上的最新备份集 (NOINIT)。来源

文档明确指出，可用磁盘空间不足将导致附加备份失败。

如果在备份操作将备份附加到媒体集时磁盘文件已满，则备份操作将失败。备份文件的最大大小取决于磁盘设备上的可用磁盘空间；因此，备份磁盘设备的适当大小取决于备份的大小。来源

SQL Recover from .bak file with NOINIT的答案表明PositionfromRESTORE HEADERONLY指示文件中的单个备份。这是一个“smallint”字段，最大应为32,767

大多数情况下，在谷歌搜索时，您会发现有人不小心附加了他们的备份，并且无法理解为什么备份如此之大。

假设有足够的磁盘空间，我没有找到任何关于可以附加多少备份的明确参考。极限是 32,767 还是其他什么东西？

Answer 1

TL：博士；可能将 32,000 多个备份放在一个文件中。如果这是一件好事，或者您是否可以从此文件的备份中恢复，则不在此处讨论。

我昨晚开始在一个没有活动的现有数据库 (231682) 上进行 tlog 备份。我使用了一个 while 循环和一个计数器，所以我可以得到一个运行总数。

DECLARE @counter int
SET @counter = 1
While 1=1
Begin 
BACKUP LOG [231682] TO  
DISK = N'G:\SQLBackups\Test_Tlog.trn' WITH NOFORMAT, NOINIT,  
NAME = N'231682-Log Database Backup', SKIP, NOREWIND, NOUNLOAD
SET @counter = @counter + 1
print @counter
End

• 16 小时后，计数为 5,967，文件大小为 356MB。这可能需要一段时间。开始时每秒完成 24 个日志备份。
• 1 天 16 小时：计数为 8,401，文件大小为 700MB，sp_whoisactive显示等待信息 (2029ms)BACKUPTHREAD
• 4 天 18 小时：计数为 12,834，文件大小为 1.6GBsp_whoisactive显示等待信息（52113 毫秒）备份之间的 BACKUPTHREAD 时间已减慢到每个日志备份约 70 秒。
• 5 天和几个小时；外部事件（服务器重启）导致 tlog 备份停止。已完成备份的计数为 13,717 文件大小为 1.8GB，备份之间的时间约为 80 秒。已验证 restore headeronly from disk='G:\SQLBackups\Test_Tlog.trn'未尝试恢复数据库，因为这会非常痛苦。设置计数器以开始SET @counter = 13717和重新启动使用相同代码将备份添加到同一文件。备份恢复，大约需要 80 秒
• 1周; 由于外部问题第二次重启。计数为 15,186 个文件大小 2.3GB 每个备份大约需要 90 秒。
• 一周半；计数为 17,919 文件大小为 3.2GB 每个备份大约需要 2 分 25 秒。
• 2周; 计数为 19,645 文件大小为 3.8GB 每个备份大约需要 2 分 45 秒。
• 3周; 计数为 22,919 文件大小为 5.2GB 每个备份大约需要 3 分 30 秒（每小时 17 秒），因为我现在正在作业中运行无休止的 t-log 备份，我已将其添加到代码中，RAISERROR(N'Count equals :%d', 16, 1, @counter ) WITH LOG;因此运行计数显示在SQL 错误日志谢谢@Erik Darling
• 4 周；计数为 25,587 文件大小为 6.6GB 每个备份大约需要 3 分 45 秒（每小时 16 个）
• 5 周；计数为 28,242 文件大小为 8GB 每个备份大约需要 4 分 35 秒，（每小时 13.5 个）
• 6 周；计数为 30,037 文件大小为 9.1GB 每个备份大约需要 5 分钟（每小时 12 个）
• ~7 周：专用备份磁盘上的空间不足。当空间不足时备份开始失败，但作业继续运行和尝试。停止其他一切，通过删除一些文件腾出更多空间。SQL 日志中的计数是错误的，因为它计算了失败和成功的尝试。
  • 停止工作
  • 文件大小为 10.4GB，每次备份大约需要 5 分钟（每小时 12 个），成功或失败的时间相同。
  • 使用restore headeronly from disk='G:\SQLBackups\Test_Tlog.trn'Count检查备份为 32,021
  • 标题暗示所有成功的备份都很好。
  • 大多数备份显示 75,776BackupSize的值和 ~4,000 的值，CompressedBackupSixe每个备份的压缩大小各不相同。
  • 我没有尝试使用 t-log 文件进行恢复。我怀疑会有问题，我想在我把一切变得像现在这样丑陋之前尝试一下。
  • 删除t-log文件，重启正常备份。

我在这个实例上默认压缩备份。

第 3 周 注意：文件大小和备份时间与备份数量不成比例。查看 tlog 标头，我们看到位置 2 中的备份大小为 75766 字节，开始到完成时间为一秒或更短。位置 22919 中的备份也具有 75766 字节的大小和一秒或更短的开始到完成时间。将备份附加到同一文件的开销似乎导致速度变慢。异常增长可能与我在实例上运行的每周维护任务有关。

异地备份，看起来我的异地备份解决方案 (IBM Spectrum) 没有备份 trn 文件。我怀疑这是因为文件不断被编辑。

编辑，一段时间后。我正在考虑做另一个实验来测试大约 30,000 个备份的恢复。为了避免尝试恢复多个 t-log 的问题，我考虑使用差异备份。我创建了一个空数据库，进行了完整备份，然后进行了 10 次差异备份。然后我进行了 10 个 t-logs 备份并使用RESTORE HEADERONLY FROM DISK我比较了大小，差异备份明显大于 t-logs，我没有足够的空间来执行良好的测试。

差异备份 2-10（第一个总是大一点）

• 备份大小 = 1126400
• 压缩备份大小 = 62271

T-Logs 备份 2-10（第一个总是大一点）

• 备份大小 = 75776
• CompressedBackupSize = 3800（平均值，因人而异）

差异备份大约大 16 倍，最好的情况下我只能得到大约 2,000 个，此时我不做进一步的测试。