Restic Docker Container Scheduling

Getting Help
1

My question: Does anyone have a technique to automate the daily scheduling of backups using the official restic container image that they can share?

My problem:
I have a Docker container that is set to run continously based on the official restic docker image. If I run the restic commands in the container, I can manually backup from one local folder to another local folder. Everything is working except I have to manually log in and run the portainer command. However, I’m not sure how to get the backup command or any commands inside the restic to run on a schedule. The container did not seem to have an internal crontab or something like that.

What I tried:

I’m not sure how to get the backup command or any commands inside the restic to run on a schedule. The container did not seem to have an internal crontab or something like that. Unfortunately, my ASUSTOR NAS unlike other NAS units has no ability to schedule jobs. I tried using crontab by cracking into the underlying OS but that did not work and I would prefer a pure container solution and that config would be wiped without warning if there was an update, so not a great solution, and it did not work for me. I also tried setting up a side car container to send commands but was not successful and that involves giving root access or something like that which seems insecure, but in any case could not find a container image that would do the job securely.

Details:
The restic version is the latest in hub.docker.io, currently 1.80.

Workflow:
Here is my complete workflow for setting up my persistent restic container for (so far) only manual backup jobs.

Creating a restic container for local backup

Phase 1: Creating the Restic “Service” Container in Portainer

We went to Containers → + Add container and configured the following settings:

  1. Name and Image:
  • Set the Name to Backup-OneDrive-Restic-Local-User1.
  • Set the Image to restic/restic:latest.
  1. Command and Entrypoint:
  • In the “Command & Logging” tab, we overrode the Entrypoint to be sh and the Command to be -c 'tail -f /dev/null'.
  • Purpose: This was the crucial fix to make the container run a command that keeps it alive and idle, ready for our instructions.
  1. Volume Mapping:
  • In the “Volumes” tab, we created two Bind mounts to connect folders inside the container to your real folders on the NAS.
  • Source: Mapped the container’s /source path to your NAS’s /volume2/Sync_OneDrive_User1 path.
  • Destination: Mapped the container’s /backup path to your NAS’s /volume2/Backup_OneDrive_User1 path.
  1. Environment Variables:
  • In the “Env” tab, we set two variables to automatically configure restic.
  • RESTIC_REPOSITORY was set to /backup, telling restic which container path to use for the backup.
  • RESTIC_PASSWORD was set to your secret password, so you never have to type it in a command.
  1. Restart Policy:
  • In the “Restart policy” tab, we set the policy to Unless stopped.
  • Purpose: This ensures your backup container will automatically start if you ever reboot your NAS.
  1. Deployment: You clicked Deploy the container, which created and started the service based on all these rules.

Phase 2: First-Time Initialization and Manual Backup

  1. Connected to the Container: We used Portainer’s Exec console feature to open a command prompt inside the running container, making sure to use the correct /bin/sh shell.
  2. Initialized the Repository: Inside the console, you ran the one-time command restic init.
  • Result: This created the necessary file and folder structure for a restic repository inside your /volume2/Backup_OneDrive_User folder.
  1. Ran the First Backup: You then ran the command restic backup /source.
  • Result: Restic successfully scanned all 176 GB of your data from the source folder, compressed it, encrypted it, and saved it as the first “snapshot” in your backup repository. This took about one hour.
2

Ok I’m probably about to make a fool of myself but what exactly is the benefit of running a docker container in this case? Why not simply copy the restic binary to /usr/local/bin and then adding it to crontab (or make it a systemd service if you must)?

3 Likes
3

It is especially true for single binary file application like restic without any special dependencies. I can’t grasp this fascination with docker. Sure it can make things easier in some cases (complex solution setup with many moving parts). But for restic what it only adds is extra layer of complexity many docker fans simply do not know how to handle.

Unless it is for pure exercise and learning. But then everything goes.

1 Like