A few days ago I blogged about my new M1 MacBook Pro. It's mostly been fine, but now I'm experiencing a significant problem: I can't figure out how to make a backup! I back up my home folder daily, and that continues to work as before, but I also back up the entire internal disk weekly, and that doesn't work.
With my 2014 Intel MacBook Pro, I can boot into the recovery volume, select the APFS container for the SSD, select the command "New Image from" the container, and save a new encrypted, compressed disk image to my external backup drive. This works great, extremely reliable, never fails, and takes about an hour, so I can run the backup while I'm out for errands. I don't need a bootable backup, I just need to protect against data loss, for example, when the Big Sur updater hosed my install.
With my new Apple Silicon MacBook Pro, the "New Image from" command is disabled for the internal disk container. According to Apple's support documentation, "You can’t create images of individual APFS volumes. You can’t create images of APFS containers on Mac computers with Apple silicon or an Apple T2 Security Chip." The documentation doesn't explain why, but… that sucks.
The suggested alternative is to create a "New Image from Folder". So I booted into recovery and selected the
/System/Volumes/Data folder. I decided to just back up the read-write data volume and not the read-only system volume, because I didn't really need the latter, and skipping it would save time and space. I started the backup and went outside for an hour to get some exercise. When I got home, however, the backup wasn't even close to finished. Only 50GB of the 350GB data had been saved to the new image. The other ridiculous thing is that there was no way in Disk Utility to cancel the creation process. The only way to stop it was to reboot. The user interface was still responsive — there was no hang or spinning pinwheel — the Disk Utility app just doesn't provide cancel button!
At that point I decided to do a speed test of my two MacBook Pros, Intel vs. ARM. I copied an identical multi-GB file from each MacBook Pro to my backup drive, and the copy durations were also identical, so there was no problem with that. The limiting factor is just the speed of my backup HDD. I have to use a USB-C to USB-A dongle from my new MacBook Pro, but that didn't slow down the copy speed at all. Thus, there's no hardware explanation for why it would take 7 times longer to back up my new MacBook Pro compared to my old MacBook Pro.
Today I attempted a slightly different strategy. I booted into recovery, created a new blank encrypted sparseimage with a maximum size of 400GB, and then restored the data volume into the blank image. This seemed to be progressing fine, so I went out to run some errands. When I got home an hour later, the screen was black, which is not odd, but the mouse pointer and the battery status in the menu bar were still visible, which is very odd. When I woke the screen, I discovered that the restore operation had failed. I checked the size of the sparseimage, and it was only 15GB. The error message from Disk Utility was not very informative:
Failed to create source stream for replication.
Volume replication failed - Operation not permitted
The operation couldn't be completed. (OSStatus error 1.)
I guess the next thing I'll try is to boot into recovery and run
hdiutil create -encryption -format UDZO -srcfolder /System/Volumes/Data -noatomic from Terminal to see whether that makes the backup faster than "Image from Folder". It's unacceptable to me to turn a 1 hour process into a 7 or 8 hour process.
Of course I'm aware of Time Machine, but please don't suggest that to me. Time Machine doesn't really fit my backup workflow, and I've never trusted Time Machine anyway. I'm also aware of third-party backup software, and I'm not opposed to that in principle, but I'd really like to hear an explanation of what's going wrong with my manual backups. After all, third-party software isn't magical, so the question is what if anything it's doing differently. If I don't know what's going wrong now, how can I be confident that third-party software will solve my problems? I'm appealing to the Apple Silicon and APFS experts out there for information about how this works, or is supposed to work, or isn't supposed to work. At the moment, I'm not particularly happy with Apple Silicon as the future of the Mac. Help!
I tried many different variations of arguments to the
asr command-line tool for Apple Software Restore, but every attempt failed. I ran these commands both from the recovery volume and also from the main system volume. I tried restoring from a snapshot. Nothing worked. Usually I got an undocumented error code on invoking the command.
I have found one thing that works. In Terminal, booted from recovery:hdiutil create -encryption -format UDSB -srcfolder /Volumes/Data -noatomic -noscrub
This finished in about an hour, the same amount of time as the backups from my old Intel Mac. The format
UDSB is a sparse bundle, a newer format similar to a sparse image that grows with its content, but a sparse bundle is backed by a file hierarchy on disk rather than a single file. To my surprise, I discovered that the different disk image formats have vastly different write speeds. In one test I ran with the exact same data,
UDSB was almost 4 times faster than
UDSP and an astounding 7 times faster than a standard
UDRW read-write disk image!
One problem with using sparse bundles for backups, however, is that a sparse bundle is a read-write disk image format. My intention is to archive the backups, and I never want the data to change once it's been written. So after I created the backup, I used
hdiutil convert to convert the sparsebundle into a
UDRO read-only disk image. This took at least 2 hours, which is annoying, but at least I didn't need to be booted into recovery during that time. Still, even that is not a good solution, because creating a sparsebundle and then converting it to a read-only disk image requires twice the free space on the backup disk as just creating a single backup disk image. I can delete the sparsebundle after the conversion, but the disk space is needed during the conversion. Another problem is that if I'm performing a full system backup in preparation for a macOS software update, I have to delay the update for 2 additional hours, and I wouldn't want to use the Mac during that time, otherwise any data changed during that time wouldn't be captured by the backup.
If I can convert
UDRO in 2 hours, does that mean I could just use
hdiutil create -encryption -format UDRO to create the backup in 2 hours instead of 1 hour? Bizarrely, the answer is no, not even close. When I replaced
UDRO in my command-line invocation, I found that the estimated time was about 10 hours! I decided to give up and abort this operation long before it finished.
I don't understand how creating a sparsebundle and converting to it read-only can take 3 hours, while creating a read-only disk image directly takes 10 hours. It makes no sense!
Anyway, I think my backup strategy hereafter will be to just create a sparse bundle from my Data volume, change the permissions on the backup drive so that the entire bundle hierarchy is read-only, and also make sure to to always
hdiutil attach -readonly from the backup. It's very annoying and a bit error-prone, but any other strategy would waste vast amounts of time in comparison.
In conclusion, it seems to me that Apple has totally messed up backups on Apple Silicon and made them painfully more difficult, if not impossible. More and more over time, Apple is turning the Mac into a glorified iOS device. You'd never have these specific backup problems with an iPhone, because you're simply disallowed from directly accessing the file system of an iPhone. I have to wonder if that's the eventual future of the Mac too.