Restic can take up a lot of RAM, unlike Borg.
Borg offers the option of no encryption. This is useful when backing up to a local drive that is already encrypted, for example with LUKS.
But, they are generally similar.
However having server side support reduces backup times.
Which is to say, you don't need the borg executable server-side if you are happy to run it over SFTP transport which limits some functionality.
Yes, of course you could talk over an sshfs mount point but I can't think of why you would do that over the more basic SFTP transport.
The accepted, and full-featured, way to run borg is with the executable on the server side and I will point out that the borg project distributes a "frozen" version of the tool that allows you to run it without having python in your environment. I believe they use py2exe to pack it up.
This is important for us[1] as we have no interpreters of any kind in our environment (no shell, no python, no perl) so we can only run binary executables ...
[1] rsync.net
“When Borg is writing to a repo on a locally mounted remote file system, e.g. SSHFS, the Borg client only can do file system operations and has no agent running on the remote side, so every operation needs to go over the network, which is slower.”
SSHFS would be tool agnostic/transparent though of course would result in operations going over the network as it’s not a local repo, but pseudo-local.
I’m curious, how do you use plain SFTP transport with borg using rsync.net?
Either way, having the borg executable on the server side is the "correct" way to do things.
no sftp inside borg (nor anything else).