we operate an 80TB QNAP NAS, both for storing bulk data as well as TimeMachine backups of our laptops. The NAS itself can sustain over 300 MByte/sec of write speeds when accessed from multiple ethernet-connected machines, and TimeMachine has decent performance (configured as AFP share).
However when accessed over wifi, the performance drop is massive – it doesn't show any "live" speeds but leaving a laptop for 20 hours (no energy saving) and only 850MB of transferred data speaks enough. Granted, our network setup is a bit non-standard as our Cisco WLAN AP controller is at our central datacenter connected to our office via a 100/100 leased line and has to share traffic with other clients, but even under loaded conditions an SSH transfer to the NAS achieves ~5 MByte/sec.
What exactly does TimeMachine do when using a network share? Is it possible that there are MTU fuck-ups somewhere along the connection, or does AFP require ultra low latency links (when over wifi, ping is 40ms)?
Best Answer
After your comments and my questions answered, here are my recommendations/best practices.
Probably the only real remedy would be to have the office AP switch local traffic indeed locally. This feature is available in Cisco's APs/AP controller, called FlexConnect.
If you read the first paragraph and look at the illustration in the following PDF, you'll see that this is pretty much your use case. The AP controller is located in a remote location connected via a dedicated (VPN'ed) line – but traffic within the local branch/office is switched locally.
You should probably have a word with your net ops people to see if this is possible to setup or if your AP fits the requirements (a list of supported APs is also in the PDF).
https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-1/Enterprise-Mobility-8-1-Design-Guide/Enterprise_Mobility_8-1_Deployment_Guide/ch7_HREA.pdf
The PDF is from the AP controller software version 8.1, but this feature goes way back (formerly known as Hybrid REAP). You should probably also consult the documentation version corresponding to your AP controller software version to have an accurate list of supported APs.
The real limiting factor will always be the sluggish data rate caused by your specific network setup, regardless of AFP vs. SMB. So, all the following measures are only additional remedies and best practices you can try.
MTU
Check/set your maximum non-fragmenting network MTU over the Wi-Fi connection.
http://www.mseri.me/fixing-wifi-on-os-x-by-tweaking-the-mtu/
There is still the magic MTU number of 1453 floating around the interwebs in regards to (at least older) macOS versions, especially when interacting with Cisco equipment.
http://osxdaily.com/2013/01/14/set-mtu-size-from-the-command-line-of-mac-os-x/
SMB vs. AFP
SMB should generally be preferred over AFP by now, as AFP has been deprecated by Apple for quite some time.
AFP is not even supported anymore when sharing from APFS-formatted volumes.
https://support.apple.com/en-us/HT208018
macOS SMB
Time Machine backups over SMB are supported in QNAP QTS version 4.3 and later.
https://www.qnap.com/en-us/how-to/tutorial/article/using-time-machine-to-back-up-your-mac-to-a-qnap-nas-via-smb/
By default, macOS packet-signs SMB connections, which greatly impacts transfer performance (transfer speed here with signing disabled is doubled!).
As I have no idea if/where you can disable signing globally/server-side in QTS (Syno guy :) or if this would be recommended in your use case, you can disable SMB packet-signing client-side on specific macOS machines.
https://support.apple.com/en-us/HT205926
You can check if signing is disabled by using the command "smbutil statshares -a" (a SMB volume has to be mounted, otherwise the command output will be blank).
Please see the following URL fore more info:
https://kb.promise.com/thread/disable-smb-signing-on-os-x-10-11-5-10-12-x/
Samba settings
The two following best practices are not really related to Time Machine but greatly improve the general SMB experience for macOS clients.
You should augment the Samba config file (smb.conf) on the QNAP NAS according to the following URL:
https://support.apple.com/en-us/HT207128
Ignore the FCP X specific stuff, this setting basically enables macOS-specific features in Samba.
Please check the QNAP specifics for Samba configuration. (For instance, Synology uses a private Samba build with some configuration differences, like commas instead of spaces for multi-attribute config lines.
Also, augment the Samba config file by this:
This setting forces Samba SMB shares to resemble the behaviour of AFP shares by only showing shares that you have permissions for. By default Samba shows all shares, even the ones you don't have permissions for, which shows a permissions error message when trying to access a share w/o permissions.
Disable .DS_Store on network shares
You can try to disable creation of .DS_Store files on network volumes. This can speed up SMB performance. First paragraph in the following URL:
https://support.apple.com/en-us/HT208209
Time Machine
Try to exclude as many items/locations in the Time Machine preferences as feasible. For instance, I excluded the /Applications folder, as it is usually the same/less hassle to reinstall an application than to recover it from a backup. Also, the ~/Downloads folder is usually a good no-backup candidate. Additionally – but this is depending on the specific workflow – it can be feasible to exclude directories that contain data managed by version control systems.
Time Machine is a low priority process. Any other activity will suspend the Time Machine backup process. You can try to disable the low priority throttling in macOS to speed up Time Machine. Please see the following URL for more info (including how to make this setting permanent):
http://www.mackungfu.org/massively-speed-up-time-capsule-time-machine-backups
You can then use the free tool "Time Machine Editor" to exclude your work hours from the Time Machine schedule.
https://tclementdev.com/timemachineeditor/
DISCLAIMER: Use these recommendations at your own risk. Specifially, try out the settings/modifications first on a test machine before rolling out to production systems.
These are my 2 cents (actually, it's more like 1,50 Euro).
Assuming from your name that you are located in a German-speaking region:
Viel Erfolg!
[EDIT] With QTS 4.3.5 it looks like QNAP added GUI options to enable access based share enumeration, so it is probably not necessary anymore to manually edit the smb.conf for this functionality. From the QNAP QTS 4.3.5 release notes: