Nov 04

Time Machine automatically deletes old backups when it’s getting full, but if you also use the backup disk for other purposes, you might want to clear some space manually.

There is a built-in command line utility that comes with macOS which you can use for this – tmutil.

Specifically, the sub-command you want is tmutil delete, here is an extract from the man page:

     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.

You can list existing backups with tmutil listbackups but the path that’s printed is not the path you need to provide to tmutil delete. In fact, you actually need to provide the -d and -t flags, not -p.

To find the backup mount point, you can use tmutil destinationinfo. Here is an example output:

~ $ tmutil destinationinfo                                                                                     
====================================================
Name          : Time Machine
Kind          : Local
Mount Point   : /Volumes/Time Machine
ID            : F0CBBC01-DEAD-CA1F-BEEF-0000AAAABBBB

So in this case, the value for the -d flag is "/Volumes/Time Machine".

You can extract this with awk or another utility, for example:

~ $ tmutil destinationinfo | awk -F ' : ' '/Mount Point/{print $2}'                                            
/Volumes/Time Machine

As for the -t (timestamp) flag, this is obvious from the tmutil listbackups output, but you can even specify -t in the listbackups sub-command which prints only the value needed in the correct format.

For example:

~ $ tmutil listbackups -t
2022-02-05-094839
2022-02-12-091416
2022-02-19-093000
2022-02-26-092448
...

Bringing it all together

Now we know what values to pass to tmutil delete, the final command might look like this:

sudo tmutil delete -d "/Volumes/Time Machine" -t 2022-02-05-094839

But we can go one better than this… Say you want to delete all the backups from Jan-Mar in 2023, you can use this one-liner:

tmutil listbackups -t | \
egrep '2023-0[123]' | \
xargs -L 1 sudo tmutil delete \
-d "$(tmutil destinationinfo | awk -F ' : ' '/Mount Point/{print $2}')" -t

Of course you could filter in other ways, e.g. head -n 20 to delete the oldest 20 backups (careful though, this will delete the most recent as well if there are only 20 or fewer in total).

Tagged with:
Dec 23

I recently purchased a new Mac mini to replace my home computer – a 2009 iMac. It was well overdue as Apple listed it as obsolete 4 years ago.

Unfortunately, it only comes with 256GB SSD storage as standard and Apple charges £200 extra for 512GB and £400 extra for 1TB. Very pricey! So in an attempt to save some money, I thought I would use an external drive for additional space.

It wasn’t long before I settled on the idea of getting an NVMe SSD with an enclosure. This was recommended by The Verge and seemed to offer the best price point and flexibility.

For the SSD itself, I went through several sites such as Tom’s Hardware looking for a recommendation and eventually settled on the ADATA XPG SX8200 Pro. This offered a good price/performance ratio (at least in the UK).

Now came the more tricky part – which enclose to use. Originally, I was expecting to get a Thunderbolt enclosure, but it turns out they are prohibitively expensive – especially for my use-case. It didn’t make sense to spend more on the caddy than the SSD!

After trawling Amazon for a while I picked up a FIDECO M.2 NVME External SSD Enclosure. It looked very promising – 4.3 out of 5 starts with 782 ratings.

However, as soon as it arrived – the fun started. While I did manage to connect and initialise the disk, immediately after starting a file transfer it detached itself from the OS. I tried disconnecting and reconnecting it, but it showed up uninitialised as a 97.86TB disk.

I thought I’d try formatting it again, but I ended up with the following error:

Unable to write to the last block of the device. : (-69760)

This makes sense, given how big it thought the disk is (over 90TB), and how big it actually is (1TB).

At this point, I started researching enclosures and looking around to if others had similar problems. It turns out NVMe enclosures are notoriously flakey and there are many forums threads discussing the topic.

What I found is, for all the off-brand enclosures, there are three actual chips that power them:

  1. JMS583
  2. RTL9210(B)
  3. ASM2362

Without knowing ahead of time, it seems the enclosure I first bought contained a RTL9210B. This does not have a lot of complaints, but it certainly didn’t work for me. I even tried upgrading the firmware to no avail.

So with that in mind, I scoured Amazon for a new enclosure with a different chipset. Specifically an ASM2362 as the JMicron chip has lots of negative comments.

A few days later (no, I don’t have Prime) my Kafuty USB3.1 to M.2 NVME External Hard Drive Enclosure arrived and I swapped over the SSD.

It immediately showed up in Finder but I thought I’d reinitialise it anyway. Some file transfers and speed-tests later, all was still good ?

TLDR; On my M1 Mac mini, RTL9210B was a complete failure and ASM2362 is stable.

Tagged with:
preload preload preload