I bought a NAS (Qnap TS-231P) which I want to use for backing up two Windows PCs regularly. In order to be on the safe side if a crypto trojan hits those PCs I don’t want to connect the NAS via SMB because I think this will make it impossible for the trojan to access the backup files.
The idea is to use either ftp or sftp and give the necessary credentials only to the process that runs when creating the backup. Depending on if I use ftp or sftp this is either directly supported by restic or I need the REST server which creates an (theoretical) attack surface.
My main concern is: how “efficient” is (s)ftp in contrast to SMB ? Is this “better” or “worse” than SMB ? I can imagine that SMB could be better because one can position relative positions of a file, for (s)ftp this could be difficult. But because I don’t know how restic works internally I can not judge if this a valid point or not.
Welcome to the forum. Both SMB and SFTP are able to selectively read parts of a file, thus there’s no difference there. Depending on how fast the CPU of your NAS is, file transfers might be slowed done by the encryption used for SFTP.
How would sftp prevent an trojan from deleting your backup files? If a trojan tampers with restic during a backup run, then it could also wipe the backup over sftp. (Yes it’s more likely that crypto trojans for Windows just care about SMB shares and don’t go hunting for specific backup program, but it’s still a relevant risk).
To be safe from crypto trojans, you want an append-only backup, which by definition would prevent a trojan from deleting it. The are currently two options to setup such a backup repository: Either with rclone, see https://forum.restic.net/t/append-only-backups-via-ssh-using-rclone/1456 or using the restic REST server with the --append-only flag.
You refer to the append-only backup part? Maybe, if SMB allows you to set the permissions for a user such that they can only create new files and write them only a single time (except for the locks folder, where that user also needs the delete permission). But I’m not familiar enough with the SMB ACLs to know whether that’s possible.
Just use rest-server - it should perform much better than SMB or SFTP, and as @MichaelEischer mentioned you can use the --append-only feature of rest-server to only allow your clients to back up but not delete anything from your backup repositories. It’s a no-brainer (assuming your NAS can run it)
Thanks, I found a rest-server package for my qnap device.
During my investigations I found rclone which also implements the restic REST API, can be installed in qnap NAS too and supports the local filesystem of the NAS as a target.
Do you know both approaches and could you compare them and advice which to use ?
Where/what did you read that rclone supports the restic REST API?
I’m only aware that restic can use rclone as a backend, which enables you to use restic with any of the backends that rclone support.
I’m not aware that rclone can act as a backend to restic in such a way that restic sends backups to rclone over the wire, and rclone then writes that down to a local repository. I believe rclone has to exist alongside restic, not on a remote host.
I would go for setting up rest-server on the NAS and use that as the remote backend from restic directly.
There’s also the possibility of using Minio to create an S3 backend, but I don’t think it has an append-only mode.
Rclone can indeed be used with the rest backend, exactly the same as our own rest-server. In addition, rclone also supports a special version of the REST backend over stdin/stdout, which we use in our rclone backend for restic (where we call rclone and talk to it via stdin/stdout instead of over the network).
Hello Alexander,
can you make this comparison between rest-server and rclone ? rest-server seems to be so stable that is didn’t need a fix in the last two years. I found packages for my Qnap NAS for both rest-server and rclone.
Which would you use to have a more “crypto trojan safe” solution with a readonly backup archive / repo ?
It’s mostly he same code, rclone imports and uses he code from the rest server. The main difference is that all the code around the core protocol (tls support, authentication etc) is probably much better maintained by rclone…
There is a third option, wich is using a minio backend and setup “s3:ListBucket”,“s3:GetObject”,“s3:PutObject” permission on the bucked (no delete), and full permission on the “locks” subdirectory.
