Sometimes OS X tells me that it's "Preparing backup..." for an enormous amount of time. The time it takes seems to have no correlation to the amount of data to be backed up. Same for the "Finishing backup..." stage.
The question: what is OS X doing when it's "Preparing backup..." and "Finishing backup..."?
I know it's figuring out what to backup and then recording the changes, but surely the time this takes should be proportional to the amount of data that changed. There's plenty of space disk space (so I assume it's not deleting old backups). I'm using a TimeCapsule if that makes any difference. Nothing is going wrong with it, I'm just curious.
Here is an answer from another forum (original poster unknown to me):
To compliment Commander Keen's answer I recommend reading an in depth look at Time Machine by Earthling Soft. Additionally more information is logged to system.log by backupd (which will say why the preparing status is so long and such)
To easily view the
backupdlog take a look at the Time Machine Buddy widget. Also note that there's another log on the backup disk itself, in the hidden file.Backup.logwhich can be found in the folder of each backup. This gives some other information than thebackupdlogs.Note that often the logs show figures that do not seem to match:
Above, fewer files are actually copied than first predicted. As Time Machine relies on FSEvents which only reports changed directories, I assume that in the above example these directories held a total of 821.4 MB in files. While actually copying the files, Time Machine then compares the changed directories on the hard disk with the backup, and finds that only 3.8 MB files were actually changed.
To see what has been written to the backup see TimeTracker (GUI) or timedog (command line). Note that, even when running as an admin user, sometimes these programs need to be run as root to see all files. When not doing that, these tools might for example not take the backups of MySQL logs and data into account, owned by _mysql in group wheel:
In those cases both tools will (silently) report a lower total backup size and fewer files than the
backupdlogs in Console. So, if the numbers don't match with the logs, then for TimeTracker:Likewise, for timedog:
To easily find large files on your hard disk see Disk Inventory X. This program has nothing to do with Time Machine, but may help investigating problems, like when you wonder why your backup is a lot smaller than the space used on your hard disk. Note that this program will probably always report less total disk space in its window title than in its screen where one can select which disk to investigate (even when running as root and choosing menu View, Show Physical File Size). But if the reported total size is really a lot smaller than the actual totals used on your Mac, then it may help to run as root:
To remove files from the backup (like if you happen to discover that Time Machine was actually backing up some huge files, such as a runaway MySQL log file), Apple writes:
Now, if those files that you want to delete are only visible to root, then you should invoke "Enter Time Machine" as root as well. And that requires Finder to be started as root first:
This looks like a normal Finder, but you'll notice root next to the home folder icon in Finder's sidebar. Now use Shift-Cmd-G (menu Go, Go to Folder) to get to, for example,
/usr/localand find the folder from which you want to delete the files from the backup disk. Next, enter Time Machine (and once again validate that root is shown next to the home folder icon) and follow Apple's instructions. When done deleting the files from the backup, hit Ctrl-C in Terminal to stop the root-Finder. (I also needed to log off my Mac as the remote disk would not unmount properly.)If you are using a sparse bundle (like when using a backup on the network) then any freed space will not be reclaimed automatically (or: not until the space is needed). To enforce this, see How to reclaim all/most free space from a sparsebundle on OS X. This does not only apply to files you removed manually, but also to files removed by Time Machine for expired hourly or daily backups, during post-backup thinning.
Time Machine will actually compact the sparse bundle itself, when disk space runs out. But it seems it might first delete some old backups during pre-backup thinning, so maybe it's wise to manually compact if you ever deleted some huge files, or if expired backups might have included huge files:
Starting pre-backup thinning: 53.57 GB requested (including padding), 9.90 GB available No expired backups exist - deleting oldest backups to make room Deleted backup /Volumes/Backup of XX/Backups.backupdb/XX/2007-12-20-172543: 9.90 GB now available Deleted backup /Volumes/Backup of XX/Backups.backupdb/XX/2007-12-31-005523: 9.90 GB now available Deleted 2 backups: oldest backup is now 8 Jan 2008 Stopping backup. Backup canceled. Ejected Time Machine disk image. Compacting backup disk image to recover free space Completed backup disk image compaction Starting standard backup [..] Starting pre-backup thinning: 53.57 GB requested (including padding), 12.75 GB availableMany thanks to Adam Cohen-Rose for testing the above; see his blog for more details!
When stuck in "Preparing" (ThinningPreBackup)
Use lsof (be sure to run this as root) to see what files the backups are access - the last file should be changing:
This indicates it is doing something - and to be patient...