Free Space on Time Capsule not Changing

Question

Level 1

0 points

Free Space on Time Capsule not Changing

I've noticed this problem over the last couple of weeks. The amount of free space (and used space) on the Time Capsule drive is not changing. All the backups are happening as they should, but no change in free space.

I've verified all the backups are there by entering time machine and seeing the files for all dates.

I checked that it wasn't just a coincidence based on backups and then removal of old ones (thinning) by looking through the system log and it shows that after every backup and ever pre/post-thinning it always shows 803.7 GB free (actually, exactly 803.65)

I tried restarting my coputer.

I tried restarting the Time Capsule.

I upgraded the Time Capsule firmware to the latest version (7.3.2).

All without luck. Has anyone else seen this behavior or have any idea what might be going on?

MacBook, Mac OS X (10.5.4)

Posted on Jul 25, 2008 2:34 PM

Reply

Answer 1

Jul 26, 2008 10:29 AM in response to bigpond3

What kind of changes are you expecting? Unless you change a lot of files on your hard drive, very often you won't see a noticeable difference. The TC doesn't so much copy your hard drive every time, but rather makes an initial of everything and then, when some file changes somewhere, it notices and then backs that up again. It operates similar to the diff / rsync commands. I noticed that mine didn't seem to be updating but then added a few gigs of data - then it changed.

Reply

Answer 2

bigpond3 Author

Level 1

0 points

Jul 26, 2008 11:28 AM in response to Justin LaPre

Here's an example from some recent backups. This is the System.log records relating to backupd.

Jul 26 09:12:57 MosMac /System/Library/CoreServices/backupd[2121]: No pre-backup thinning needed: 100.0 MB requested (including padding), 803.65 GB available
Jul 26 09:16:29 MosMac /System/Library/CoreServices/backupd[2121]: Copied 1464 files (23.4 MB) from volume Macintosh HD.
Jul 26 09:16:29 MosMac /System/Library/CoreServices/backupd[2121]: No pre-backup thinning needed: 100.0 MB requested (including padding), 803.65 GB available
Jul 26 09:17:42 MosMac /System/Library/CoreServices/backupd[2121]: Copied 501 files (4.4 MB) from volume Macintosh HD.
Jul 26 09:18:07 MosMac /System/Library/CoreServices/backupd[2121]: Starting post-backup thinning
Jul 26 09:18:07 MosMac /System/Library/CoreServices/backupd[2121]: No post-back up thinning needed: no expired backups exist
...
Jul 26 10:13:36 MosMac /System/Library/CoreServices/backupd[2193]: No pre-backup thinning needed: 100.0 MB requested (including padding), 803.65 GB available
Jul 26 10:16:56 MosMac /System/Library/CoreServices/backupd[2193]: Copied 1599 files (15.9 MB) from volume Macintosh HD.
Jul 26 10:16:56 MosMac /System/Library/CoreServices/backupd[2193]: No pre-backup thinning needed: 100.0 MB requested (including padding), 803.65 GB available
Jul 26 10:17:50 MosMac /System/Library/CoreServices/backupd[2193]: Copied 425 files (4.2 MB) from volume Macintosh HD.
...
Jul 26 11:04:33 MosMac /System/Library/CoreServices/backupd[2349]: No pre-backup thinning needed: 100.0 MB requested (including padding), 803.65 GB available
Jul 26 11:09:18 MosMac /System/Library/CoreServices/backupd[2349]: Copied 995 files (136.6 MB) from volume Macintosh HD.
Jul 26 11:09:52 MosMac /System/Library/CoreServices/backupd[2349]: No pre-backup thinning needed: 100.0 MB requested (including padding), 803.65 GB available
Jul 26 11:10:22 MosMac /System/Library/CoreServices/backupd[2349]: Unable to rebuild path cache for source item. Partial source path:
Jul 26 11:11:31 MosMac /System/Library/CoreServices/backupd[2349]: Copied 723 files (4.6 MB) from volume Macintosh HD.

There's at least a couple hundred of MBs backed up.

Reply

Answer 3

Jul 26, 2008 6:11 PM in response to bigpond3

I believe there is certain amount of "magic™".

The actual "file" containing the backup on the TC's disk is in the form of a sparse bundle. This appears in Finder as YourMachineName_MACAddress.sparsebundle, but, being a bundle, is a disguise for a directory of the same name. This contains many 8MB files called bands that contain the actual backup data. As each band is exactly 8 MB, the total space used will grow in 8MB increments.

Further, I'm quite certain that the bundles are not necessarily 100% utilized which is a what's behind to lack of apparent growth.

If you examine the sparse bundle in Finder when it's "expanded" - that is when it appears in finder as device named backup of YourMachine name (which happens when Time Machine is backing up) you will find that the space on the disk image is smaller than the sparse bundle size. (You can also see this by clicking in Finder on the time capsule name that appears under Shared and then double clicking on the TC disk name and then double clicking on the sparse bundle name....this will take a long time but eventually the disk image will open up as Backups.backupd and under that folder with your machine name.)

For one of my systems the sparsebundle is 50.12 GB and the size of the Backups.backupd is 47.97GB. So the actual backups aren't filling all the space occupied by the sparse bundle. Since starting in April the sparse bundle for this machine has grown by less that 600MB and there is no question that more data than that has been added to the backups.

So the increasing amounts of new data backed up by Time Machine are not directly or immediately reflected in the space used on the TC disk.

Reply

Answer 4

Jul 27, 2008 4:21 AM in response to Steve Holton

I'm not the original poster, but THANK YOU so much for this explanation. It answers and clears up my confusion as explained in my thread from a day ago:

Confused about backups and TC's Sparsebundle

Reply

Answer 5

bigpond3 Author

Level 1

0 points

Jul 27, 2008 5:52 PM in response to Steve Holton

Thanks for that. I think it makes sense now. When I look at the actual sparebundle size, it's well below the amount used (total minus available) when I check it on the HD icon. So I guess it makes sense that until the sparsebundle size ramps up to fill the amount allocated I won't be seeing any changes.

Reply