restic-automatic-backup-scheduler: scheduled restic backups on any OS

Restic does the backups, the operating system does the scheduling

restic is a command-line backup tool, and the author describes it as the right way to make backups. The gap this project fills is not backup capability but scheduling. As the intro puts it, restic does not come pre-configured with a way to run automated backups, say every day, but it is possible to set that up yourself using built-in tools in your OS and some wrappers.

That is the whole idea. restic does the deduplication, encryption and snapshot work, Backblaze B2 does the storage, and the operating system scheduler does the timing. No daemon, no agent, no server, no panel. The README recommends B2 as the storage backend, noting that restic works well with it and that it is affordable for a hobbyist, with an anecdotal note that a full-systems backup costs less than one US dollar per month for the author.

The project was formerly named restic-systemd-automatic-backup, and the rename is the first clue to the current shape. It is not a systemd project any more. There are separate setup paths for Linux with systemd, macOS with a LaunchAgent, Windows with a ScheduledTask, and plain cron for any system with a cron daemon, described as tested on FreeBSD and macOS. The description in the repository metadata says exactly that, and the topic tags cover cron, launchagent, scheduledtask, systemd, systemd-service, systemd-timer and the rest.

The audience is a person with one machine, or a homelab, who wants backups that run without them thinking about it and whose backup setup they can still read. The stated aim is a hackable code base to start from, and the project says so directly: the scope is not to be a full-fledged super solution that solves all problems and all possible setups.

The primary language is Shell, the licence is BSD-3-Clause, and the repository has no GitHub releases at all.

Four setup paths, one script underneath

The setup section of the README branches on the platform, and the four branches exist because each scheduler expresses the same two ideas differently. A backup job needs a definition of what to run, and a trigger that says when to run it.

On Linux with systemd, that means a service unit and a timer, and the install target is named for it:

   $ sudo make install-systemd

On macOS the equivalent is a built-in LaunchAgent, and the README provides a target for it. On Windows it is a ScheduledTask, which lives in a ScheduledTask/ directory in the repository alongside the shell scripts. For anything else with a cron daemon, there is a cron setup, and the make target list confirms the four install paths as install-systemd, install-cron, install-targets-launchagent and install-targets-schedtask.

The make file also exposes finer-grained targets that separate installing the scripts from installing the configuration, and separate activation from deactivation for the macOS launch agent, with activate-launchagent-backup and deactivate-launchagent-backup among them.

The consequence for an operator is that switching platforms does not mean rewriting your backup. The restic invocation and the profile stay the same, and only the scheduler glue changes. That is the property that makes the project useful across a mixed fleet, and it is why the same repository can carry systemd units, a LaunchAgent plist and a Windows scheduled task side by side.

The one sharp edge visible in the target list is a typo: the target deactivate-launchagent-chec is missing the final k of check, while its counterpart deactivate-launchagent-check is spelled correctly. If you script around that target, spell it exactly as the make file does.

The make install rewrites paths with a placeholder

The install machinery is more considered than a plain file copy, and the make file explains why at length.

The build runs in three stages and is described as an out-of-source build. First the source files are copied to a local build directory. Second, in that build directory, the string "{{ INSTALL_PREFIX }}" is replaced with the value of $PREFIX. Third, the files are installed from the build directory to the target directory.

The reason given is that supporting a custom install path, with an example of $(PREFIX=/usr/local make install), requires modifying the files that refer to other files on disk, and the way to do that without dirtying files controlled by git is to substitute a placeholder during the build. The substitution step itself is a single line in the notes:

# 2. build dir: replace the string "{{ INSTALL_PREFIX }}" with the value of $PREFIX

That is the kind of detail that separates a script you can install at an arbitrary prefix from one that assumes it lives in a fixed place, and it matters for people who do not want a backup tool spread across a dozen directories in /etc.

The make file also handles the fact that GNU install and the macOS version of install take different arguments. It probes for GNU install, and if it is present it uses a suffix option for backups, otherwise it uses the BSD style backup flag, and in both cases the timestamped copy is left behind rather than the original being overwritten. On a machine where a previous profile was customised, that backup file is a lifeline.

Requirements are modest and stated up front: restic at v0.9.6 or newer, bash at v4.0.0 or newer, and GNU make if you want the automated install, which the README notes is part of base-devel on Arch, part of build-essential on Debian and Ubuntu, and available on macOS through the pre-installed version or Homebrew.

Where the restic arguments live and how to change backends

The README is explicit that Backblaze B2 is a recommendation rather than a requirement. You can use any of restic's supported storage backends, and the setup should be similar, but you will have to use other configuration variables to match your backend of choice.

The instructions for making that change are precise: to use a storage backend other than B2, you should only need to tweak a few settings variables in the backup profile, as well as some restic arguments inside restic_backup.sh.

So there are two places to touch. The backup profile holds the configuration variables, which is where the credentials and repository location live, and the script holds the restic command line, which is where flags that do not fit neatly into a variable belong. That separation is a deliberate choice to keep the common case, changing a backend, to editing configuration rather than shell code, and it is also a reasonable thing to review before you let a script run as root with your backup credentials in the environment.

The repository layout supports the same picture. There is a bin/ directory for the executables, etc/ for configuration, scripts/ for the shell logic, Library/ and ScheduledTask/ for platform-specific pieces, plus a Makefile at the root and a CHANGELOG.md. A.devcontainer/ directory is present for development in a container, and a.semver.yaml file for version metadata.

The topic tags also include email-notification, which points to the backup being able to report on itself by mail. The README excerpt does not show how that is configured, so if you need failure notifications, that is a detail to read in the repository rather than assume.

Feature complete, which is both the appeal and the limit

The project scope note carries an explicit update: this project is feature complete, only bug fixes will be accepted, and contributors are free to fork if they want to add more features, because being a forking base was the initial scope.

That is unusual to find stated plainly, and it changes how you evaluate the repository. A project that has declared itself done is not going to grow a plugin interface, a dashboard or support for a new scheduler. What you get is a stable, small, readable base that you are expected to modify yourself if your requirements go beyond it.

For most single-machine backup use cases, that is exactly the right trade. The scripts are short, the configuration is a profile, and there is no service to monitor beyond restic itself. The maintainer accepts bug fixes only, which in practice means the code stops moving except when something breaks, and a repository in that state is easy to reason about over a long period.

The counter-argument is scale. There is no central management, no reporting across machines, no policy engine, no key management story, and no notification configuration documented in the README. If you have thirty hosts, you are running this on thirty hosts, or you are writing something else.

Packaging reflects the same pragmatic scope. There is an AUR package for Arch Linux, with both a version badge and a maintainer badge, and a Homebrew formula in the maintainer's own tap, erikw/tap. Neither is a distribution channel in the package-registry sense; they are conveniences for two specific platforms that the author also develops on.

Where this scheduler is the wrong tool

The first case is the one the project itself names. If you want a solution that covers every setup and every requirement, this is not it, and if you need someone else to add features, you will be forking.

The second case is multi-host orchestration. The repository has no mechanism for a fleet: each installation schedules its own local job, and there is no server collecting status. Comparing a self-hosted script like this with a managed backup product is a category error, but the comparison people actually make is usually with a commercial agent that reports into a dashboard.

The third case is a backup that has to be verified and restored automatically. The scripts run restic; the README excerpt does not describe a prune policy, a check command, or a restore test, and the topics list does not mention them either. If your requirement includes a routine verification that the repository is actually restorable, that has to come from somewhere else.

The fourth is the credential question. Backing up to B2 means the script runs with the credentials to your backup bucket, which usually means running as root, which the install command reflects with sudo. Whether those credentials live in the profile, in the environment or in a restic key file is exactly the kind of thing you want to read in the repository before pointing it at a machine that holds anything you care about.

One more practical point. Because there are no GitHub releases, version tracking is done by tags and the CHANGELOG, and the AUR and Homebrew channels pin their own versions. If you install through a package manager you get that channel's idea of the current version, and if you install with make from a clone you get whatever branch you checked out.

Editorial conclusion

Adopt restic-automatic-backup-scheduler if you want a readable, small set of scripts that run restic on a schedule you control through the scheduler your operating system already provides, and you are willing to maintain the backup profile yourself. Do not adopt it if you need a managed backup product, multiple machines, or a feature roadmap, because the project states it is feature complete and only bug fixes are accepted. Verify first that your restic is at least v0.9.6 and your bash at least v4.0.0, that the backup profile matches your chosen storage backend rather than the Backblaze B2 default, and that you can read the scripts before they run as root, since the licence is BSD-3-Clause, the repository has no GitHub releases, and the last push was on 2026-08-27.

Frequently asked questions

Official sources

1. erikw/restic-automatic-backup-scheduler on GitHub
2. Issues
3. License: BSD-3-Clause
4. README