The Time Machine is causing the CPU to hit 100%.

I have the same error on my MacBook Air M1.

Deleting the old backup didn't help.

Backing up to a USB drive does not cause an error.

The error only appears when backing up to a Synology NAS.

It didn't show up on older MacOS either.

That supports the assertion that diskimagesiod, the daemon that now manipulates disk images, needs some work in either optimizing its CPU usage, or throttling is CPU usage, or BOTH.

Grant Bennet-Alder

But I'm dealing with the same problem. See my older posts.

Timemachine creates snapshots on a local disk and then moves them to a NAS or local disk.

If disimagesioid has a problem with snaphots, it loads the CPU to 100% when accessing it and then backing it up on the NAS.

My snapshots were created by an older version of macos and after upgrading to MacOS Sequoia 15.0 this problem occurs.

As I wrote earlier, I used the OnyX utility.

I had to turn off Timemachine until I deleted the old snapshots.

Timemachine on Synology NAS is now usable again.

Although it still loads the CPU, but for a much shorter time and not at 100%.

Today I upgraded to MacOS Sequoia 15.1 I will test Timemachine to see how it works.

[Edited by Moderator]

Readers here have not disclosed any known fix for this issue.

I don't expect Apple Support to be able to fix this for you on the spot, but your should let them know it is happening and ask them to create a Formal Bug Report on your behalf, or add you to any existing Bug report they already have on file.

Formal Bug Reports require methodical collection of enough information from you, to allow an Engineer to re-create the problem in their lab, so they can study it in detail.

You can also post an informal Bug Report on the feedback pages. These are NOT tracked, and you will generally NOT get a report back:

Product Feedback - Apple

.

Add screenshot:

Reboot only works sometimes. I had to turn off Time Machine on the NAS until the problem was resolved. Time Machine on a USB drive works without problems.

No, that's not one cpu. That's 100% of the overall cpu capacity, what he's showing you is iStatMenus, and iStats normalizes the load on a 1~100% scale.

If you scroll back up you will notice some other user took a snap of the native activity monitor, and it shows 700%+ CPU usage.

This is not isolated, I have the exact same problem, see pics below.

iStats:

Activity Monitor:

Thanks, I had a snapshot from September, so quite old, maybe that was the one causing problems, let's see if I have the CPUs at 100% again for diskimagesiod.

what is likely happening during that time is updating the sparse bundle disk image file (a full MacOS file system inside a FILE) on the Time capsule.

It is possible Sequoia does not write totes files as quickly as Sonoma.

The more often time machine is allowed to run, the less it will have to write to the drive when it does run.

Backing up to a NAS (or any Network drive) uses the same sparsebundle disk image to store the backup information inside a file on the remote device, so this is the same issue despite not being a Time capsule device.

I'm curious if folks are noticing this after/during other particularly CPU-heavy processes, or processes that write to disk. I also have the issue of it occasionally nearly maxing out my CPU (700%+ on an 8 core MBP M1 2020 13") during Time Machine backups to a networked drive (Time Capsule). It never hits long enough to get the fan going, but I notice things get laggy.

I ask because I tend to notice it when using Lightroom Classic getting laggy during more CPU-intensive processes that already push my machine. I'll check Activity Monitor, see LrC hitting the CPU hard momentarily, and then see diskimagesiod spike to 700%+. This warning about a LrC permissions error having a caveat of "if a Time Machine volume is mounted, just ignore this," makes me wonder if there's some interplay.

Anyway, throwing that out there?

MBP M1 2020 13" 16GB RAM, Sequoia v15.0.1

what seems different is that the task hogging the CPU is diskimagesiod, the daemon that does the I/o to manipulate disk images. As I noted earlier, backups on a server are kept ins a sparsbundle disk image, a variant of disk images.

Local backups typically cause a more modest spike in CPU use by mdworker or related tasks, and it stays under control. Older macOS may cause a similar spike, but my experience is that its stayse controlled at 100 percent of ONE CPU.

There may be a new way of doing this for the latest MacOS, and it sounds like it needs some tuning.

Be sure to let Apple know through some of the methods enumerated above. Otherwise, they won'y know it's a problem and won't be working on a fix.

Yes; I submitted a feedback report. It's hard to do a true bug report since the issue is intermittent.

I have realized that it's not only Time Machine/Time Capsule. I opened a sparse bundle DMG on my internal SDD and am getting periodic full-CPU spikes. I'll file another report.