Backing Up Cloned APFS Files
QThere are cases where we can’t make an exact copy of your APFS volume. And Time Machine can’t either. Nothing can.
[…]
The reason is there’s no (public) way to find out that two files are actually sharing the same data (they might even only be sharing some of the same data, as I explain above). So, when copied, the “clone” relationship is broken, as is the ten-pounds-of-shit-in-a-five-pound-bag magic. You now have a full ten pounds. It doesn’t fit…so you end up covered in shit.
[…]
Time Machine does seem to be able to determine if two files are clones (which I assume it’s doing with private APIs, because I can’t find any documented APIs to determine if two files are clones). When it backs up cloned files, it uses hard links to represent them (since HFS+ doesn’t support clones, and Time Machine can only back up to HFS+ volumes), and when it restores, it checks to see if those files are clones (which it tracks in a special database), and restores them as clones to APFS…unless they’re restored to an HFS+ volume, where all bets are off.
But even in the best case, restoring to APFS, when files get ‘separated’ when they’re changed, again, only the part of the file that was changed is separate. The other blocks are still shared. So even though they’ve jumped through hoops to maintain the clone relationship, there are lots of cases where Time Machine’s own copies will increase in size too, and it happens more and more as the files diverge further.
[…]
What does this mean for you? It means you can get in cases where data that fits on a source drive won’t fit on a destination, even when the drives are exactly the same size.
Previously: SuperDuper and APFS.
Update (2017-10-29): See also: Howard Oakley.
