write failure on backup device 'device.name' Operating system error 112

bestlong

檢查 MSSQL 伺服器運行狀況，在系統日誌內發現備份作業執行失敗的錯誤訊息，重點內容如下：

BackupMedium::ReportIoError: write failure on backup device 'D:\MSSQL2005Backup\devdb\devdb_backup_201210121350.trn'. Operating system error 112(磁碟的空間不足。).

檢視 D 磁碟空間也確實用盡了，基本上修改維護計畫放置備份檔的儲存路徑就可以了。
因 E 磁碟還有大於 200G 的可用空間就拿來用。
不過，再次執行備份作業，同樣的錯誤卻依舊發生。

bestlong

魔鬼總在細節中

備份是IT人員保命丹，一定要第一優先排除萬難解決問題
但是天呀，磁碟機明明還有超大空間但是 SQL 備份作業卻回應空間不足，這是遇到靈異事件嗎？當然不是
檢查 Database Log 檔案的大小居然累積了大於 16GB 的份量
原來是檔案系統的單一檔案大小的限制造成
因為 E 磁碟剛好是 FAT32檔案格式，單檔最大可以到 4GB

在不能立即轉換檔案格式到 NTFS 的狀況下，只好調整備份指令來處理，原來的 SQL 語法如下：

1. BACKUP LOG [devdb] TO  
   
2. DISK = N'E:\MSSQL2005Backup\devdb\devdb_backup_201210121359.trn'
   
3. WITH NOFORMAT, NOINIT,  NAME = N'devdb_backup_20121012135000', SKIP, REWIND, NOUNLOAD,  STATS = 10

複製代碼

那就拆成六個檔案來處理：

1. BACKUP LOG [devdb] TO  
   
2. DISK = N'E:\MSSQL2005Backup\devdb\devdb_backup_201210121500a.trn' ,
   
3. DISK = N'E:\MSSQL2005Backup\devdb\devdb_backup_201210121500b.trn' ,
   
4. DISK = N'E:\MSSQL2005Backup\devdb\devdb_backup_201210121500c.trn' ,
   
5. DISK = N'E:\MSSQL2005Backup\devdb\devdb_backup_201210121500d.trn' ,
   
6. DISK = N'E:\MSSQL2005Backup\devdb\devdb_backup_201210121500e.trn' ,
   
7. DISK = N'E:\MSSQL2005Backup\devdb\devdb_backup_201210121500f.trn'
   
8. WITH NOFORMAT, NOINIT,  NAME = N'devdb_backup_20121012150000', SKIP, REWIND, NOUNLOAD,  STATS = 10

複製代碼

手動執行成功。


結論：
由於該環境是因為原空間用盡的問題沒有及時發現，所以持續累積成較大的檔案。資料異動量很多又剛好遇上 FAT32 的障礙，只要把這個瓶頸先手動處理過之後，後續就讓維護作業的排程處理就可以了。

還有，這個案例是備份交易日誌檔，但是備份資料檔案時觀念也是相同，而且在不同的 MSSQL 版本都會發生。可以的話也是盡早將 FAT32 檔案格式轉換成 NTFS 來降低風險。

官方參考資料 http://support.microsoft.com/kb/325334