Time Machine Backup Issue Now Resolved in 9.5.3! [Updated]

Just updated to 9.6.1 and I'm still seeing long Time Machine backups with On Access Scanning enabled.

Going to reboot again just to see if it makes any difference!

Right after I updated to 9.6.1, I tried a TM backup and prep time took a bit longer than it had recently. But plists were part of the update, so I rebooted and the backup went back to its brisk normal.

Rebooted again and it seemed a little faster, might have to wait until I have more to backup to see what it's really like though, it still took almost 10 minutes to backup (find volume, prepare, backup, finish) 500MB.

What kind of connection do you have with your TM volume? Mine is in one of the bays in a Mac Pro so it and the boot drive are on the same bus. 2.5GB to be backed up always start out with long completion estimates and then are done in about three minutes though initially the progress is measured in KB's. And the boot drive is running Yosemite, not Sierra.

The TM volume is on a synology NAS, it's connected to the network on a 1000MB ethernet port and both the Macs are using 5Ghz 802.11ac wifi, about 3 or 4 meters away from the AP with line of sight.

There's no issue with network throughput, just Sophos.

I've just updated one of them to macOS 10.12.3 and it's started to backup 2.91GB to the TM volume, it's currently saying 2 hours left and I believe it, it's only done 300MB in the last 20 minutes.

I just don't think the slow TM backup with On Access scanning turned on issue has been fixed, even with 9.6.1!

And mine is STILL not working.

I'm on Sierra with 9.5.5 and backups crawl so slow they're unusable.

This thread has 33k views and it still appears abandoned by Sophos.

Was this issue resolved and noone told us? I saw one person mention 9.6.1 helping, but it doesn't seem to be part of the GA release feed and noone else confirmed.

Time for me to jump ship? I want to like Sophos for me and my clients.

Hello,

9.6.1 should fix that issue, can you upgrade and please let us know?

Thank you,

Bob

9.6.1 running now and started a new backup which appears to be hanging on "Preparing backup...". It would appear that this is not in fact fixed in 9.6.1, or that the fix is not enabled immediately or automatically.

Thoughts:

1)

One commenter mentioned that after 9.6.1 things were still slow, so they rebooted, then they got fast. At first glance that doesn't sound right, since I would assume if this was necessary either the support staff in this thread or the installer would instruct me that is required for the upgrade. However I see this:

sh-3.2# kextstat|grep sophos

  152    0 0xffffff7f80a1c000 0x7000     0x7000     com.sophos.kext.oas (9.5.54) B52E445F-3F0B-3056-BB9D-581194C69E63 <5 4 1>

Note the version number (9.5.54) -- kextunload won't work on com.osphos.kext.oas I assume for security reasons. So perhaps things WILL work after a reboot.

2)

Time machine occasionally verifies or repairs the backup archive, and in these cases "Preparing backup..." really does take a long time.

I will update this thread after a reboot and a few days of monitoring.

A reboot did indeed update the kernel integration.

  152    0 0xffffff7f839c3000 0x8000     0x8000     com.sophos.kext.oas (9.6.51) 9052EE54-A066-3D35-A6CA-BE58375979EE <5 4 1>

The fact the installer didn't prompt for reboot and the GUI incorrectly reports the version should be considered a bug which affects security. I assume this is a design decision however it does not allow positive control over the versions of software in use and thus violates the approved software versions component of secure system code/image policies and associated technical controls advised by ISO, NIST, CIS and others. Please forward this upstream.

I'll update the thread in a few days re: speed -- but I'm staring at a "Preparing backup..." status again right now.

A reboot did indeed update the kernel integration.

  152    0 0xffffff7f839c3000 0x8000     0x8000     com.sophos.kext.oas (9.6.51) 9052EE54-A066-3D35-A6CA-BE58375979EE <5 4 1>

The fact the installer didn't prompt for reboot and the GUI incorrectly reports the version should be considered a bug which affects security. I assume this is a design decision however it does not allow positive control over the versions of software in use and thus violates the approved software versions component of secure system code/image policies and associated technical controls advised by ISO, NIST, CIS and others. Please forward this upstream.

I'll update the thread in a few days re: speed -- but I'm staring at a "Preparing backup..." status again right now.