// the find
creativeprojects/resticprofile
Configuration profiles manager and scheduler for restic backup
resticprofile is a Go binary that wraps the restic CLI, so backup settings live in one TOML, YAML, JSON, HCL or conf file instead of shell scripts full of flags and environment variables. It also schedules runs through systemd, cron, launchd or Windows Task Scheduler, which suits people who run restic on several machines and want the configuration kept in one place.
- The CI matrix covers Linux, macOS, Windows, OpenBSD, FreeBSD, NetBSD and an SSH client test. That is more platform coverage than most Go backup tools bother with, and it matters for a tool that often runs as root from a cron entry.
- Profiles can inherit from each other and groups can run sequentially, so a shared retention block is written once rather than copied into every machine's file.
- Monitoring is practical: a status file for monitoring tools, a Prometheus export or push gateway, per-job HTTP hooks and syslog. The status file is a sensible way to check backup freshness without running another agent.
- The config schemas are published as JSON schema for both v1 and v2, so an editor can flag a bad profile before a scheduled run fails overnight.
- This is a thin layer over the restic binary, so its behaviour depends on which restic version is installed. The README does not say which restic versions are supported or how the two are kept in step.
- Two configuration dialects are in play, v1 (config/config_v1.go) and v2 (docs/content/configuration/v2.md), each with its own schema. Anyone migrating has to check their files against the right one, and the code carries both paths for as long as v1 is supported.
- The tree includes FUSE mount, battery detection and sleep prevention alongside scheduling and backup logic. That is a wide surface for one Go binary, and each platform-specific piece is a place where behaviour differs.
- Scheduled runs inherit the quirks of each backend. systemd timers, crond, launchd and Task Scheduler all handle missed runs and failures differently, and the README does not explain those differences.