How to save data from a time machine backup that has gone bad

Question

My 3TB USB disk I use as my Time Machine target has gone bad. I can mount it read only but no set of options I've tried allow me to mount it read/write.

The fsck tells me that the catalog btree is bad and I can not repair it because there is not enough space left on the disk to allocate a new btree (these are messages I get from fsck_hfs).

The Apple support article says to just open the volume in the finder and copy the Backups.backupdb to a new drive. When I try that, the "preparing to copy" dialog comes up. After 26 hours, it is at 3.8 million files but it has stopped moving. My fear is the btree is in a circular loop and it got stuck -- maybe?

When I try to copy the old volume to a new volume using ditto, I get lots of errors about "Operation not permitted". I believe the time machine disk has some fairly unique directory structures and I guess ditto doesn't know how to recreate them properly?

I thought about using ditto and create a big cpio file but then what would I do to restore it? I assume I would get the same errors. And, I also have the fear that if the directory structure is really goofed up, it might not ever finish.

To be honest, this is not a tragic loss. I could just reformat the drive and start fresh with backups and give up all of the historical data which, 99.99 chances out of 100 I would never want. So, this is a bit of an opportunity to poke at it and see if I can find a way to recover the drive without any huge heartbreak if I destroy the file system mucking with it. Or, I could just retire the drive and if I really really really need something off of it, I could mount it and pull just that piece off.

Another possibility is to write a program to traverse the tree keeping track of the inodes. For each unique inode of a regular file, copy that file to the new disk using an inode unique path. For each repeat inode, don't go down into the tree. Also, in to a separate file, record the paths to get to an inode. The big ICK there is all the extended attributes and ACLs that Apple / HFS has. I don't know how to get the complete set of these things. Is there more than just ACLs and extended attributes? Perhaps such a critter already exists.

Answer 1

I am simply going for an answer with this because I believe it is the only one.

First of all don't use Finder. If you do, don't copy it all because Finder does not understand what a hard link is.

If you would like to keep the data in sort of the same structure you can use rsync with a version number greater 3. Not the version supplied by Apple. With that you would be able to copy the volume including hardlinks while preserving xattrs and permissions. With one caveat. Not the ownership because that is set to nobody right now.

Tmutil keeps track of it and you can inherit them on another machine/installation. But restoring seems (as far as my research has lead me) also to be limited to tmutil. While I am sure that there are certainly commands that would do this at will they are not documented in

man tmutil

In order to get all data off you will have to run rsync as root. Which will then be the owner afterwards. Alternatively it will set them back to how they were but at nobody as the owner isn't that useful either. The rsync route would allow you to only copy the files that actually exist if you choose to preserve hardlinks. The resulting data set would be about the same size, should be identical in properties with the only difference being that the folders are now not hard-linked. Only the files are.

Personally I would be interested in trying to ask tmutil afterwards to adopt this data set. In any case you will then be able to browse the data freely.

If you just wan't to get all the unique data that is on the time machine disk you can ask fdupes to list hard-links as duplicates (it has a switch for that) and then have them deleted. This should leave you with one unique set. There will still be loads of files that are practically identical but not actually bit for bit. So it might be still messy.

I have gone trough something similar myself. Basically Time Machine should either you once your backup has reached a certain age and tell you to start over. Because it is impossible to restore a working installation from a time machine backup that is a couple of months old (depends on usage, obviously). It simply becomes a really fragmented mess if it has to keep track of millions of files in order to create the consistent set at point X in time. The alternative would be to reconsolidate the sets permanently but that would mean that the resource usage of Time Machine would go up. For mobile computers that would also be unpractical since the disk would need to be connected for extended periods of time. If you like the idea that you can reinstall your computer to the state it was 1h ago before you installed "xy" or did some "rm"ing on something that seemed useless you better keep only 2 or 3 months worth of time machine around (again, depends on usage). Or start using rsync and multiple targets, either with a self written solution or with one of the commercial wrappers around it. Separating the Backup strategy for stored data and working data also helps.

If now someone will turn up an say that using something like ZFS Snapshots would be better then I can only recommend to test that for a couple of weeks and not just blabber on what is written on the internet. This does need considerably more resources to the time machine solution. If it is used for files that change a lot you either end up with pretty gigantic snapshots and are running out of disk space which won't be restored if you delete the snapshots in between. If you even can delete them, which is unlikely. Which only leaves you with the option to delete the oldest ones frequently but in that case Time Machine works absolutely fine as well. From my experience even better. Deduplications would need a very fine graded adjustment since so many files are altered every couple of minutes on OSX but are still kept for years. Incremental backups over a long time seem so of alluring but in practise that might not be the best approach.