Time Machine Repair
Published 2013-10-18 @ 12:00
Tagged thoughts, osx
(last updated: 2020-06-19)
Turn off time machine on all involved parties, then:
% TM=mybackups.sparsebundle
% sudo chflags -R nouchg $TM
% plutil -remove RecoveryBackupDeclinedDate com.apple.TimeMachine.MachineID.plist
% plutil -replace VerificationState -integer 0 com.apple.TimeMachine.MachineID.plist
# See note section below:
% sudo hdiutil attach -nomount -noverify -noautofsck -readwrite $TM
# Note the device it is attached to and save it off:
% DEV=/dev/diskXs2
% sudo fsck_hfs -drfy $DEV || sudo fsck_hfs -p $DEV
% hdiutil detach $DEV
For me, everything fixed itself so I was able to skip the last step.
Note:
I’ve extended the above fsck_hfs
commands via some of the comments
on garth.org’s post, but the reality is I usually use DiskWarrior’s
“Rebuild Disk Image” feature. It handles all of the mounting/attaching
and has a better repair track record than fsck_hfs
does… It is
slow and takes a lot of RAM at times (whereas fsck_hfs
is just
slow). I’ve mitigated some of this by splitting up my time machine
backups to an ancient archive vs the current backup image to reduce
the amount of stuff it needs to repair.
Additional Repair:
At times, I’ve found that replacing the token
file inside the
sparsebundle to help:
hdiutil create -size 1t blah.sparsebundle
mv blah.sparsebundle/token $TM/token
rm -rf blah.sparsebundle
And sometimes it seems that time machine gets “stuck” knowing that the backup destination is read only. Just remove and re-add it:
% tmutil destinationinfo | grep -A1 afp: | grep ID | cut -f2 -d:
URL : afp://ryan@NAS._afpovertcp._tcp.local/backups
ID : 5AC4BD3B-C6CD-4F55-9304-375694C01DC4
% sudo tmutil removedestination 5AC4BD3B-C6CD-4F55-9304-375694C01DC4
% sudo tmutil setdestination -ap afp://ryan@NAS._afpovertcp._tcp.local/backups
Destination password: *****