Restic runs in a cron job via sudo crontab -e.
Any security downside?
I don’t know exactly what a restic binary can do as root.
I think it comes down to your security requirements. I do trust restic to be well written and tested and it supports being executed as root. But in general you should follow the
“least possible privileges” approach whenever possible.
If there is a bug in restic an attacker might try to exploit it to gain root access on your system.
Supply chain attacks could also target restic via dependencies or infected build environments (there are reproducible builds available, but not every user might compile on their own to validate signatures).
Finally, there is a human factor, if someone takes over a critical github account, e.g. by phishing or blackmail or insecure secrets, infected binaries could be published.
With Linux capabilities there is a way to grant only a subset of root’s permission to a given user.
This reduces the attack surface quite a bit, for a critical production system I would do that hardening steps as described in
On the other hand, if you try to convince a friend to run backups of their private workstation, I would not add this as a conversation starter 
1 Like
Be aware if you run Restic as root, and do anything involving the cache - if you try to run Restic NOT as root, it may complain about the cache not being accessible. You can either fix permissions on the cache or just delete the cache folder to get it to work again. Or just always run as root, of course.
Only issue I’ve ran into 