SQL数据库备份失败求助：1.1TB库备份报1359错误

刚看到你遇到的这个头疼问题——1.1TB的数据库备份快完成时触发了SetEndOfFile错误1359，导致备份直接终止，这种情况我之前帮不少用户排查过，咱们一步步来拆解解决：

先搞懂错误本质 #

错误1359是系统层面的内部错误，结合SQL的报错上下文，大概率和备份目标路径的存储资源、权限限制或者文件系统特性有关，不是SQL本身的核心功能问题。

逐一排查解决办法 #

• 先查备份目标磁盘的可用空间
  虽然进度显示到90%左右，但很可能磁盘空间刚好在备份收尾阶段不足。1.1TB的数据库做完整备份，哪怕开启压缩也需要几百GB的空间，建议先确认目标盘剩余空间是否比预估备份大小多20%以上，避免卡最后一步。

• 验证SQL服务账户的路径权限
  执行备份的SQL Server服务账户，需要对\Dive\sql\这个文件夹有完全控制权限。有时候临时修改了文件夹权限、更换了服务账户，会在备份后期（比如执行SetEndOfFile操作时）触发隐性的权限问题，虽然报错码是1359，但权限不足是常见诱因。手动给SQL服务账户添加上该路径的完全控制权限试试。

• 检查文件系统的最大文件限制
  如果目标磁盘是FAT32格式，单个文件最大只能到4GB，1.1TB的备份肯定直接超限制，必须转换成NTFS格式（用命令convert X: /fs:ntfs，X是对应磁盘盘符，转换不会丢失数据）。就算是NTFS，也要确认有没有第三方存储工具设置了文件大小配额，限制了备份文件的生成。

• 尝试拆分备份到多个文件
  大数据库备份成单个文件很容易触发各种存储层面的问题，你可以试试多文件备份的方式，比如：

  BACKUP DATABASE YourDatabaseName
  TO DISK = N'\Dive\sql\Stage_backup_2018_04_25_001501_1259003_1.bak',
       DISK = N'\Dive\sql\Stage_backup_2018_04_25_001501_1259003_2.bak',
       DISK = N'\Dive\sql\Stage_backup_2018_04_25_001501_1259003_3.bak'
  WITH INIT, COMPRESSION;
  

  这样每个备份文件体积会小很多，降低单个文件写入时的出错概率，同时开启压缩还能减少备份体积和耗时。

• 排查磁盘硬件和驱动问题
  如果上面的方法都没用，可能是磁盘本身有坏道或者驱动老旧。可以用chkdsk X: /f /r命令检查磁盘错误（注意需要先卸载磁盘或者在安全模式下运行，避免占用），同时更新磁盘控制器的驱动程序，老旧驱动很可能在大文件写入的收尾阶段出问题。

• 临时更换备份目标路径
  如果当前备份到的是网络共享盘，试试换成本地磁盘备份。网络连接不稳定时，很容易在执行SetEndOfFile这种收尾操作时失败。如果换本地盘能成功，那就是原共享路径的存储环境有问题。

总结 #

先从空间、权限、文件系统这几个最容易排查的点入手，大概率能解决问题。如果还是不行，再尝试拆分备份或者检查硬件。

内容的提问来源于stack exchange，提问作者user9192401