cplieger/docker-rsync-scheduler repository overview

⁠docker-rsync-scheduler

docker-rsync-scheduler copies chosen folders from your Docker host to a NAS or another server over SSH, on a schedule you set. It pushes one way only and keeps no older versions.

⁠What it does

docker-rsync-scheduler keeps an up-to-date copy of your folders on a NAS, a backup box or another server:

• Pushes each folder you list with rsync over SSH, every 6 hours by default or on the interval you set.
• Can mirror deletions too, with a cap on how many files one pass may delete.
• Skips a folder that is empty when a pass starts, so a source drive that failed to mount does not wipe the copy.
• Shows a failed job as an unhealthy container, until the next clean pass.

⁠Who it is for

docker-rsync-scheduler is built for pushing folders from a Docker host to a machine you reach over SSH, without writing cron jobs and rsync options by hand. Each job is a few lines of YAML, checked before the container starts.

You need a remote machine with rsync installed, an SSH key it accepts and a folder to write to.

Two other kinds of tool suit a different need:

• Consider Syncthing⁠ if you want folders kept in sync both ways between devices, set up from a web page.
• Consider restic⁠ if you want backups as snapshots you can list and restore.

docker-rsync-scheduler is free software under the Apache-2.0 license.

⁠Pull

docker pull cplieger/docker-rsync-scheduler:latest

Also published to ghcr.io/cplieger/docker-rsync-scheduler with identical images and tags. Release versions are tagged vX.Y.Z alongside latest.

⁠Quick start

# Example compose for docker-rsync-scheduler. See docs/configuration.md and docs/hardening.md for all configuration options and hardening.
services:
  rsync:
    image: ghcr.io/cplieger/docker-rsync-scheduler:latest
    container_name: rsync
    restart: unless-stopped

    environment:
      SYNC_INTERVAL: "6h"  # time between passes, or "off" to trigger passes from another scheduler
      SYNC_TIMEOUT: "10m"  # how long one job may run before it is stopped and counted as failed

    volumes:
      # Copy config.example.yaml to config.yaml and list your jobs before the first start.
      # Its first job deletes remote files that are gone from the source. To keep them, remove its "delete: true" line.
      - "./config.yaml:/config/config.yaml:ro"
      # Create a dedicated key with ssh-keygen and add id_ed25519.pub to authorized_keys on the remote.
      # The remote needs rsync installed.
      - "./id_ed25519:/keys/id_ed25519:ro"
      - "./data:/data"  # keeps the schedule across restarts, recreates and image updates
      # One read-only mount for each source folder a job in config.yaml pushes
      - "/srv/source/certs:/sources/certs:ro"
      - "/srv/source/appconfig:/sources/appconfig:ro"

⁠Documentation

• Full documentation⁠ — configuration, behavior, security
• Configuration⁠
• Security⁠
• How docker-rsync-scheduler works⁠
• Monitoring and alerts⁠
• Contributing⁠
• Releases and changelog⁠

⁠License

Apache-2.0. See LICENSE⁠. The image carries the license text of every bundled component under /usr/share/licenses/. The Alpine packages in the image ship no license file upstream, so their license texts are kept under licenses/ in this repository and copied in.

The bundled component is rsync itself, which is GPL-3.0-or-later. The build fetches the pinned release tarball https://download.samba.org/pub/rsync/src/rsync-<version>.tar.gz, at the version the RSYNC_VERSION argument in the Dockerfile pins, verifies the detached upstream signature and then the pinned SHA256, and applies no patches to the extracted source. rsync's own COPYING travels in the image at /usr/share/licenses/rsync/COPYING, and the upstream project is RsyncProject/rsync⁠. That tarball and this repository's Dockerfile are the complete recipe for the rsync binary in the image, which is how anyone who receives it gets the corresponding source.