I’m used to spending quite a lot of time researching these articles, which often spin off into answers which I provide in my Genius Tips section in MacFormat magazine. I am much less used to spending significant amounts of money repairing the damage which results from that research.

But last week’s article on FileVault encryption cost me nearly £300 for a replacement SSD. I’m not looking for donations, or even sympathy, but think it a useful cautionary tale.

It has been quite a while since I last used FileVault, and not something that I was prepared to attempt with my main workhorse iMac, with almost a terabyte of documents and other files on its Fusion Drive. But my standby MacBook Air (mid 2011, with a nippy i7 processor) has only apps and documents already on my iMac, and has been little-used since its purchase. With its largely empty 250 GB internal SSD, it should have been an ideal platform for FileVault.

I keep the MB Air fitfully up to date with macOS, and it was already up to Sierra 10.12.5, so should have been a quick and simple workthrough to perform and illustrate with screenshots. Starting the encryption went as programmed, but somewhere around 73% completion, something seemed to go wrong.

The progress indicator in Security & Privacy was misleading. For a while it seemed stuck at 73%, then jumped to 100%, and back to 73%. There were no warnings or error messages.

When I ran diskutil cs list in Terminal, sometimes it would report that encryption was 73% complete, other times it reported the conversion process had failed.

When it was clear that encryption was stuck at this point, I opened DriveDx to check how the SSD was doing.

What had been a growing irritation now became a very serious concern: my little-used SSD with less than 250 hours on the clock was failing, with an overall health rating of ???.

Looking further down the report, it looked like macOS encryption had been bludgeoning a few blocks to death, and if I didn’t do something fairly quickly, my SSD would be rendered useless.

I restarted in Recovery mode, and checked it with Disk Utility, which repaired a couple of errors on it, and declared its S.M.A.R.T. status as ‘verified’, which contradicted DriveDx’s report of Failing, and did not explain why encryption was running round in circles getting nowhere.

I restarted in hardware test, which twice failed to complete its tests, but did not report any errors. I decided that the only thing that I could do was abort encryption before it did any further damage, so restarted in Recovery mode to initialise and install macOS afresh.

At the end of all this, I had an internal SSD which, at best, had undergone a pretty severe insult. At worst, it had lost at least one of its nine lives. I had to choose whether to make my MacBook Air fully healthy again with a new SSD, or hope that the problems with its existing SSD would not resurface.

I opted to replace the 250 GB internal SSD with a new Transcend JetDrive 500 of 480 GB capacity. Although not a cheap option, it should give the MacBook Air a new lease of life. Installation was far simpler than I had anticipated: like several similar kits, it comes complete with both the special screwdrivers needed to open the case and replace the SSD.

It also includes a USB 3 (not C format) case which made the exchange particularly quick. You first put the new SSD in the case, connect it up, and in Recovery mode initialise it and clone over the contents of the old SSD. That was a strange experience, because every command in Disk Utility failed on the first attempt, but was successful when repeated. I have no idea why that happened.

Having prepared the new SSD in the case, you then swap the old for the new, and the upgrade is seamless. I now have a large 250 GB external SSD which will be put to good use too. I decided not to mess with FileVault again this time, and wonder whether I was just unlucky, or whether this is a more common bug in Sierra 10.12.5.

I hope that High Sierra’s APFS encrypted disks are more bombproof, but won’t be rushing to try them out.