An APFS snapshot is a read-only, point-in-time image of an APFS volume that the Apple File System creates almost instantly by preserving references to existing data blocks instead of copying them. In macOS storage & backup, snapshots underpin Time Machine local snapshots, safe system updates and the sealed system volume that macOS boots from.
A snapshot initially takes almost no extra space. It grows only as files on the live volume change, because the blocks it references can no longer be reused. That makes snapshots cheap to create and quick to restore from, but also explains why they can quietly hold large amounts of disk space until macOS removes them.
How copy-on-write makes snapshots possible
APFS is a copy-on-write file system: when a file is modified, the new data is written to free blocks and the metadata is updated to point at them, while the old blocks are released. A snapshot simply marks the current set of metadata and blocks as retained, so the old blocks are not released when the live volume changes.
Creating a snapshot therefore takes a fraction of a second regardless of volume size. Reading from it shows the volume exactly as it was at that moment. The cost appears later: every block that is changed or deleted after the snapshot stays allocated, so the snapshot’s footprint equals the amount of data changed since it was taken, not the size of the volume.
Snapshots are per volume, not per container. A snapshot of the Data volume captures user files and apps, while the System volume has its own sealed snapshot. Multiple snapshots of the same volume share any unchanged blocks between them.
Where macOS uses APFS snapshots
macOS relies on snapshots in several places, most of them invisible to the user. The table summarizes the main uses and their typical lifetime.
| Use | Created by | Typical lifetime |
|---|---|---|
| Time Machine local snapshot | Time Machine, about every hour | Around 24 hours |
| Backup source snapshot | Time Machine before each backup | Until the backup completes |
| Backup destination snapshots | Time Machine on an APFS backup disk | Hourly, daily and weekly retention |
| Signed System Volume snapshot | macOS installer and updater | Until the next system update |
| Third-party backup snapshot | Backup and cloning tools | Depends on the tool |
Since macOS Big Sur, the Mac boots from a cryptographically sealed snapshot of the System volume rather than from the volume itself. Each update builds a new system snapshot, verifies its seal and switches to it, which allows a clean return to the previous state if the update fails.
Managing local snapshots
Local snapshots are usually managed automatically, but Terminal commands give full control. The table lists the most useful ones; dates in snapshot names follow the format YYYY-MM-DD-HHMMSS.
| Command | Purpose | Notes |
|---|---|---|
tmutil listlocalsnapshots / | List Time Machine local snapshots | Shows snapshot dates |
tmutil localsnapshot | Create a snapshot now | Useful before risky changes |
tmutil deletelocalsnapshots <date> | Delete one snapshot | Frees its retained space |
tmutil thinlocalsnapshots / <bytes> 4 | Ask macOS to free space | Removes older snapshots first |
diskutil apfs listSnapshots / | List all snapshots on the volume | Includes non-Time Machine snapshots |
Disk Utility also displays snapshots for a selected volume when Show APFS Snapshots is enabled in the View menu, and it can delete them there. Restoring from a local snapshot is done through the Time Machine browser for individual files, or through macOS Recovery for a whole volume.
Snapshots compared with other backup methods
A local snapshot is not a backup in the full sense, because it lives on the same physical disk as the original data. If the SSD fails or the Mac is lost, every snapshot disappears with it. The comparison shows where snapshots fit.
| Method | Location | Protects against | Does not protect against |
|---|---|---|---|
| APFS local snapshot | Same volume | Accidental deletion, bad edits, failed updates | Disk failure, theft, fire |
| Time Machine backup | External or network disk | Disk failure and most data loss | Disaster at the same site |
| Bootable clone | Separate disk | Quick recovery of a full system | Changes after the clone date |
| Cloud sync | Online service | Device loss for synced files | Synced deletions and corruption |
A practical rule is to treat snapshots as a fast undo layer on top of real backups. They answer the question of how to roll back the last few hours quickly, while external and offsite copies answer how to survive the loss of the machine.
Snapshots and disk space
Space held by Time Machine local snapshots is reported as purgeable space. macOS removes these snapshots automatically when free space runs low, generally keeping a margin of free space and deleting the oldest snapshots first. Large downloads or app installs therefore succeed even when the Finder shows little free space.
- Unexpectedly low free space often comes from snapshots retaining recently deleted large files, such as video projects or virtual machine images.
- Snapshots from third-party tools are not always treated as purgeable and may need to be deleted manually.
- Storage reports differ between the Finder, About This Mac and Disk Utility because they treat purgeable space differently.
- Deleting a file does not free space while a snapshot still references its blocks.
The idea in brief
An APFS snapshot is like a photograph of the Mac’s disk at one moment. Taking the photograph is instant and costs almost no space, because the Mac simply promises not to throw away the old versions of files that the photograph shows.
If something goes wrong later, the Mac can look back at that photograph to recover a file or undo a failed update. The catch is that the photograph sits on the same disk. It helps with mistakes, but it does not replace a real backup on another drive.
A practical scenario
A designer works on a MacBook with a 512 GB SSD and Time Machine backing up to an external drive at the office. Working from home one afternoon, the designer accidentally overwrites a layered project file with a flattened version and then empties the Trash. The external backup drive is not connected.
Because Time Machine keeps hourly local snapshots on the internal SSD, the designer opens the Time Machine browser, goes back two hours and restores the original project file in less than a minute. Later that week, Finder shows only 20 GB free after a large video project was deleted. Running tmutil listlocalsnapshots / shows several snapshots still referencing the old video files; macOS purges them automatically when a new download needs the space, and free space returns to about 140 GB.