← Field Notes
Storage · Deep dive

Apple's macOS 28 deprecation leaves encrypted Time Machine disks without a migration

R Rob Flanagan · · 7 min read

Two documented remedies, and the same sentence removes both of them from backup disks. The old history does not come with you, and Apple never says it does.

The macOS Tahoe 26.6 release notes carry one line that ends a backup lineage, and it is filed under a deprecations heading rather than announced:

Encrypted HFS+ (CoreStorage) is deprecated and will not be supported in macOS 28.Apple, macOS Tahoe 26.6 release notes

Read the scope before the consequence. This is the part that gets garbled in every retelling. The deprecation is about encryption, not about the format. Apple's support article says plainly that "macOS 28 and later will continue to support unencrypted volumes that use Mac OS Extended format." An APFS Encrypted destination needs nothing. An encrypted disk image or a NAS sparsebundle is not a CoreStorage volume. What is in scope is narrow: a whole volume encrypted through CoreStorage, formatted Mac OS Extended, and used as a Time Machine destination.

For that specific disk, Apple documents no way forward that keeps the history.

Two non-destructive remedies, and the sentence that removes both

Apple's support article documents three actions for an encrypted Mac OS Extended volume, and two of them keep what is on the disk. The first is conversion: open Disk Utility, and "from the Edit menu in the menu bar, choose Convert to APFS, then click Convert to confirm." The second is decryption from Finder, after which "the volume will still use Mac OS Extended format, but won't be encrypted". On an ordinary volume that is a real fix, because unencrypted Mac OS Extended survives into macOS 28. The third action is erasing and reformatting, which Apple describes in the same breath as deleting everything; it comes up in the next section.

Under each of those two headings, Apple prints the same sentence:

This solution doesn't apply to encrypted Time Machine backup disks.Apple Support, support for encrypted Mac OS Extended disks in macOS 28 or later

It appears twice on the page, once per remedy. Worth being exact about the verb, because I have seen this written up as a warning that conversion is risky or likely to fail. That is not what Apple said. Apple did not describe a conversion that might not work. Apple excluded the backup-disk case from the procedure altogether, and the difference matters when you are the person who has to explain to a user why their disk is being retired.

What Apple does document, and what it costs

Strip the excluded paths out and two documented options remain, both of which break the chain.

PathApple's wordingWhat carries forward
Convert to encrypted APFSExcluded for Time Machine backup disksn/a
Decrypt the volumeExcluded for Time Machine backup disksn/a
Erase and reformat as APFS or APFS (Encrypted)"This permanently deletes all data on the volume, but ensures future macOS compatibility"Nothing. The history on that disk is gone
Start a new destination"Begin backing up to encrypted APFS-formatted external drives instead"Nothing into the new lineage. The old history stays on the old disk, untouched

The difference between those last two rows is the whole decision. Erasing destroys the history; starting elsewhere leaves it sitting on a disk that macOS 28 does not support as an encrypted HFS+ volume. Neither one moves it.

"Instead" is Apple's word, not mine. The release notes tell you to begin backing up somewhere else. They do not say the existing history follows you there, and no reviewed Apple source says it does.

The two formats do not describe history the same way

This is the mechanical reason a migration would be hard even if someone wanted to build one. Worth knowing before you promise anyone a conversion.

Apple's retired APFS guide states that "directory hard links are not supported by Apple File System," and that on conversion from HFS+ they are "converted to symbolic links or aliases." Directory hard links are the trick classic Time Machine used to make each backup look like a full copy of the disk while storing only what changed.

The tmutil manual then describes two genuinely different on-disk representations. An HFS+ backup disk has a backup store, defined as "the top-level Backups.backupdb directory at the root of an HFS+ backup disk." An APFS backup disk does not: the manual's own note reads "n.b. APFS backup disks do not have backup stores," and a backup there is a volume snapshot instead.

So the old history is a directory tree held together by a filesystem feature the new filesystem does not have, and the new history is a snapshot. Apple documents neither a conversion between the two nor a tool that performs one.

One honest caveat, because a tmutil-literate admin will reach for it: inheritbackup and associatedisk do carry an existing history forward. They reassign ownership of a backup to a different Mac, and re-bind a volume's store. Neither converts an HFS+ history into APFS snapshot form. They are the right answer to a different question.

Auditing the exposure without overstating it

Here is where Mac admins can do useful work, and also where it is easy to write a script that lies to you. Apple says a directly attached external disk "is the most common Time Machine setup," but that is a statement about topology. It establishes nothing about how many managed Macs still run encrypted HFS+, and I am not going to pretend otherwise. This is a remediation gap with a deadline, not a fleet-wide incident.

I would report three states and refuse to collapse them into one:

  1. Verified affected. The destination volume is attached, is CoreStorage, is Mac OS Extended, and is encrypted. diskutil cs list is the documented way in; Apple names it in the decryption procedure, and diskutil(8) documents cs as the CoreStorage verb alias. Confirm encryption explicitly, because CoreStorage is not a synonym for it. diskutil(8) also documents Fusion and other non-encrypted CoreStorage logical volumes, so a CoreStorage hit alone is not a finding.
  2. Configured but detached. tmutil destinationinfo -X prints the destinations configured for use with Time Machine. A destination that is not plugged in cannot have its filesystem or encryption state read, because the device is absent. One inventory pass cannot prove a negative here, and a script that reports "clean" for a disk that is merely in a drawer is worse than no script.
  3. Not placed in scope by this evidence. Ordinary SMB and NAS destinations. Apple documents those as separate topologies from direct attachment. Two things do not get filed here, though: a destination hosted by another Mac needs any directly attached destination volume checked on that Mac, and a disk image is its own layer. The hdiutil manual is blunt that "many common uses of disk images blur the distinction between the disk image container and its content, but this distinction is critical." Encryption on the container is not CoreStorage on a volume.

The wording of that third state is careful on purpose. I am not telling you network destinations are safe. I am telling you this evidence does not reach them.

What I would actually do

Once a disk is verified affected: stand up a new APFS Encrypted destination. Moving the destination is Apple's instruction, in Apple's words, to "begin backing up to encrypted APFS-formatted external drives instead."

I would go further than that sentence does, and I want the seam visible. Apple says begin; I would want the first full backup finished before the macOS 28 upgrade. That completion, and that timing, are mine. Apple does not state either one, and a destination that has begun backing up is not yet a destination you can restore from.

If policy requires the old history, and in a regulated environment it sometimes does, I would preserve the disk as legacy recovery media and validate a restore from it on a pre-macOS-28 Mac before that Mac upgrades. Label that clearly: it is my operational recommendation, not Apple guidance. A restore path you have never exercised is a belief. Exercise it while a Mac that can still read the disk is in front of you.

Deprecations run on a slower clock than a CVE, and the cost lands on whoever is holding the disk on upgrade day. This one arrived in release notes rather than a bulletin, which is the ordinary way these things arrive, and is the same argument for reading the release notes properly that I have made before.

The question worth asking about your own fleet is not whether you can migrate those disks. It is whether you were treating them as active backup infrastructure or as legacy recovery media with a retirement date you set.

Sources

Primary sources, retrieved 2026-07-28 and re-fetched live on 2026-08-10. Local manual pages were read on macOS 15.4.1 build 24E263:

← Back to Field Notes