[華語, cmn-Hant-TW]
Time Machine 跑一跑突然跳出來說無法備份，查了一下 /var/log/system.log 發現長這樣 (重點部位打馬賽克)
May 24 14:04:52 Panther com.apple.backupd[25334]: Starting standard backup
May 24 14:04:52 Panther com.apple.backupd[25334]: Attempting to mount network destination using URL: smb://whsyu@10.9.1.120/backup_panther
May 24 14:04:56 Panther com.apple.backupd[25334]: Mounted network destination using URL: smb://whsyu@10.9.1.120/backup_panther
May 24 14:04:56 Panther com.apple.backupd[25334]: Backup verification failed for image /Volumes/backup_panther-1/Panther_${MAC_ADDR}.sparsebundle!
May 24 14:04:56 Panther com.apple.backupd[25334]: Error 513 changing immutability for /Volumes/backup_panther-1/Panther_${MAC_ADDR}_2010-05-24-140456.sparsebundle
May 24 14:04:56 Panther com.apple.backupd[25334]: Unable to make /Volumes/backup_panther-1/Panther_${MAC_ADDR}_2010-05-24-140456.sparsebundle immutable!
May 24 14:04:56 Panther com.apple.backupd[25334]: Creating disk image /Volumes/backup_panther-1/Panther.sparsebundle
May 24 14:04:58 Panther com.apple.backupd[25334]: Error -5000 creating backup disk image
May 24 14:04:58 Panther com.apple.backupd[25334]: Failed to create disk image /Volumes/backup_panther-1/Panther.sparsebundle, status: -5000
May 24 14:05:03 Panther com.apple.backupd[25334]: Backup failed with error: 20
May 24 14:05:03 Panther com.apple.backupd[25334]: Ejected Time Machine network volume. |
這個映像檔是放在遠端透過 smb 連線，所以 backupd 會自動嘗試掛載，然後似乎是因為映像檔檢查失敗所他嘗試要做一些處理來修復，結果修不好就噴錯誤訊息了。而且不只是噴錯誤訊息，連映像檔的檔名都被改了，看起來像是附加時間標記，應該是做到一半爛掉吧。
備份是放在一台 FreeBSD 的某個 zfs 磁碟上，因為有做每日的 snapshot，所以試著從之前幾天的備份撈看看，錯誤依然存在；先人工 fsck 再讓 Time Machine 讀，結果還是一樣，最後就決定直接去碰映像檔裡面看看有沒有什麼地方可以動的。
雖然說 .sparsebundle 在 Finder 下看到是一個映像檔，不過其實底層就跟 .app 一樣只是一個目錄，也因此要看內容很方便，只要切到目錄內即可。 經過了一些嘗試發現裡面有一個檔案叫 com.apple.TimeMachine.MachineID.plist 裡面有記錄一些前次備份的資訊，包括驗證結果等等 (從檔案內的 xml 標記來猜測)。 對照錯誤訊息的紀錄可看出 backupd 幾乎是瞬間判定驗證失敗，那就很有可能是直接參考這個檔案後立刻做出反應。 把這個檔砍掉之後開 Time Machine 再叫他備份一次，果然這次 backupd 就乖乖的重新跑 fcsk_ufs 來驗證，驗證完之後又可以正常備份了。
在測試的過程中 zfs 的 snapshot 幫了不少忙，因為在試這個檔案之前有先惡搞映像檔內的其他檔案過，結果當然是失敗了，不過一失敗後就立刻用 zfs rollback 把實驗前剛打的 snapshot 還原回來重測別的檔案，這個回溯幾乎是瞬間完成，省了不少時間跟指令。
今天又遇到一次，用原文方法直接砍掉爛掉那個映象檔裡面的 plist 無解，不過直接撈前幾天的備份之後就恢復正常了。
又遇到了，後來發現直接跳過驗證步驟似乎也是可行的解法，當然前題是要確定映象檔是正常的才能放心跳過就是。