Recently, my SSD started failing. That's a usual fact with SSD and I was prepared for it, or I thought I was. I got a replacement Intel SSD from amazon which was advertised as 240GB rather than 256GB. I originally thought that this was due to formatting (GiB vs GB) but it turns out it is actually smaller.

I put in the Macbook Pro, launched Internet Recovery (boot with cmd-R) and selected "restore from time machine". Unfortunately, the system complained that my destination drive didn't have enough space.

I embarked upon a day-long quest to start to remove things that bloated the Time Machine backup, for example, backups of Google Chrome (which I can download), and my iPhoto Library (which I have backed-up elsewhere too). I was too distracted by this painful procedure to realise that nothing I did had any effect - the restore system always complained about the target disk being smaller.

Given that it didn't spend a huge amount of time calculating the actual size of the backups, I felt that the size information was stored somewhere and wasn't updated. In now obvious retrospect, I used the xattr utility to examine the metadata of various things on the TimeMachine backups. Lo and behold:

orestis-edm-mini:swarthy sor$ xattr -l 2012-11-19-004303/M4_256/
com.apple.backupd.SnapshotVolumeFSEventStoreUUID:
00000000  45 41 39 39 45 39 38 44 2D 39 34 44 41 2D 34 34  |EA99E98D-94DA-44|
00000010  38 46 2D 42 34 37 42 2D 44 33 31 38 30 36 36 33  |8F-B47B-D3180663|
00000020  45 33 46 38 00                                   |E3F8.|
00000025
com.apple.backupd.SnapshotVolumeLastFSEventID:
00000000  35 33 31 30 36 34 35 39 00                       |53106459.|
00000009
com.apple.backupd.SnapshotVolumeUUID:
00000000  33 37 33 31 35 37 46 43 2D 33 45 43 39 2D 33 38  |373157FC-3EC9-38|
00000010  42 32 2D 38 43 35 41 2D 45 33 45 42 31 43 33 32  |B2-8C5A-E3EB1C32|
00000020  42 38 34 35 00                                   |B845.|
00000025
com.apple.backupd.VolumeBytesUsed: 232715759616
com.apple.backupd.VolumeIsCaseSensitive: 0
com.apple.metadata:_kTimeMachineNewestSnapshot:
00000000  62 70 6C 69 73 74 30 30 33 41 B6 59 AA 07 00 00  |bplist003A.Y....|
00000010  00 08 00 00 00 00 00 00 01 01 00 00 00 00 00 00  |................|
00000020  00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000030  00 11                                            |..|
00000032
com.apple.metadata:_kTimeMachineOldestSnapshot:
00000000  62 70 6C 69 73 74 30 30 33 41 B6 59 A9 3B 00 00  |bplist003A.Y.;..|
00000010  00 08 00 00 00 00 00 00 01 01 00 00 00 00 00 00  |................|
00000020  00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000030  00 11                                            |..|
00000032

Among other things, there's an obvious "VolumeBytesUsed", that obviously isn't being updated when I trimmed down various files from inside the TimeMachine interface. After issuing xattr -w com.apple.backupd.VolumeBytesUsed 219637221376 2012-12-10-142137/M4_256/, the restore interface happily accepted my latest backup. It's now restoring the backup as we speak, and I will update this post once I see some results.

In conclusion, I really need to have a bootable SuperDuper backup to streamline this kind of restore. On the other hand, if an SSD drive starts failing, and it silently corrupts data, can we even trust backups?

December 13, 2012, 9:39 a.m. More (532 words) 1 comment Feed
Previous entry: EuroPython 2011 impressions
Next entry: WSGI, Twisted and Server Sent Events

Comments

1

Comment by Pol , 1 year, 9 months ago :

I am having a similar problem, did you finally succeed?


This post is older than 30 days and comments have been turned off.