NFS and SMB both have multiple levels of security exposures. In their native forms, NFS and SMB are a bit insecure protocols. Furthermore, because both methods require the mounting of a remote file system, there is a bit of risks involved. /etc/exports and /etc/smb.conf (for NFS and SMB, respectively) must be configured carefully on the backup server (tarpool in our example). This is particularly dangerous if users on the server being backed up cannot be trusted.
It is important that the backup server only expose as much as necessary for jd to back up its files. tarpool should never expose the backup folders of other servers to jd. This requires careful planning and crafting of /etc/exports and /etc/smb.conf on tarpool.
Likewise, the respective mount commands to be executed on jd also need to be crafted carefully. NFS passes the permissions from tarpool (the backup server) to jd, so the permissions must be configured properly on tarpool to begin with. SMB relies on fmask and dmask to further secure the files.
The SSH+sudo method, on the other hand, requires no remote file system mounting. The security exposure of SSH is limited to begin with. Combined with additional restrictions, such as disabling passwords and checking the client address, can further eliminate network-side exposure. On the local side (users on jd of our examples), sudo is a fairly secure mechanism. It does require /etc/sudoers be configured properly. However, this is relatively simple compared to the configuration of /etc/exports or /etc/smb.conf.
If you worry about a local user be able to attack the password of backup, you can make sure that the username backup has no password in /etc/shadow. This means that it is impossible to change user to backup from any non-root accounts. It also means that no one can log in as backup. To become backup, a user needs to log in as root, then change user to backup.
If a local non-root user can gain root privilege, then nothing is secure on jd anyway.