我已经插入了一个运行SQL Server 2008和Windows 2003的盒子，并且在安装SQL 2008 SP1之前和之后，都发生了一些大型（35GB）日志备份“失速”的事件。 服务器日志发送到备用数据库，因此每隔15分钟进行一次常规日志备份。
但是，索引reorg导致日志增长到大约35GB（对于大约17GB数据的DB），下一个日志备份运行到大约95％完成，然后似乎停止。 该进程显示为暂停，等待状态为BACKUPIO。 在SPID上的CPU，读取和写入活动也不会改变，并且进程保持在这个状态几个小时，通常这个大小的备份应该在大约20分钟内完成。
此服务器具有单个RAID-1卷，因此源数据库文件和目标备份文件位于相同的卷上。 但是，我无法确定是否有其他进程阻止备份。 备份SPID不能被终止，并且终止日志备份并清除备份文件上的锁的唯一方法是循环SQL Server服务。
有一个事件完全终止了备份，另一个进程locking了备份文件，但没有关于该进程的详细信息。
任何人都可以提出一个原因或诊断过程到这种情况？
一旦失速发生，使用进程pipe理器等工具来确定是否有其他进程正在影响对文件的访问，即locking文件。
运送生成的日志需要很长时间吗？ BackupIO还会在与IO相关的networking操作期间定义networking延迟。
这可能是黑暗中的一个镜头 – 但是当服务器上的防病毒软件在备份过程中开始扫描备份文件时，我已经看到了这种情况。 服务器上是否运行防病毒软件？如果有，是否设置为排除包含备份的备份文件扩展名或卷？