Your browser may have trouble rendering this page. See supported browsers for more information.

This page shows the source for this entry, with WebCore formatting language tags and attributes highlighted.

Title

Time Machine Backups

Description

I continue to be mystified as to how Microsoft has not managed to create a backup system as seamless and straightforward and efficient as Time Machine for OS X. The software is, however, not without its faults. As is usual with Apple software, Time Machine becomes quite frustrating and unwieldy when something goes ever so slightly wrong. When it works, it works very well. It is unobtrusive. You have hourly backups. It is as technology should be: serving you. At the beginning of the year, I bought an NAS (Network-attached Storage) to improve file-sharing at home. I then moved my Time Machine backups from an individual external hard disk for each OS X machine with Time Machine support (a grand total of two of them) to the home cloud (the aforementioned NAS). This all worked quite well. I connected each machine to the NAS directly to create the initial, full backup and, after that, the machines burbled along, backing up efficiently over the wireless network. That is until, one day, something went mysteriously wrong. Both of my machines have experienced this, seemingly without cause. The helpful error message is shown below. <img src="{att_link}time_machine_nas_error.png" align="none"> If you read through it carefully, you'll see quite an implicit threat: the "Start New Backup" button, offered as the "quick-win" solution, will simply throw away all of your previous backups. Don't be seduced by the "Back Up Later" button. All it does is show you the <i>exact</i> same message one day later. You are free to put off the decision indefinitely, but you will become well acquainted with this message. Thanks Apple! Is that really the best that you can do? You just give up and tell me that I have to either (A) reconnect my machine to the LAN and run a backup that will take 12 hours or (B) just go ahead and try the same, but on the wireless LAN, which will take four times longer. This is a typically technocratic software failure: the error was caught and acknowledged, so ... mission accomplished. That is most decidedly <i>not</i> the case. Apple should be eminently aware that this message will be shown to people for whom a fresh non-incremental backup entails not just dozens of hours but possibly <i>days</i>. Not only that, but <i>uninterrupted</i> hours/days. It is just not acceptable to give up so easily without even <i>trying</i> to repair the problem. So that's where we stand: the automated backup---lovely as it is when it works---performs some sort of verification and then gives up. But a manual verification has, to date, never failed. And I've applied the solution below several times now, for both machines. The solution is documented in <a href="http://www.garth.org/archives/2011,08,27,169,fix-time-machine-sparsebundle-nas-based-backup-errors.html" author="Garth Gillespie">Fix Time Machine Sparsebundle NAS Based Backup Errors</a><fn>: <ol> <c>su Admin</c> (change to an administrator/sudoer account, if necessary) <c>su -</c> (change to the root user) <c>chflags -R nouchg /Volumes/marco/Magni.sparsebundle</c> (fix up flags/permissions) <c>hdiutil attach -nomount -noverify -noautofsck /Volumes/marco/Magni.sparsebundle</c> (attach backup volume, which automatically starts a file-system check) <c>tail -f /var/log/fsck_hfs.log</c> (show the progress for the file-system check) </ol> The final command will show progress reports of the file-system check; if the check does not start, see the link above for more detailed instructions. Otherwise, you should see the message, <bq>The volume Time Machine Backups appears to be OK.</bq> in the log. Once this has run, you have to reset the status of the backup so that Time Machine thinks it can use it again: <ol> Browse to <c>/Volumes/marco/Magni.sparsebundle</c> in the Finder Right-click the file and select "Show Package Contents" from the menu Open the <c>com.apple.TimeMachine.MachineID.plist</c> file in a text editor <div>Remove the two lines: <code> <key>RecoveryBackupDeclinedDate</key> <date>{whatever-the-date}</date> </code></div> <div>Change the value of <c>VerificationState</c> to 0, as shown below: <code> <key>VerificationState</key> <integer><hl>0</hl></integer> </code> </div> </ol> It's not very straightforward, but it's worth it because <i>you won't lose your entire backup history</i>. In my experience---and that of many, many others who've littered their complaints online---Time Machine will, at some random time, once again fail verification and offer to chuck your entire backup because it can't think of a better solution. Not only that, but once you've reset everything and Time Machine has run a backup, you might catch it surreptitiously re-running the verification. I highly recommend canceling that operation. Otherwise, despite the image just having been verified---and used for backup---not ten minutes before, Time Machine will once again throw its hands in the air, declare defeat and deliver the bad news that there's nothing for it but to start from scratch. Irritating as it is to have to perform these steps manually, it doesn't even take that long, even when run over a wireless network. It would be utterly lovely if Apple could get this part working a little more reliably. <hr> <ft>The example path---<c>/Volumes/marco/Magni.sparsebundle</c>---is for a volume called "marco" on my NAS where the Time Machine backup for the machine "Magni" is stored. Obviously you will have better luck if you replace the volume and backup names in the path with those corresponding to your own NAS and machine.</ft>