asr is reportedly unreliable for this task. ![]() As predicted, the copied version took up twice the space, and the inodes of the subfolders of each set did not match as they had in the original, as shown above. To be sure, I copied a small backup set with two snapshots from one disk to another using the flags -aHAXENxv -fileflags -inplace to preserve as much as possible. rsync preserves hard links when using -H, but this only applies to files.ditto man page: “ditto preserves file hard links (but not directory hard links)…”.cp man page: “Note that cp copies hard-linked files as separate files.”.% ls -li /Volumes/Time\ Machine\ Backups/Backups.backupdb/MacBook\ Pro/-112359/Macintosh\ HD\ -\ DataĢ51408 5 root admin 238 23 Dec 09:59 ApplicationsĢ57836 61 root wheel 2108 1 Sep 17:25 Libraryģ68161 2 root wheel 68 23 Dec 10:05 Volumesģ68165 6 root wheel 204 26 Jul 17:58 privateįor copying hard-linked directories, these tools are confirmed not to work: % ls -li /Volumes/1TB\ External/Backups.backupdb/MacBook\ Pro/-112359/Macintosh\ HD\ -\ Dataġ57335 62 root wheel 2108 1 Sep 17:25 Libraryġ57462 6 root wheel 204 26 Jul 17:58 privateīut when copied incorrectly, they’re all given distinct numbers: Note how on the source disk, most of the top-level inode numbers stay the same between backups: ![]() The simplest indicator of a directory being hard-linked is different paths having the same inode number, as shown by ls -li. Presumably Time Machine used HFSX to ensure compatibility for the narrow set of users who use that on their internal drives, but since Time Machine has no problem copying from HFS to HFSX, why the Finder won’t let us also do so in this case is a mystery.Ĭan we just use the command line to copy the data, you might ask? Not so fast: Time Machine on HFS relies on hard-linked directories, a concept so volatile that they can only be created with a system call, and therefore so rare that command line utilities don’t copy them correctly. The system protects Time Machine backups with the TMSafetyNet.kext mechanism, so clearing off the disk image requires using either tmutil delete Backups.backupdb or running rm -rf Backups.backupdb through its bypass command, located in /System/Library/Extensions/TMSafetyNet.kext/Contents/Helpers/bypass.īecause the disk image’s mounted volume (named “Time Machine Backups”) is formatted as case-sensitive HFS (“HFSX”), attempting to copy Backups.backupdb with the Finder will throw this error: “The volume has the wrong case sensitivity for a backup”. ![]() If you actually try this though, you’re likely to run into at least one of these issues: HFS backups (macOS 10.x)Ī common suggestion for creating the disk image is to add the network drive as a new backup destination, stop the backup once the disk image has been created, then manually mount the image and replace its Backups.backupdb folder with the one from your local drive. The main problem is that there’s no official way to preserve your existing backups when making this type of destination switch, so we need to improvise - and it quickly became apparent that many of the suggestions on how to do so are either outdated or don’t fully understand the situation. ![]() In wanting to move my Time Machine backups to a network drive without losing any history, I set to looking up what methods others had used and what quirks to watch out for.īackups made by Time Machine to a local disk are simply stored in a Backups.backupdb folder on the disk, while backups to a network drive are stored in said folder within a sparsebundle disk image, since Time Machine relies on specific features of HFS or APFS.
0 Comments
Leave a Reply. |