Versatile, flexibly configurable wrapper & automation tool for BorgBackup & Snapper
Find a file
2025-10-14 11:52:04 +02:00
.gitea initial pub 2025-08-26 00:41:14 +02:00
.github add util note to README 2025-09-25 15:16:43 +02:00
bin bumped version, upd changelog 2025-10-14 11:52:04 +02:00
docs bumped version, upd changelog 2025-10-14 11:52:04 +02:00
etc add 'resnap' handling 2025-10-02 16:00:12 +02:00
systemd initial pub 2025-08-26 00:41:14 +02:00
util initial pub 2025-08-26 00:41:14 +02:00
.gitignore . 2025-08-28 19:17:02 +02:00
LICENSE initial pub 2025-08-26 00:41:14 +02:00
README.md add util note to README 2025-09-25 15:16:43 +02:00


SnapBack

A versatile, flexibly configurable wrapper & automation tool for
BorgBackup & Snapper


Features

  • Unified job concept for both archiving and (btrfs) snapshot purposes
  • Archiving from paths, own (transient or persistent), or existing btrfs snapshots
  • Archiving with configurable path prefixes
  • Supporting multiple repositories, and mixed BorgBackup versions
  • More flexible snapshotting than with common Snapper automations
  • Adjustable pruning/cleanup logic for archives & snapshots
  • Simple job scheduling using OnCalendar event specification format
  • Versatile individual job selection, for immediate, undefined, or timed (at-alike) processing
  • Automated backlogging of incomplete jobs after failure or signals
  • Status overview
  • Optional systemd timer setting from configured schedules
  • Optional temp. automounting
  • Hooks for custom scripts pre/post all essential operations
  • Optional status notifications at end of runs (D-Bus and/or custom script)
  • Flexible, YAML based configuration
  • Minimum overhead, small footprint
  • Few dependencies
  • ...
  • and the documentation got the words Don't Panic! on it!

Requirements

  • Linux (developed and primarily tested with Debian 12/13)
  • bash v5.0 or later, 5.1+ recommended
  • common basic utilities (for Debian: packages coreutils, hostname, libc-bin, ncurses-bin, procps, util-linux)
  • yq v4.44 or later (Mike Farah's standalone one, not the eponymic jq wrapper), 4.47+ recommended
  • for job scheduling:
    • systemd-analyze   ◀systemd
    • or a compatible replacement for its calendar command
  • for archiving:
  • for snapshots:
  • for desktop notifications:
    • D-Bus environment
    • notify-send utility   ◀deb:libnotify-bin

Note

A systemd environment is not absolutely required, but strongly recommended.
Some features are otherwise not available, and unless you really want to do without job scheduling, you need to find a compatible replacement for systemd-analyze calendar.

Downsides

  • Needs root privileges for meaningful operation.
  • Does not come with a GUI, but requires you to properly configure what you want it to do, using YAML.
  • Supports archiving only with BorgBackup.
  • Supports snapshotting only with BTRFS filesystems, and only in Snapper fashion.
  • Does not handle all Snapper features, like pre/post snapshots, and is not planned to ever do so.
  • Does not give any help mangling with Snapper configurations.
  • Facilitates only creation & maintenance of snapshots & backups, and does not by itself help with restoring from or doing other things with them.
  • Requires Borg repositories to exist ready for use, and does not help with any repo maintenance beyond compacting.
  • Author is an aged, grumpy diva.

Documentation 🞂

Installation 🞂

Changelog 🞂

Special Notes

btrfs Utility

When this is present, SnapBack does not have to rely on Snapper all too much, and can avoid some troubles.
E.g. the common Snapper OBS builds for Debian lack rollback support, and do thus not indicate if a snapshot is a default one, which may result in pruning failures.

BorgBackup v2 Notes

Important

  • Support for the upcoming v2 is currently still EXPERIMENTAL.
  • v1 repos require manual migration.

The good news, as far as SnapBack is concerned: Don't Panic!

  • It (hopefully) handles most things automatically, dep. on the used client's version.
  • Archive names for v2 repos are clearly recommended to be configured in "new" (and simpler) fashion, but it also accepts the "classic" v1 way w/o making Borg unhappy.
  • No need to migrate everything in one run: repos may be version tagged for selecting from different Borg executables.