Restic is a static binary, so I wonder if you drop it in a synology NAS DSM in /usr/bin/restic, and it would work without breaking the DSM.
A more complicated way is restic in a Docker container.
How do you guys run restic on synology?
I don’t see a reason why this would break the Synology software. This should just work. You might have to tweak some things regarding the cache directory location but other than that, I can’t think of things.
It’s worth searching the forum for posts regarding the usage of Synology 
I’m using it - even on the shittly old DS214play … self-compiled for i686 (x86)
Only thing you’ll have to manage is make the garbage collector more aggressive export GOGC=1 and take care of tmp-folder mountpoint - if you’re running it with very limited resources (~512MB here).
I did formerly back up the whole NAS to GDrive with that … roundabout 2 TiBs only tought …
Or better said I used to - because nowadays I use it simply as a target for the rest-server now
Both of them work totally fine - never had any issue with them!
2 Likes
I guess then running the static binary is very similar to using Restic docker container.
Yes just without the overhead and permission issues of docker
Tought, like I said, you might need to compile it yourselfbecause some dependencies like glibc are not statically linked by default Golang design principals.
Depending on the DSM Version you might have to compile it with a statically linked glibc (because Synology is most of the time using a reaaaaally old version of glibc by the time they release a DSM Version).
If you need help with that just respond here and I’ll look up the commands needed on my build machine so that you have a really portable restic binary without any external dependencies.
Thanks a lot for your help, much appreciated!
You raised an important point that restic binary is not completely standalone and still has some dependency, eg, glibc. Any other dependency?
I raised this question here, that if I backup the data with restic, and back up restic binary, if I will be able to unlock the repository in the future. It seems, maybe not, since glibc version might advance in the future and be not backward compatible.
You can find that out by using ‘ldd restic’ on something like Ubuntu.
glibc is something that is usually deeply tied to the operating system that rarely changes unless across majors or in a Rolling Release distro over a longer timespawn.
It’s a really old discussion more or less pointing to the underlying linux/gnu-stack.
The only way to really have a rollback machine is by creating a VM that you snapshot and freeze - never update and stash away multiple times to prevent bitrot issues from hunting you.
Well or even better an OS install that you do this to, so that you’re not reliant on any hypervisor too …
I am running restic with rclone on a ds923+. It works totally fine, I push my family photos to OneDrive which offers 1TB as part of my Microsoft 365 membership which I would not use otherwise.
I use the Synology Task Scheduler to run restic, as it notifies me on failed script execution via email.
One issue I came across was the non-standard partition layout, DSM on my system only had a 2.3GB rootfs mounted to /. The raid array was mounted to /volume1, you can easily see what is mounted by running df -h.
Therefore, I placed the restic binary in /volume1/homes/konrad/.local/bin/restic, extended my PATH variable and also exported a few other variables into .bashrc:
export PATH=$PATH:/volume1/homes/konrad/.local/bin
export RESTIC_CACHE_DIR=/volume1/homes/konrad/.cache/restic
export RESTIC_REPOSITORY=rclone:onedrive:/backup/synology
export RESTIC_PASSWORD_FILE=/volume1/homes/konrad/.restic-password.txt
The task scheduler runs the backup as root, to prevent missing permission problems on certain folders, but if you just backup data, user permissions are usually fine.
#/bin/bash
set -xe
source /volume1/homes/konrad/.bashrc
export RESTIC_CACHE_DIR=/volume1/homes/konrad/.cache/restic-root
restic version
restic backup \
--exclude /volume1/data/fotos/user/HandyBackup \
/volume1/data/fotos/ /volume1/data/daten/
restic forget -d 7 -w 4 -m 3 --prune
Note: I overwrote the cache folder for the root user again to prevent access problems of the cache used by a non-root user.
Additionally, I run a backup validation job every Sunday, also triggered by the task scheduler which also sends me an email with the job results.
This validation job looks like:
#/bin/bash
set -xe
source /volume1/homes/konrad/.bashrc
restic version
restic check --read-data-subset 10G
restic stats
restic snapshots
It does not restore the entire data set, as this would cause significant traffic, but fetches 10 GB and validates the metadata of the repository.
It is not my only backup (I also use Hyperbackup from Synology to another NAS), so I am fine with a bit of risk here, anyway, a full restore from time to time would be a good idea.
I thought that extending the 3-2-1 rule would be a good idea, so in addition to the usual criteria, I also don’t rely on a single backup software. Even if it’s not really likely that Synology goes out of business or drops its backup software, I still think having an open format which still offers compression and encryption is a plus. The reason why I am not running restic only is, that Synology describes standard procedures to administer its systems with its own tools. In case my wife/family needs to restore a backup and I am not around, they could still just google/call a tech-savy person and use the standard tools. Also, Hyperbackup offers a UI out of the box and is integrated into DSM, so you can login into the WebUI and download old revisions quite easily, if you need to.
Hey konrad, going back to a really basic question here from your answer - which binary did you use for restic? Did you just place it into your volume that you created here, or do you use a docker container?
I used the amd64 binary directly on the host and placed it on volume1, I put it into /volume1/homes/konrad/.local/bin in that example, but other folders are ok as well, just ensure to set the RESTIC_CACHE_DIR to a location with enough space available.
Docker would work as well, but as the golang binaries are already quite portable, I did not see a need of adding more indirection via docker.
In the meantime I switched to using resticprofile instead of pure restic with scripts, the config file format looks quite nice and it can handle scheduling via systemd which also works on Synology DSM.
1 Like
Awesome! Does the AMD64 binary work across all synology models or does it change? I’m asking because I know the 7series has a different Linux distro than the 220+ I’ve got.
It should work for all models which ship an x86_64 processor, the DSM version should not matter much as the go binary is pretty self-contained. That being said, I did not test it on DSM 6, only on DSM 7.
The + series should use the x86_64 processor architectue, there are also arm-based CPUs e.g. in the j series, those would require a different binary.
1 Like