REST server vs SFTP

I have been running restic for several years. It runs automatically and I don’t even have to think about it. Once in a while I check the repo in case a lock file has silently blocked the backups, or run a restic check. It would be great if restic could work without lock files. Congratulations to the restic developers!

I use SFTP but I see suggestions for REST server (an http server). Can someone explain the difference between REST server vs SFTP ?

It seems backups are faster. How much is the difference? Any other advantage?

I want to see if it worth changing.

I guess the answer to your question depends on quite a few factors. rest-server is not better than SFTP but different. The way I see it:

Pros:

  • Append-only mode(*)
  • Multi-Repo access via multiple users
  • Maybe speed but I haven’t personally tested that

(*) This adds security against ransomware and other malware. because the client can’t delete any data from the repo.

Cons:

  • Additional software you have to setup and secure
  • Additional software that can contain exploitable bugs

I guess for personal backups to a machine that you have ssh access to anyway, adding rest-server makes limited sense. But if you have a central backup server and clients that you don’t want to trust 100% (like internet exposed hosts running potentially exploitable services) it might make sense to setup rest-server with append-only mode.

But that’s just my 5 cents!

1 Like

Thanks, that clarifies it!

It takes more setup actually compared to SFTP. Username and passwords must be setup, vs simple ssh key-gen. TLS certificate should be setup and renewed for protecting user passwords.

Exactly. It’s well worth it if you have the requirements mentioned above though!

1 Like

Not entirely sure I agree. If you use SFTP and you don’t want the client to be able to SSH to the server and do whatever they want, you need to configure their account to only allow SFTP access to their files. I personally don’t think REST-server is any more complicated, I’d rather say it’s easier to set up as you just drop the binary in place, create a .htpasswd for your users and off you go. But yes, you do need to manage the certificate as well, and the making sure rest-server runs continously.

Yes. That is why I said that if it’s a personal backup to a machine that you have full ssh access to anyway, it doesn’t make a difference. But I totally agree: if not, rest-server is very much worth a look.

And if you want to avoid the hassle of taking care of a certificate and put the backup server where the clients can’t even access it, you might consider initiating the backup from the server via an (encrypted) ssh tunnel like I do in some cases. Then, all you have on the client is the restic executable and not even any passwords or backup server URLs.

1 Like

I agree with @rawtaz in the fact that leaving SFTP accessible to Restic is a potential security risk: the SSH key used to connect to the remote machine has no passphrase protection. If you get access to the client you also have access to the backup server.

With rest-server the server wouldn’t be compromised if someone gets hold of the client. It works great with a VPN if you don’t want to manage TLS certificates.

This is not true. The access is limited to SFTP and doesn’t include ssh.

The usual process is to create a non-privileged user “restic”, lock it down (perhaps even lock the password, set no shell, and change the root folder), and backup via pubkey SFTP. SFTP is over ssh and is far more secure than rest-server.

These days, the disks are usually encrypted via full disk encryption in most operating systems. Even if the key leaks, the SFTP access with the above setup only provides access to backups.

1 Like

This is not true. The access is limited to SFTP and doesn’t include ssh.

Sorry I made quick assumptions from what I’ve seen are the most common setups :bowing_man:

In your case you probably don’t need to try rest-server

I haven’t properly tested this a long time, but when I was picking between back-ends a few years back, SFTP was markedly slower than REST server, or local S3 (minio). FWIW I opted for the REST server in the end, because the CPU usage on the server was lower than minio.

I believe recent restic versions have much better SFTP performance, but there are still relatively recent reports of SFTP being slower than desired (e.g. Testing Restic with ~4TiB Data), so I’m honestly not sure what the current “state of play” is.

In my humble opinion, there is no substitute for actually testing a representative data sample in your own environment, as your hardware is likely to be bottlenecked in places mine isn’t, and vice versa. That is really the only way to know if it is worth the effort of migrating back-ends :slight_smile:

As an aside, this confused me:

SFTP is over ssh and is far more secure than rest-server.

The REST server back-end can use https for the connection, which is the same TLS encryption as used in SSH/SFTP surely?

1 Like

Encryption and signature algorithms are the same, typically ECC (often based on curve 25519) and RSA, everywhere. The protocols and software differ.

You can’t say Wireguard or SSH is as secure as a web server.

If TLS version is forced to be 1.3 on both ends, the protocol will be highly secure. The vulnerabilities usually lie in http server, in this case REST-server.

It might be a concern only if the server is publicly accessible.

FWIW, since restic 0.17.0, the SFTP performance has been very much improved, to the extent that one should no longer feel that SFTP is a slow or second class backend in restic :slight_smile:

1 Like