Shirt Pocket Discussions

Shirt Pocket Discussions (
-   General (
-   -   Workaround for 100% CPU usage by sdbackupbytime (

jkbull 03-03-2019 11:13 AM

Workaround for 100% CPU usage by sdbackupbytime
First, I want to mention that I've used SuperDuper! for years and consider it a great product. I'm currently using SuperDuper! 3.2.4 (v 118) on macOS High Sierra.

This morning I awoke to find SuperDuper!'s sdbackupbytime process using 100% of CPU time. After quitting the process via Activity Monitor or restarting the computer, the process restarts and resumes using 100% of the CPU. (Well, 100% of one core, anyway.)

This appears to be due to a bug in SuperDuper! when a backup is scheduled to start during the hour after the switch to Daylight Savings Time. In my case, I had a backup scheduled to start at 2:00 am on Sunday March 10, which is the exact time that the DST switch occurs. (Interestingly, although the scheduled time was 2:00 am, the time in the description of the backup was "Every Sunday at 3:00 amů". That sort of makes sense because 2:00 am doesn't really exist; DST causes the time to skip from 1:59:59 to 3:00:00.)

The workaround is to change the schedule so the backup starts before 2:00 am or after 3:00 am. Then all is well. Setting it to start at 2:00 am, 2:05 am, or 2:55 am triggers the problem.

dnanian 03-03-2019 11:17 AM

This is happening in v118? I'd fixed the problem in October, so I'm rather surprised it would be back.

I'll take a look - thanks for the report.

jkbull 03-03-2019 11:28 AM

Yes, v 118.

I emailed details to, including spindumps, etc. if you need them.

dnanian 03-03-2019 08:34 PM

Thanks. It's a slightly awkward time to have this happen, because I'm out of the office for another week, but at least we have a workaround and it only happens to people whose backups land in that hour.

hand123 03-07-2019 08:28 PM


Originally Posted by dnanian (Post 34426)
This is happening in v118? I'd fixed the problem in October, so I'm rather surprised it would be back.

I'll take a look - thanks for the report.

I noticed high memory usage of sdbackupbytime today. I forced quit. It reappeared automatically and started using a lot of memory again.

dnanian 03-07-2019 09:09 PM

Change the backup time so it's not in the 2-3am range (eg use 3:05).

geiswood 03-09-2019 12:12 AM

Me Too
this is happening for me, but I don't currently have ANY scheduled backups.
perhaps this will go away once we've traveled into the future on Sunday?

I'm running SD 118 and Sierra 10.12.6

Keeping Activity Monitor open to Kill sdbackup like a cockroach...

geiswood 03-09-2019 12:05 PM

Me Too
I was finally able to keep the sdbackupbytime cockroach under the fridge by deleting all my past scheduled backups from the library and restarting my machine.

Lost 3 days of computer usability to this runaway memory hog process. Had started to price new systems...

I blame Ben Franklin and his daylight "Savings" concept...

dnanian 03-09-2019 12:25 PM

I don't quite know what "past scheduled backups" means here: did you have actual schedules? sdbackupbytime shouldn't be running if there aren't any schedules.

Anyway, apologies for the problem: a source code control issue allowed a problem I'd fixed in 3.2.3 come back in 3.2.4 (still don't quite know how it happened, frankly). We'll have it fixed in the next update, for good. (I wasn't able to get a fix out earlier due to being on vacation...)

geiswood 03-13-2019 07:33 PM

They were old schedules, probably created when I was running 3.2.3 (or older...) They were not active schedules and probably referred to external volumes that no longer exist.

Hope your vacation was relaxing and exotic, hope you had an appropriate beverage in hand while checking the support forums.

dnanian 03-13-2019 08:25 PM

Had fun skiing, thanks. Cut short, unfortunately, due to a death in the family (Dad) back now.

All times are GMT -4. The time now is 11:06 PM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2022, vBulletin Solutions, Inc.