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.

From: http://www.garth.org/archives/2010,07,16,124,fixing-time-machine-sparsebundle-network-backup-errors.html

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: *****