我得到了一个MS-SQL服务器备份.bak文件来恢复我的机器上的大小约为25MB，但需要10Gb的可用磁盘空间，因为日志文件的大小，这表明他们的日志文件没有退出也不截断。 （请注意，10Gb日志文件必须大部分为空，否则.bak文件将比25mb大很多）
这个数据库是一个小的使用（可能不是非常重要的）数据库，同一个站点有另一个更重要和更大的数据库，（大小在某个地方的5 Gb），有一个较小的日志文件，所以我假定该数据库的日志文件正在修剪。
我被告知，该网站使用日志传送备份他们的主数据库到第二台服务器，但我不知道是否小型数据库也被备份。
所以，我猜测他们只是使用主数据库的日志传送，或者他们只是备份主数据库。
这提出了几个问题
在日志备份之后，SQL实际上不会调整日志的大小，而只是更改内部元数据以标记可以重新使用的日志部分（称为虚拟日志文件或VLF）。 这个过程被称为日志截断。 所以，如果没有免费的VLF，你的日志文件将会增长，但是除非你手动告诉SQL Server这样做，否则永远不会收缩。
由于数据库的日志大小为10Gb，因此无论实际使用的数量是多less，恢复备份也会创build一个10Gb日志文件。 这同样适用于任何数据文件。
您可以使用' DBCC SHRINKFILE '命令缩小日志文件 – 尽pipe除非您确定日志不会再次增长到10Gb，否则我build议不要这么做（性能会影响文件的增长）。 长时间运行的事务或数据库维护活动可能会占用大量事务日志，因此值得注意的是为什么日志在10Gb之前收缩。
回答你的3个问题：
是否有任何用户/pipe理员可以执行的备份干扰或中断日志传送？
是 – 如果通过将日志备份到日志传送configuration之外的目标来中断备份链，导致备份不会应用到辅助服务器。 在这种情况下，您应该使用COPY_ONLY备份，因为这些备份不会破坏日志链。 这仅适用于日志备份，因为完整备份不会截断日志。
如果您使用日志传送，是否足以确保日志不会持续增长，还是需要备份日志（例如使用维护计划）？
这应该没有问题，除非有其他的东西会阻止日志被截断，比如数据库镜像，长时间运行事务，复制甚至数据库快照的创build。 找出为什么你的日志不被截断的方法是查看sys.databases中的log_reuse_wait_desc列。
日志传送的备份作业也有可能（但不太可能）使用COPY_ONLY / NO_TRUNCATE进行备份，这意味着日志文件一旦完成就会不断增长。
这个不是太重要，但是如果我得到的备份需要比我有的更多的日志文件空间，是否有任何方法可以在没有日志文件的情况下恢复它，或者没有从源头解决问题并获得新的备份。
如果您收缩日志文件，然后进行完整备份，当您还原它时，SQL Server将使用较小的日志文件创build数据库。
如果你无法缩小，但是你正在恢复到一个开发/testing服务器，那么你可以挂载一些临时存储，并在RESTORE语句中使用'WITH MOVE'将日志文件移动到该驱动器，然后缩小日志并移动日志将临时存储文件归档（关于是否缩小日志还是不适用！）。