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.
Possible solution 1:
Instead of following Apple's recommendation of copying the backup in the Finder, you might want to try to use Disk Utility to restore the disk to the new disk (if the new disk is completely empty).
Possible solution 2:
Follow these instructions to make sure that MAC Address and UUID match. I have successfully used this solution in a slightly different scenario, namely to change my backup computer identification so I could keep a backup of a certain state of my computer that would not be deleted when old backups are deleted. It should also work the other way around.
Best Answer