我收到一个 MS-SQL 服务器备份 .bak 文件，需要在我的计算机上恢复，该文件大小约为 25mb，但需要 10Gb 的可用磁盘空间，因为日志文件就是这个大小，这表明日志文件不会被撤消或截断。（请注意，10Gb 日志文件必须大部分为空，否则 .bak 文件将比 25mb 大很多）
这个数据库是一个很少使用的（可能不是很重要）数据库，并且同一站点有另一个更重要和更大的数据库（大小在 5 Gb 左右），它的日志文件较小，所以我假设该数据库的日志文件正在被修剪。
有人告诉我该网站使用日志传送将其主数据库备份到第二台服务器，但我不确定是否也备份了较小的数据库。
因此，我猜测他们要么仅对主数据库使用日志传送，要么仅备份主数据库。
这引发了一些问题
- 现场用户/管理员是否可以执行任何类型的备份，但会干扰或中断日志传送？
- 如果您使用日志传送，是否足以确保日志不会持续增长，或者您是否仍然需要备份日志（例如使用维护计划）？
- 这个不是太重要，但是如果我得到的备份需要比我可用的更多的日志文件空间，有没有办法在没有日志文件的情况下恢复它，或者不从源头修复问题并获取新的备份。
答案1
SQL 实际上不会在日志备份后调整日志大小 - 相反，它只是更改内部元数据以标记日志中可重复使用的部分（称为虚拟日志文件或 VLF）。此过程称为日志截断。因此，如果没有可用的 VLF，您的日志文件将增大，但除非您手动告诉 SQL Server 这样做，否则它永远不会缩小。
由于数据库的日志大小为 10Gb，因此无论实际使用量是多少，恢复备份也将创建一个 10Gb 的日志文件。这同样适用于任何数据文件。
您可以使用'DBCC 收缩文件' 命令 - 但除非您确定日志不会再次增长到 10Gb，否则我建议不要这样做（文件增长会影响性能）。长时间运行的事务或数据库维护活动可能会占用大量事务日志，因此在缩小之前，有必要找出日志为何为 10Gb。
回答你的 3 个问题：
现场用户/管理员是否可以执行任何类型的备份，但会干扰或中断日志传送？
是的 - 如果您将日志备份到日志传送配置之外的目标位置，从而破坏了备份链，导致备份无法应用于辅助服务器。您应该使用仅复制在这种情况下，备份不会破坏日志链。这仅适用于日志备份，因为完整备份不会截断日志。
如果您使用日志传送，是否足以确保日志不会持续增长，或者您是否仍然需要备份日志（例如使用维护计划）？
这应该没问题，除非有其他东西阻止日志被截断，例如数据库镜像、长时间运行的事务、复制甚至数据库快照创建。找出日志未被截断的原因的方法是查看 log_reuse_wait_desc 列系统数据库。
日志传送的备份作业也有可能（但不太可能）使用 COPY_ONLY/NO_TRUNCATE 进行备份，这意味着日志文件一旦满了就会不断增长。
这个不是太重要，但是如果我得到的备份需要比我可用的更多的日志文件空间，有没有办法在没有日志文件的情况下恢复它，或者不从源头修复问题并获取新的备份。
如果您缩小日志文件然后进行完整备份，则当您恢复它时，SQL Server 将使用较小的日志文件创建数据库。
如果您无法缩小但要恢复到开发/测试服务器，那么您可以安装一些临时存储并在 RESTORE 语句上使用“WITH MOVE”将日志文件移动到该驱动器，然后缩小日志并将日志文件从临时存储中移出（关于是否应该缩小日志的警告仍然适用！）。