Time Machine slow at certain spots

[jj5406]

This is not about general speed of time machine backups, but whenever a backup seems to be taking forever and I look in "Time Machine Preferences...", it always seems to be "stuck" (actually just going very, very, very slowly) at a certain spot in the backup. Right now it says "Backing up 429.7 MB of 5.67 GB, About 23 hours remaining". It's been stuck there (creeping slowly up in the 420 MB range for an hour or two).

That estimate of time remaining is just based on how long it's been running, and how much data is remaining. What usually happens is at some point it will get past its hangup, and finish up quite quickly.

What I want to know is what is slowing it down and maybe avoid this issue. I'm wondering if it is certain files that are taking forever, or is it something else running that is slowing things down?

A few minutes ago I could see that scep_daemon was eating up a lot of CPU (> 100% in the activity monitor listing) and backup was barely registering. Now (after hours of being stuck) things seem to be moving again. scep_daemon is still > 100%, but now backup is jumping around (from 1 up to 60%). In other words, it doesn't seem to be related to the scep_daemon.

Is there a way to see what particular files are being backed up in real time? That might help me diagnose the problem.

Thanks.

-JJ

 

[jbarley]

Maybe something like a very large Photos library file, something large that gets changed or modified regularly.

 

[jpn]

i think we have all noticed that at times Time Machine doesn't appear to be increasing the % done.
but its clear that there is just no file large enough by itself to be causing minutes worth of apparent stoppage/slowdown/delay, no matter what is the name of the particular file that it appears stopped at.
therefore i have always thought that those times that a slowdown/stoppage appears to be happening there is something else going on in the network or in the background of my system that causes this. or, that the Time Machine file system or tracking system is catching up or doing some checking itself. but not caused by a particular file itself.
also, since i began to use 2 Time Machines, (1 SSD and 1 spinning media) and 2 different methods of it being hooked up (1 by WiFi and 1 by direct USB-C) i can also report that in fact the SSD/USB-C combination has no slowdown whatsoever at any point. its an amazing difference to me since for many many years i have come to get accustomed to the Spinning Disk/WiFi) occasional slowdowns.

 

[jbarley]

Is there a way to see what particular files are being backed up in real time? That might help me diagnose the problem.

Thanks.

-JJ

This free app gets good reviews.
https://www.macupdate.com/app/mac/36691/timetracker

 

[jj5406]

hmmm. Interesting notes niji. jbarley: The slowness I'm seeing is almost certainly not the result of a large file - though my thought was that there might be certain files or directories that are causing delays for some reason other than size (though not sure what that reason would be). I have long since off-loaded my photos library to an external disk, which I keep backed up by duplicating to a second external disk.

My current setup is that my time capsule is connected directly to ethernet and my laptop is connected directly to the time capsule via ethernet adapter plugged into the lightening port and ethernet cable to the time capsule. There is no WiFi being used in this setup. I have always assumed that the backups are taking advantage of the direct connection between the laptop and the time capsule rather just than sending data out onto the LAN (as would be done to backup to a time capsule that is connected at some other point on the LAN) - though that may not be the case.

These long and obvious delays appear to happen when I haven't backed up my computer for a day or more. If I do a backup shortly after the long delay-backup (when there is obviously much less data to back up), it is rare to see such problems, and if I do, they are much shorter in duration. I'm running a backup now and the same thing is happening - though this time there is no other process clearly using up CPU. The process kernel_task, which I imagine is involved in the backup, appears to be the most active in cpu, network, disk access, and memory.