How to Create and Manage APFS Snapshots Manually with tmutil
Creating, listing, mounting, and cleaning up APFS local snapshots directly — the same mechanism Time Machine uses, available for manual, ad-hoc use.
APFS snapshots aren’t exclusive to Time Machine’s automatic scheduling — tmutil also supports creating and managing them directly, useful as a quick, space-efficient safety net before a risky change, independent of your regular backup schedule.
Step 1: create a manual snapshot of the current disk state
sudo tmutil snapshot
This creates a local APFS snapshot immediately, capturing the current state of your disk — the operation completes almost instantly regardless of how much data is on the disk, since APFS snapshots are copy-on-write and don’t duplicate any data upfront.
Step 2: list existing local snapshots
tmutil listlocalsnapshots /
This shows every local snapshot currently retained, including ones created automatically by Time Machine’s normal background scheduling, not just ones you created manually.
Step 3: mount a snapshot to browse its contents directly
sudo tmutil mountsnapshot / -m /Volumes/SnapshotView
This mounts the specified snapshot as a read-only volume you can browse in Finder or Terminal, letting you inspect exactly what a file or folder looked like at that specific point in time, without needing to go through the full Time Machine restore interface.
Step 4: compare a file’s current state against the snapshot version
diff /Volumes/SnapshotView/Users/you/somefile.txt ~/somefile.txt
Useful for confirming exactly what changed in a specific file since the snapshot was taken, before deciding whether to restore it.
Step 5: unmount the snapshot when done browsing it
sudo tmutil unmountsnapshot / -m /Volumes/SnapshotView
Step 6: delete a specific snapshot manually
tmutil deletelocalsnapshots <snapshot-date>
The date argument matches the format shown in listlocalsnapshots output — useful for reclaiming space from a manual snapshot you no longer need, without waiting for macOS’s automatic thinning to eventually remove it.
Step 7: understand automatic thinning behavior
macOS automatically manages local snapshot storage under normal conditions — thinning older snapshots as disk space is needed elsewhere, without any action required from you. Manual snapshots you create are subject to this same automatic management, meaning a manually-created snapshot isn’t necessarily permanent; it’s still eligible for automatic removal under disk-space pressure, the same as an automatically-created one.
Step 8: use this as a quick pre-change safety net
sudo tmutil snapshot # immediately before a risky system change
# ... make the change ...
# if something goes wrong, mount the snapshot (Step 3) to recover
# specific files, or use Time Machine's own restore interface for
# a more complete rollback
Why this is a meaningfully lighter-weight safety net than a full backup
A manual snapshot costs essentially nothing to create and takes effect instantly, unlike waiting for or triggering a full Time Machine backup to an external destination — making it a genuinely practical “just in case” step immediately before a risky change (a system update, a risky configuration edit, a large file operation) where a few seconds of overhead is worth having a rollback point available, even though it isn’t a substitute for genuine off-disk backups protecting against actual disk failure or loss.
Step 9: the related, single-file equivalent — APFS clone files
cp -c original.psd copy-for-editing.psd
For duplicating a single large file rather than snapshotting an entire volume, cp -c creates an APFS clone file — a copy-on-write duplicate sharing the same underlying data blocks as the original until either file is actually modified, at which point only the changed blocks diverge. This is the same underlying mechanism Finder’s “Duplicate” command uses on APFS volumes, and it’s why duplicating even a multi-gigabyte file on APFS completes essentially instantly and consumes no additional disk space until you actually start editing one of the two copies — a single-file, always-writable sibling to the whole-volume, point-in-time snapshot mechanism covered in the rest of this guide.
Step 10: understand why a snapshot alone can’t protect against disk failure
A local APFS snapshot lives on the same physical disk as the data it’s a snapshot of — it protects against software mistakes, bad edits, and accidental deletions, but it disappears entirely along with everything else the instant that disk itself fails, is stolen, or is otherwise physically destroyed. This is the precise, important distinction between a snapshot and a genuine backup: Time Machine’s actual value comes from writing to a separate physical destination (an external drive, a network share), with local snapshots serving as a fast, space-efficient bridge between those less-frequent off-disk backups — not a replacement for having an off-disk copy at all. Treating a snapshot as sufficient insurance on its own, rather than as a convenient supplement to real backups, is a mistake that only becomes obvious — usually far too late to matter — the moment the disk itself is the thing that actually fails rather than something more forgiving, like a mistaken edit or an accidental deletion the local snapshot could have recovered cleanly on its own.
Related:
- APFS Explained: Snapshots, Clones, and Space Sharing in Apple’s Filesystem
- Managing Time Machine From the Command Line with tmutil
Sources: