Time Machine backups painfully slow on NAS (smb)

[HDFan]

I am transferring at about 20-30 MBps (not Mbps) via AFP/WiFi-5.

How big is the backup?

 

[rehkram]

While we wait for rg_1890 to respond I just ran a 13,437,648,896 bytes (13.5 GB) TM backup of my internal drive to my Syno NAS, time was 11 minutes (660 seconds).

So by my calcs the nominal transfer rate would be 13,437,648,896 / 660 = 20,360,074 Bps (19.4 MBps). So I pretty much concur with rg_1890's findings.

 

[El Pescador]

The unix suggestion is the first one that I've seen that gives me some hope. I'll try this when I return home. I've pretty much been battling terribly slow and inconsistent TM back-ups since switching to my Synology NAS ["preparing" the backups takes forever, then the back-ups themselves are slow (back-up running right now hasn't even shown any progress for 45 min) and then the "cleanup" function at the end drags on for eons if and when a back-up actually does complete without just failing and starting over again]. When I had TM backing up to the Time Capsule that I was also using for a WiFi router, I had years and years of flawless backups that were fast and completely in the background. It worked beautifully but obviously I wanted to upgrade our WiFi over time and the Time Capsule was only 1TB so now I have great WiFi running on an Eero mesh system and an expensive NAS that is incredibly slow for back-ups and it's honestly 95% of the reason I bought a NAS in the first place. I'm not using it for a media server or anything besides home network file storage for access across different computes and doing TM backups for those three computers. Could I just buy an external HD and plug in for periodic back-ups? Yes of course but it defeats the purpose of TM. I don't want to have to think about backups and go plug in. I just want it to back up in real time wirelessly without me even thinking about it. I loved the concept of a NAS given I'd have redundant backups. If one volume got corrupted, I'd have the second one as a double safeguard. At this point, I'm ready to throw in the towel if this new suggestion doesn't work. How can technology get better but something simple like TM back-ups get worse? I miss the Time Capsule days for this reason - it worked SOOOO great and I took it for granted.

 

[rehkram]

Definitely try rg_1890's 'Apply default UNIX permissions'.

If it's still slow check that 'Transport encryption' is disabled on the NAS side under DSM > Control Panel > File Services > SMB > Advanced Settings button, and also on the macOS side. To disable it on the macOS side I used the following command:

printf "[default]\nsigning_required=no\n" | sudo tee /etc/nsmb.conf >/dev/null

For more background on turning-off signing see:

https://forums.macrumors.com/thread...electing-synology-share.2117841/post-26039284

Also, since that post, I've re-enabled AFP since it didn't seem to affect SMB and was probably a red herring.

 

[rehkram]

Also, since that time, I see that Apple have changed the default for SMB packet signing to 'no'. This started in macOS 10.13.4. So running that macOS command should not be necessary if you're at 10.13.4 or later.

Turn off packet signing for SMB 2 and SMB 3 connections - Apple Support

Learn how to turn off packet signing on your Mac.

support.apple.com

 

[southerndoc]

I connected via AFP finally and my issues went away.

 

[rg_1980]

How big is the backup?

Hi, it is about 70GB.

 

[El Pescador]

Update from me since yesterday: Unix settings didn't help make it faster but it did finally complete a back-up. It took all night for 135 GB though. A 322MB backup going right now started 2 hours ago. Basically nothing is working for me yet and I have everything enabled/disabled that's been suggested. Like I said before, TM was working perfectly and super fast when I was using Time Capsule for a Wifi Router and back-up disk - that's when things were old and slow even. I'm baffled why modern/faster routers and a robust NAS like Synology aren't at least meeting that standard when you'd think back-ups were even faster. I don't use the Synology NAS for anything except computer backups so there's no competing demands either. Also as an aside, I've noticed that if you have a Mesh wifi system and you move your computer and it switches to different "nodes" the backup gets disrupted and you have to start over again.

 

[rehkram]

I don't use any wifi connections. All is CAT 6 ethernet. NAS plugs straight into a port on the main house router.

 

[El Pescador]

I don't use any wifi connections. All is CAT 6 ethernet. NAS plugs straight into a port on the main house router.

My NAS is plugged into the router too but my computer backs up over wifi. Perhaps I'll just have to suck it up and get in the habitat of connecting my computer to the NAS directly via USB to USB or USB to Firewire connection and use it like an external hard drive - which defeats the purpose of the NAS ultimately.

 

[rehkram]

My NAS is plugged into the router too but my computer backs up over wifi. Perhaps I'll just have to suck it up and get in the habitat of connecting my computer to the NAS directly via USB to USB or USB to Firewire connection and use it like an external hard drive - which defeats the purpose of the NAS ultimately.

Not at all. Just run ethernet cables. I installed wall boxes with RJ45 jacks at the two locations I need for primary connections, terminating at another box near the main house router. I'm lucky I can run them under the floor easily, you might not find that so easy depending on your house.

 

[jbPrime1]

I have done extensive troubleshooting to try and solve the problem of Spotlight holding my SMB share Time Machine volume "hostage", preventing it from being unmounted/ejected, and preventing subsequent Time Machine backups from a MacBookAir 2018 Intel client. The SMB share is on a MacMini (server) on the LAN and the shared TimeMachine volume is on an attached DROBO on the server. The MacBookAir client is on the same LAN via Ethernet. The Time Machine log (via log show --predicate 'subsystem == "com.apple.TimeMachine"' --info | grep 'upd: (' | cut -c 1-19,87-999) shows continual [com.apple.TimeMachine:Spotlight] Waiting for Spotlight to finish indexing '[mountedTMVolume]' and this never ends. After 3 complete start-overs, the same thing. My target MacBookAir.sparsebundle was formatted all three times as APFS, encrypted. The sparsebundle was properly inherited, and setdestination was set before the first backup via attached SSD to make the first B/U faster. Then, the sparsebundle was copied to the MacMini's DROBO shared volume. After that, TM preferences was used to re-target the backup to the SMB share, encrypted and Time Machine accepted and verified the target sparsebundle. A manual backup took just 5 minutes over the LAN to the SMB share. However, after that Spotlight ran forever. Becoming increasingly frustrated, I decided to start over again using HFS+ for the sparsebundle filesystem instead of APFS. I used the same process for the initial backup and copying the sparsebundle to the DROBO shared SMB volume. I ran a Time Machine backup, which took a little longer (~ 20 minutes), not surprisingly because HFS+ is not as efficient. After Time Machine was done it no longer waited for Spotlight to finish indexing, in fact the time machine log (see above log command) showed no Spotlight entries whatsoever. My conclusion is that Apple's Time Machine will not work properly backing up to a APFS sparsebundle on a HFS+ formatted SMB share. The sparsebundle file system should probably match the SMB share filesystem. This seems counter intuitive because the underlying file system in the sparsebundle should not matter, but apparently it does.

I hope this is helpful and I intend to file an Apple bug report (if they'll let me), because, in my opinion this is an Apple bug that should be fixed. There is some Spotlight failure with SMB share mounted volumes. I don't expect this will get any attention from Apple or that anyone in that company will care about this. Miracles do happen though.

 

[rehkram]

I'd first make a backup of the the existing backup folder and then blow it away. Instansiate a new backup location via TM prefs > Advanced. It will, or should, create an APFS formatted folder on your backup device. Or that's what happened to me, much to my complete and total surprise. Been working fine ever since, fully tested, both save and restore.

But still I don't quite trust TM, call me paranoid but I test it regularly.

 

[Ruggy]

Something I discovered recently which may be relevant to some:
There are two basic types of HDD technology: CMR and SMR.
SMR drives can take a very long time to index especially with something like Time machine using a sparse bundle and especially it seems with the way Synology NAS writes to disk.
A lot of Synology drives come already configured with drives and sometimes with WD Red drives.
It's been found that although most of the Red drives are CMR some of them are SMR and there's been a law suit against WD for this reason because they aren't really compatible with Synology. They will work but very very slowly.
I found this out recently because I've never had good speed from my Synology and it contains 2 HD Red drives sold for NAS and they are both SMR!!
This is a quote I found : test showed that a zfs raid of WD Red SMR drives would rebuild in about 9-10 days, compared to WD Red CMR drives which would rebuild in 14hrs.

 

[RiderX]

WD red > 8 TB are CMR. Smaller disks should be “Red Pro“ or „Plus“ otherwise they are SMR.

 

[concretenz]

Definitely try rg_1890's 'Apply default UNIX permissions'.

If it's still slow check that 'Transport encryption' is disabled on the NAS side under DSM > Control Panel > File Services > SMB > Advanced Settings button, and also on the macOS side. To disable it on the macOS side I used the following command:

printf "[default]\nsigning_required=no\n" | sudo tee /etc/nsmb.conf >/dev/null

For more background on turning-off signing see:

https://forums.macrumors.com/thread...electing-synology-share.2117841/post-26039284

Also, since that post, I've re-enabled AFP since it didn't seem to affect SMB and was probably a red herring.

Legend! thank you.