Deleting Time Machine backups: which old ones are safe to remove
The backup disk is nearly full, the oldest backup on it is from two years ago, and dragging a folder called 2024-03-11-014522 to the Trash looks like it should work. It does not, or it half works and leaves the disk in a state Time Machine refuses to write to. The forum threads that come up for this question disagree with each other, mostly because they are answering four different questions at once.
Before anything gets deleted, it is worth separating those four questions. They live in different places, they are removed by different commands, and only one of them reliably frees a useful amount of space.
Four different things get called a Time Machine backup
The word backup covers four separate objects, and the right action is different for each one.
| What it is | Where it lives | What removing it gives back |
|---|---|---|
| Local snapshot | The internal disk, alongside the original files | Space on the startup disk, usually within 24 hours anyway |
| One dated backup | The backup disk | Only the data unique to that date, which is often very little |
| A machine directory | The backup disk, one per Mac | Everything belonging to one computer |
| The whole backup history | The backup disk | All of it, and all restore points with it |
The dated folders visible in the Finder are the second kind. They look like independent copies of the whole Mac because each one contains a full directory tree, but on both supported formats the unchanged files inside them are shared with their neighbours. That is why the first backup takes hours and the next one takes minutes.
Apple states the sharing behaviour plainly on the page about running out of room.
Your first Time Machine backup includes everything on your Mac. After that, Time Machine finds and saves only new and changed items, so the backups become smaller. Source: support.apple.com, read September 28, 2026
The practical consequence is the point of this whole article. Deleting a backup from March 2024 does not remove a March 2024 copy of the Mac. It removes only the handful of files that exist in March 2024 and nowhere else.
macOS already deletes old backups, and it is better at it
Automatic thinning is not a fallback that runs when the disk is full. It runs continuously, and it is the reason a 2 TB disk holds years of history.
If your backup disk runs low on space, Time Machine deletes older backups in order to create newer ones. However, Time Machine never deletes the last remaining backup. Source: support.apple.com, read September 28, 2026
Two of the progress messages Time Machine shows during a backup belong to this process. Cleaning up old backups appears when it is removing history to make room, and Freeing space appears when it needs room before it can continue copying. Neither is an error, and neither needs help.
The message that does mean manual action is required names the thinning explicitly: a backup can fail because there was not enough space on the backup disk even after older backups were deleted. At that point macOS has already thrown away everything it is willing to throw away, and the remaining options are a larger disk or a smaller backup. Deleting more dated backups by hand from a disk in that state buys hours, not months.
So the honest answer to which old backups are safe to remove is that on a disk with room to spare, none of them need removing, and on a disk without room, removing them is not the fix. The cases where manual deletion is genuinely the right move are narrower and worth naming.
The command that says how much a backup is actually worth
Before deleting any dated backup, it is possible to measure exactly what it would return. The tmutil command that ships with macOS has a verb for it, and its manual page describes the figure precisely.
uniquesize path ... Analyze the specified path in an HFS+ backup or path to an APFS backup and determine its unique size. The figure reported by uniquesize represents things that only exist in the specified path; things that are present in other backups are not tallied.
Running it against an old backup is the step that ends most of these debates. A dated backup that shows tens of gigabytes in the Finder commonly reports a unique size in the low hundreds of megabytes, because everything else in it is still referenced by later backups. tmutil listbackups prints the list of dated backups to feed it, and both verbs require root and Full Disk Access, which is granted to the Terminal app in Privacy settings.
Two situations produce a genuinely large unique size, and they are the ones where manual deletion pays. The first is a backup taken just after a large one time import that was later deleted from the Mac, such as a video project or a disk image. The second is a backup taken during a period when a folder now excluded from backups was still being copied. In both cases the data exists in a narrow range of dates and nowhere else, so removing those dates removes the data.
Deleting one dated backup
The supported route is tmutil delete, and its arguments are worth reading before use. The manual page describes them as follows.
delete [-d backup_mount_point -t timestamp] [-p path] Deletes the backups with the specified timestamp from the backup volume mounted at the specified mountpoint. The -t option followed by a timestamp can be used multiple times to specify multiple backups to delete. For HFS backup disks, a specific path to delete can also be specified using the -p option. This verb can delete items from backups that were not made by, or are not claimed by, the current machine. Requires root and Full Disk Access privileges.
Three details in that paragraph matter. Timestamps are specified rather than paths, which is why dragging a folder to the Trash is the wrong shape of operation. Several timestamps can be given in one invocation, which is the efficient way to remove a whole range of old dates. And the -p option, the one people look for when they want a single file gone from every backup, applies only to Mac OS Extended backup disks. On an APFS backup disk, backups are volume snapshots, and individual files inside them cannot be picked out.
That last point is the answer to a question the forum threads keep asking without resolving. On a modern APFS backup disk, there is no way to purge one sensitive file from the whole backup history. The unit of deletion is a date.
Local snapshots are a separate pile on the internal disk
When the startup disk is the one that is full, the dated backups on the external drive are not the cause. Time Machine also keeps snapshots on the Mac itself, and Apple describes their lifetime.
These snapshots are created hourly, stored on the same disk as the original files, and saved for up to 24 hours or until space is needed on the disk. Local snapshots are only created on disks using the Apple File System (APFS). Source: support.apple.com, read September 28, 2026
Those snapshots are why deleting a large file sometimes frees nothing. The file is gone from the visible volume and still present in an hourly snapshot, so the blocks stay allocated until the snapshot expires. tmutil listlocalsnapshotdates prints what exists, tmutil deletelocalsnapshots takes either a volume or a single date, and tmutil thinlocalsnapshots accepts a volume, an amount in bytes to reclaim, and an urgency level from 1 to 4.
There is also a failure message that points straight here. When Time Machine reports that it could not back up a disk because a snapshot of the disk could not be created, Apple's guidance is that the internal disk may be almost full and that deleting some files can resolve it. Waiting out the snapshots, or thinning them, is the same fix without the file loss.
Backups from a Mac that is gone
A disk that has served two computers is the case where a large deletion is clearly correct, and it behaves differently depending on format. On a Mac OS Extended backup disk, a top level Backups.backupdb folder can hold a machine directory per computer, so several Macs coexist on one volume. On an APFS backup disk, the root of the volume is the machine directory, which is why each Mac needs its own volume and why the whole volume is reserved for backups.
Apple's own note on that reservation is useful when planning a shared drive.
The entire APFS volume is reserved for Time Machine backups. If you want to store files other than the Time Machine backup on the same physical device, use Disk Utility to create an additional APFS volume on the disk. The two volumes then share the available space. Source: support.apple.com, read September 28, 2026
When a disk holding another computer's history is connected, macOS asks whether this computer should claim the existing backups on it, offering to claim them, to start separate backups alongside them, or to decide later. Claiming keeps the old history and continues it. Starting separate backups preserves the other computer's backups and adds a second set, which is how a disk quietly ends up holding two full copies of two Macs.
For the retired Mac's history specifically, deleting the whole machine directory or erasing its volume in Disk Utility is faster and cleaner than deleting its dated backups one at a time, and it is the one deletion that reliably returns a large amount of space.
Starting over on purpose
Occasionally the correct answer is to discard everything. Time Machine offers this itself when it finds a history it cannot trust, warning that backups on a disk cannot be reliably restored and offering to erase the backup history and start a new backup. It also appears as a choice during setup when an existing backup cannot be used.
Apple's advice before agreeing is to retrieve what is needed first: click Back Up Later, browse the existing backups from the Time Machine menu bar item, pull out the files that matter, and then start the new backup. The new history contains nothing until the first full backup finishes, so the window between the erase and that finish is a window with no backup at all. Running it overnight with the Mac on power is the difference between an inconvenience and a bad week.
That menu bar item is also the fastest route to Browse Time Machine Backups and Back Up Now, and it only exists if it has been turned on. Apple's route is System Settings, then Control Center in the sidebar, then Time Machine, then Show in Menu Bar. On a Mac where the bar is already full of resident utilities, adding one more icon means something else drops out of view, which is a separate problem with its own set of solutions.
What to change first
Measure before deleting. Run tmutil uniquesize against the oldest dated backups on the disk, and if the numbers come back small, the disk does not have a history problem and the next step is a larger disk rather than a cleanup. If a retired Mac's machine directory is sitting on the same volume, delete that instead, because it is the only deletion that returns real space. And if the reason this started was that the Time Machine icon was buried among a dozen others at the top of the screen, Koffret keeps the bar down to the icons worth seeing.
Frequently asked questions
Can I just drag an old backup folder to the Trash?
No. Backups are removed by timestamp with tmutil delete, not by path, and the folders are protected in ways that make a Finder delete either fail or leave the backup disk inconsistent. On an APFS backup disk the dated backups are volume snapshots rather than ordinary folders, so there is nothing for the Finder to move.
Why did deleting an old backup free almost no space?
Because unchanged files are shared between backups, so an old backup contains almost nothing that is not also in a later one. tmutil uniquesize reports exactly how much exists only in that backup, and on a healthy history the figure is usually a small fraction of what the Finder shows for the folder.
How do I delete a Time Machine backup made by a Mac I no longer own?
Remove its machine directory, or erase its volume in Disk Utility if the disk is APFS formatted and each Mac has its own volume. tmutil delete can also remove backups that were not made by or claimed by the current machine, which covers the case where the old Mac's history sits in a shared Backups.backupdb folder on a Mac OS Extended disk.
My startup disk is full even after deleting files. What is holding the space?
Most likely hourly local snapshots, which keep the deleted data on the internal disk for up to 24 hours or until the space is needed. tmutil listlocalsnapshotdates shows them, and tmutil thinlocalsnapshots reclaims a specified number of bytes from them if waiting is not an option.
Can I remove one particular file from every backup?
Only on a Mac OS Extended backup disk, using the -p option of tmutil delete. On an APFS backup disk the smallest unit that can be deleted is a whole dated backup, so a file present across months of history cannot be picked out without discarding those months.