macOS Workflow

Time Machine on the Internal Drive

How to set up a Time Machine backup on the same internal drive for fast local recovery of accidental deletions, and the surprisingly annoying process of getting macOS to accept it.

When I ordered my MacBook, I went with 4 TB of internal storage. Not because I needed it all for daily use — I deliberately wanted the extra space for a local Time Machine partition. The idea: carve off 2 TB and use it as a fast recovery layer for things that live outside my git repos. Documents, design files, configuration, notes — stuff that doesn’t get version-controlled but would still hurt to lose.

I have real backups — cloud storage and a local NAS. But restoring from those takes time, and requires network access. A same-disk Time Machine volume gives me instant recovery when I accidentally delete or overwrite something — even offline, sitting in a cafe or wherever. Not on a train though — the German rail system is so dysfunctional I gave up on trains entirely.

Simple plan. Getting macOS to cooperate was the annoying part.

The GUI says no

I created an APFS volume called “TM Backup” on the internal drive, encrypted it with FileVault, and opened Time Machine settings. The volume wasn’t listed as an available destination.

This is intentional. macOS hides volumes that live in the same APFS container as your boot volume. The reasoning is sound — if the drive dies, you lose both your data and your backup. Apple doesn’t want you to think you’re protected when you’re not.

Fair enough. But I wasn’t going for disaster recovery. I just wanted a local undo buffer for non-git files.

Forcing it with tmutil

If the GUI won’t let you, the command line usually will:

sudo tmutil setdestination /Volumes/TM\ Backup

Except it didn’t work:

/Volumes/TM Backup: The operation couldn't be completed. (OSStatus error 49229.)

Chasing the wrong fix

My first instinct was the volume role. Modern macOS wants Time Machine destinations to have a specific APFS “Backup” role. So I tried setting it:

sudo diskutil apfs changeVolumeRole disk3s9 B

Where disk3s9 is the volume identifier (find yours with diskutil list) and B stands for Backup.

No luck:

Error setting APFS Volume role: Unable to set the APFS Volume Role (-69599)

Tried unmounting the volume first, then setting the role. Same error. Fine — I’ll just recreate the volume with the role baked in:

sudo diskutil apfs addVolume disk3 APFS "TM Backup" -role B -quota 2000000000000

Error: -69624: Unable to add a new APFS Volume to an APFS Container

The -role B flag just refused to work, no matter what I tried. Dead end.

The actual problem: encryption

After going in circles with the volume role, I stepped back and tried the simplest thing — recreate the volume without encryption and without the -role B flag:

sudo diskutil apfs addVolume disk3 APFS "TM Backup" \
  -quota 2000000000000 \
  -reserve 2000000000000

The flags:

  • -quota 2000000000000 caps the volume at 2 TB so Time Machine can’t grow into space the system needs
  • -reserve 2000000000000 guarantees 2 TB for this volume — other volumes in the container can’t consume it

Then tried tmutil again:

sudo tmutil setdestination /Volumes/TM\ Backup

It went through. No error. So the -role B was a red herring — the encryption was blocking tmutil all along.

Encrypting after the fact

I still wanted the volume encrypted. FileVault protects the boot volume, but other APFS volumes in the same container aren’t automatically covered. On modern MacBooks the SSD is soldered and the Secure Enclave adds another layer, so the risk is theoretical — but I’d rather not leave a volume full of personal files unencrypted on principle.

The trick: encrypt the volume after setting it as the Time Machine destination. macOS is fine with that — it’s only the initial tmutil setdestination that chokes on an already-encrypted volume.

Verified everything works:

tmutil destinationinfo

====================================================
Name          : TM Backup
Kind          : Local
Mount Point   : /Volumes/TM Backup
ID            : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Quick reference

The full sequence from a clean slate:

# Create a 2 TB APFS volume (unencrypted for now)
sudo diskutil apfs addVolume disk3 APFS "TM Backup" \
  -quota 2000000000000 \
  -reserve 2000000000000

# Set it as the Time Machine destination
sudo tmutil setdestination /Volumes/TM\ Backup

# Now encrypt it
diskutil apfs encryptVolume disk3s9

# Verify
tmutil destinationinfo

# Kick off the first backup
tmutil startbackup

Replace disk3 and disk3s9 with your APFS container and volume identifiers. Find them with diskutil list.

What this is and isn’t

This setup protects against accidental file deletion and software mishaps. If I delete a document I shouldn’t have, or a bad update wipes a config file, I can recover it from Time Machine in seconds. Fast, local, no network required.

It does not protect against drive failure. If the physical drive dies, both my data and this Time Machine volume go with it. That’s what cloud backups and the NAS are for. Different failure modes, different recovery strategies. And for code, there’s git.

Not every backup needs to be a disaster recovery plan. Sometimes you just want an undo button that goes back further than Command-Z.