resticprofile is a GPL-3.0 configuration profiles manager and scheduler for the restic backup tool, written in Go, intended for administrators and teams who run restic jobs on a schedule and want those jobs described in a configuration file rather than reconstructed from command-line history.

What it is

resticprofile describes itself as the missing link between a configuration file and the restic backup command line. It lives in the restic ecosystem as a wrapper and orchestration layer: it reads one configuration file, resolves a named profile, and turns it into the corresponding restic invocation, so command parameters and environment variables no longer need to be remembered or repeated. Multiple profiles can coexist in a single configuration file, profiles can inherit options from other profiles, and a group of profiles can be run sequentially. Template syntax is available inside the configuration, and the file itself can be written in TOML with the .toml or .conf extension, JSON with .json, YAML with .yaml, or HCL with .hcl.

The concrete problem it solves is that restic is a command-line backup tool with no profile system and no scheduler of its own. Without a layer like this, an operator ends up hand-writing shell wrappers and cron entries for every repository, forget policy, and pre-mount step, and loses consistency between hosts. resticprofile replaces those ad-hoc wrappers with declarative profiles, and adds scheduling through systemd, crond, launchd, or the Windows Task Scheduler directly from the same configuration. It also folds in the recurring housekeeping that normally surrounds a backup: running forget under a retention section before or after a backup, checking a repository before or after a backup, clearing stale locks automatically, and running shell commands before or after a profile, which is useful for mounting and unmounting backup disks.

Key capabilities

• Profiles with inheritance, plus groups of profiles that run sequentially; group scheduling is available in configuration v2 as of v0.29.0.
• Scheduling through systemd, crond, launchd, and the Windows Task Scheduler, driven from the same configuration file that defines the backup.
• Configuration in four formats: TOML (.toml or .conf), JSON (.json), YAML (.yaml), and HCL (.hcl), with template syntax supported in the file.
• Automation hooks: run the forget command before or after a backup via the retention section, check a repository before or after a backup, run shell commands before or after a profile, run a shell command on error, and send a backup stream via stdin.
• Monitoring output: a simple status file for monitoring software, a Prometheus file exported after a backup or pushed to a push gateway, resticprofile logs forwarded to a syslog server, and HTTP hooks before and after successful or failed jobs for backup, forget, check, prune, and copy.
• Pre-flight checks: verify enough memory is available before starting a backup, and avoid scheduling a job when the system is running on battery.
• Process control and utilities: start restic at different priorities using Priority Class on Windows, nice on Unix, and ionice on Linux; generate cryptographically secure random keys for a restic key file; initialize a secondary repository with the copy-chunker-params flag; prevent the system from idle sleeping; and view help for both restic and resticprofile through the help command or the -h flag.

Who uses it and how

• Linux system administrators who schedule backup, retention, and check jobs as systemd units or crond entries instead of maintaining separate shell scripts per repository.
• macOS and Windows operators who need the same declarative profiles expressed as launchd agents or Windows Task Scheduler tasks, using the platform scheduler rather than a replacement daemon.
• Teams running observability stacks: the Prometheus export, push gateway support, syslog forwarding, and JSON status file suit environments already collecting metrics in Prometheus and Grafana.
• Configuration-management workflows, reflected in the project's Ansible and automation topics, where profiles are deployed to many hosts and scheduled identically.
• Operators who need pre- and post-job behaviour — mounting a backup disk, unmounting it afterwards, running a command on failure — expressed in the same file as the backup definition.

Getting started

The README excerpt available here recommends proceeding to the project documentation but is truncated before it names an exact install command, package, or container image, so the authoritative install and run instructions are the documentation site at https://creativeprojects.github.io/resticprofile/. The project is written in Go and is distributed as a resticprofile binary that wraps the separately installed restic executable.

How it compares

No list of paid products replaced by this project is provided in the facts, so the honest comparison point is the tool it wraps: restic itself. resticprofile does not replace restic and cannot back anything up without it — it sits above the restic command line as the configuration, scheduling, and monitoring layer, leaving storage format and encryption to restic. Anyone evaluating it should therefore treat it as an addition to an existing restic deployment rather than an alternative to one.

When to use it — and when not to

A self-hoster must already run restic and must be willing to operate the surrounding machinery this project generates or integrates with: systemd units, crond entries, launchd agents, or Windows scheduled tasks, plus whatever HTTP hook endpoints, syslog server, or Prometheus push gateway the monitoring features point at. It is a poor fit for anyone who does not use restic, for anyone wanting a standalone backup product with its own repository format, or for shops unwilling to accept the GPL-3.0 licence. The registry facts also show 99 open issues, and the README excerpt supplied here is sparse on installation detail, so a prospective user should read the documentation site before committing to a rollout.