An APFS local snapshot and a backup sound like the same idea. They are not, and mixing them up is how people lose data they thought was protected. A snapshot is a point-in-time reference to your disk's own state, stored on the same disk. A backup is a separate copy, stored somewhere else. Time Machine uses snapshots constantly, in the background, without asking, which is exactly why the distinction gets blurred. This article explains what a snapshot is at the filesystem level, how Time Machine uses them, why they cannot substitute for a real backup, and the two tmutil commands you need if you ever want to inspect or remove one yourself.
What an APFS snapshot actually is
APFS is a copy-on-write filesystem. When you change a file, APFS does not overwrite the old blocks in place; it writes new blocks and updates the metadata to point at them. A snapshot is simply a frozen record of what that metadata looked like at one moment — which blocks belonged to which files, at that instant.
Because of copy-on-write, taking a snapshot costs almost nothing at the moment it is created. No data is duplicated. The snapshot just holds a reference to the current arrangement of blocks. The cost appears later: as you keep working and the live filesystem changes, the old blocks that the snapshot still points to cannot be reused or freed until the snapshot is deleted. A snapshot that sits around for weeks on an active volume can end up "holding open" a meaningful amount of space, all attributed to the same physical disk it started on.
This is also why snapshots are fast to create and fast to delete, but not free to keep. They are a filesystem bookkeeping trick, not a copy.
How Time Machine uses local snapshots
Time Machine takes local snapshots on your internal disk between its real backups to an external drive or network destination. If your backup disk is not connected, macOS still keeps taking these local snapshots on a schedule, so that when you do reconnect the drive, Time Machine can compute the difference and back up only what changed.
This is a genuinely useful mechanism. It lets you browse "how this folder looked yesterday" using Time Machine's interface even without an external drive attached, because the snapshot on the internal disk still has that historical state available. macOS also manages the snapshot lifecycle itself, aging out old ones as space pressure increases or as real backups complete and make them redundant.
The part that trips people up is that this internal mechanism looks and feels like a backup is happening, because Time Machine's UI and terminology don't clearly separate "I have a local snapshot" from "I have your data backed up somewhere else." They are very different guarantees.
Why a snapshot is not a backup
A backup is defined by where it lives: somewhere that can survive the failure or loss of the original. A snapshot lives on the exact same physical disk as the data it describes. If that disk fails — a dead SSD controller, corrupted firmware, a laptop that gets stolen — the snapshot fails with it. There is no scenario in which an APFS local snapshot alone protects you from disk loss, theft, fire, or ransomware that touches the whole disk.
Snapshots also don't protect against every kind of software mistake. If a filesystem-level bug corrupts metadata, a snapshot describing that same metadata may be affected too. This is a narrower risk than physical loss, but it is another reason not to treat "there's a snapshot" as equivalent to "there's a backup."
What snapshots are genuinely good for is a narrow, useful category of accidents: you deleted a file an hour ago and want it back, or you want to see what a document looked like before your last edit, and your Time Machine drive is not currently plugged in. For anything wider than that — the disk itself failing, or the whole Mac being lost — you need a copy that exists on a different piece of physical hardware.
Listing and deleting snapshots with tmutil
You can inspect the snapshots currently held on your boot volume from Terminal:
tmutil listlocalsnapshots /
This prints the identifiers of each local snapshot, typically a date and timestamp. If you want to reclaim the space one is holding — for example, if you know a large amount of data changed recently and an old snapshot is pinning the previous blocks — you can delete a specific one by its identifier:
sudo tmutil deletelocalsnapshots 2026-08-10-093000
You rarely need to do this manually. macOS manages snapshot lifecycle on its own, deleting older ones under disk pressure or once a real Time Machine backup makes them unnecessary. Manual deletion is mainly useful when you are diagnosing exactly what is consuming purgeable space on a nearly full disk and want to confirm a snapshot is the cause before doing anything else.
Why off-device backups still matter regardless
None of this is an argument against Time Machine or local snapshots — they are a genuinely useful safety net for the kind of quick "I need that file from an hour ago" recovery that happens far more often than a full disk failure. The point is narrower: a local snapshot answers "can I get back to an earlier state on this same disk," and a backup answers "can I recover if this disk is gone." Both questions matter, and only one of them is answered by anything living on the same physical drive as your data.
A sound setup keeps at least one backup destination that is physically separate from your Mac's internal disk — an external drive kept in a different location, or a cloud backup service — in addition to whatever local snapshot behaviour Time Machine is doing automatically. If you only have local snapshots and no external or cloud copy, you have convenience, not resilience.
Conclusion
The confusion between snapshots and backups is understandable, because Time Machine deliberately blends the two ideas into one interface. But the underlying mechanics are simple once you see them: a snapshot is metadata living on the same disk, cheap to make and useful for short-term recovery; a backup is a separate copy on separate hardware, and it is the only thing that survives the loss of the original disk. Keep both, and know which one you're relying on when something goes wrong.
Storage tools like VolumeLens live on the "understand what's on this disk" side of this problem rather than the backup side — helping you see what's actually consuming space, including purgeable space held by snapshots, so you can make an informed decision about what to back up in the first place and what's safe to leave behind.