borgmatic
shoyu.borgbackup
Configuration-driven front end for BorgBackup that runs deduplicated, compressed, encrypted backups on a schedule, adding retention pruning, consistency checks and database dumps.
A Docker Compose file for borgmatic alone, generated from the catalog and checked by the safety inspector. Sign in and use Kitchen Credits to activate it.
Uses the Medusa cart and payment-session path. This test control does not create an order or capture payment.
Borg deduplicates at the chunk level across every archive in a repository, so successive backups store only what changed while each archive still restores as a complete tree, with client-side encryption meaning the repository host never sees plaintext. borgmatic wraps that in a single YAML file declaring source paths, repositories, retention rules and verification checks, replacing the shell scripts that usually accumulate around Borg. It dumps PostgreSQL, MySQL, MongoDB and SQLite databases into the archive consistently rather than backing up live data files, and reports outcomes to monitoring services. A first deployment initialises a repository, runs one backup and verifies it.
You know it worked when
- The configuration file validates without errors.
- A repository initialises and the first archive completes.
- A second run transfers noticeably less data than the first.
- A consistency check reports the repository and archives intact.
- A test file extracted from an archive matches the original.
Known sharp edges
- The repository passphrase or key is the only way to read the archives, and losing it makes every backup permanently unrecoverable.
- A repository is designed for a single client, and concurrent access from two machines locks or corrupts rather than queueing.
- Retention pruning is destructive and applies immediately, so an over-aggressive keep policy silently deletes archives that are still needed.
- Backing up live database files rather than using the database hooks produces archives that restore into an inconsistent state.