You may recall that this saga started when I wanted to check my Mac for problems occurring when it was left running, not asleep, and just performing maintenance tasks, in the small hours of the morning. I discovered that Time Machine backups were generating huge volleys of tens of thousands of log entries, largely because there were two snapshots which had become ‘stuck’ and couldn’t be deleted. When I went to the log to see what might have gone wrong when those snapshots were made, I discovered that my logs only went back 4-5 days. I found backed up copies in Time Machine, but no tool which could access those log files.

Console and log, the only tools provided by Apple for working with the unified log, work with different sources:

• Console can work with the special live-streamed system log, or logarchives.
• log can work with the live-streamed log, the active system log, or logarchives.

My utilities Ulbow and Consolation 3 access the log through the log show command. Although this allows them to open individual tracev3 log files, they must be contained within a logarchive. There’s no option in any of these tools to open logs from within a Time Machine backup copy, as far as I can discover. You can use the log collect command to create a logarchive, but as far I can tell, it too can’t do this apparently simple task.

If you create a logarchive from the active system log, you’ll see that it’s a bundle (folder) containing each of the components within /var/db/diagnostics, plus all the folders from /var/db/uuidtext, and an Info.plist. With the exception of that last file, it’s fairly straightforward to create your own logarchive manually.

Start by renaming the diagnostics folder to that of your destination logarchive, omitting that extension for the moment. Inside it, create a new folder named Extra, and put the logdata.statistics.[n].txt, any shutdown.log, and version.plist files inside that.

Then leave all the remaining items where they are, and drop in all the 00, 0A, … folders from inside /var/db/uuidtext.

You now have a logarchive in all but one respect: it needs its Info.plist file. Its contents aren’t complex, but it appears to refer to time sync data in the files inside the timesync folder, and it’s not easy to reverse how that works. For the time being, simply copy across the Info.plist file from another logarchive created recently from your active system. Then append the .logarchive extension, and give it a try using your favourite log browser.

To make this clearer, here’s a diagram showing which files and folders go where in the conversion process.

and here it is in convenient tear-out PDF: MakeLogarchive1

Doing that with the log files which I retrieved from my Time Machine backups, I was able to inspect the entries when the offending snapshots were created.

There are no errors there, but a day later when Time Machine came to try to ‘thin’ them, it started throwing errors, which were repeated in every subsequent backup, but never reported to the user, and inaccessible to T2M2.

I rather hope that I have solved this problem for now, but wonder if this could have been related to the 10.15.3 update, which had only been installed two days earlier? If you’ve updated to 10.15.3, you might like to check your snapshots to make sure that you too don’t have such a problem.