nfrastack/db-backup: Multi-Engine Database Backup and Restore

One db-backup Job Across Nine Database Engines

nfrastack/db-backup addresses the operational problem of maintaining separate backup procedures for different database systems. Its documented engine list includes MySQL, MariaDB, PostgreSQL, MongoDB, Microsoft SQL Server, Redis, SQLite3, InfluxDB, and CouchDB. The same tool can invoke its own scheduler or run from an existing script, which makes it relevant to servers, container environments, and CI pipelines.

The project does not describe itself as a database server or a replication system. Its scope is the surrounding backup lifecycle: creating backups, restoring them, verifying them, retaining them, and running maintenance operations. The README also names full, incremental, differential, and schema-only backup strategies. Table filtering can include or exclude tables, and individual tables can be marked for schema-only handling.

This breadth is the main reason to consider db-backup instead of maintaining separate wrappers. It also creates an adoption boundary. A team with one MySQL server may gain little from the multi-engine abstraction, while an organization operating several supported database types gains more from a shared configuration syntax and command surface. The repository does not publish a detailed compatibility matrix in the README, so engine and version verification should not be inferred from the list alone.

Configuration, Scheduling, and Storage Flow

The repository presents one unified configuration syntax across database engines. The container quick start represents that model through numbered environment variables such as `DB01_TYPE`, `DB01_HOST`, `DB01_USER`, `DB01_PASS`, and `DB01_NAME`. Configuration can also drive restore profiles, according to the documentation index. The README does not expose the internal parser or execution graph, so the most defensible description is a configuration layer that feeds common backup and restore operations rather than a claim about particular Go packages.

Jobs can be scheduled with cron expressions, intervals, clock times, natural-language schedules, day filters, and blackout windows. The built-in scheduler is optional because the binary can also be called from scripts. Retention is expressed through the last several backups, a time window, or tiers such as hourly, daily, weekly, monthly, and yearly. This model covers both simple rotation policies and more granular retention schedules, although the README does not specify the exact configuration syntax for each scheduler or retention mode.

Destination selection is also unified. Documented backends include a filesystem, S3-compatible storage, WebDAV, Azure Blob, and Google Cloud Storage. After a backup, db-backup can write a checksum and JSON sidecar metadata. That combination gives the storage layer material for integrity checking, but it does not by itself prove that a restore will succeed. Application-specific recovery requirements, such as coordinating related database backups, are not documented here.

Container Quick Start for a MySQL Backup

The README supplies a container-based first use. This is the most concrete installation path available in the repository text. It starts `db-backup`, supplies one MySQL job through environment variables, and mounts the local `./backups` directory at `/backup`.

Run the following command from a directory where the local `backups` path is writable:

docker run --rm \
  -e DB01_TYPE=mysql \
  -e DB01_HOST=db-internal \
  -e DB01_USER=backup \
  -e DB01_PASS=secret \
  -e DB01_NAME=testdb \
  -v ./backups:/backup \
  docker.io/nfrastack/db-backup:latest

Replace the example host, credentials, and database name with values for the target MySQL environment. The command uses `--rm`, so the container is removed when it exits. The mounted directory is the only storage destination identified in this quick start. The README does not state the exact files created by the first run or the exact progress lines printed, so verification should begin by inspecting `./backups` and comparing its contents with the checksum and sidecar behavior documented for configured backups.

The project also directs users to a precompiled binary installer, source builds, and a NixOS module. Those routes are documented on the Nfrastack site rather than through commands reproduced in the README excerpt. For a reproducible Go build, the repository Makefile exposes `make build` and `make build-community`; its default `EDITION` is `supported`, while selecting `community` adds the `community` build tag.

Build Variants and Edition Boundaries

The Makefile shows that the build output is named `dbb`, source code is under `src`, and the command package is `./cmd/dbb`. The default target is `build`. Build metadata includes the version, commit, build date, and channel, and the build disables CGO. Engine-specific build tags can be requested through `ENGINES`; the Makefile comments include `mysql` and a comma-separated `mysql,postgres` example. These are build-time choices, not documented runtime configuration commands.

The edition split is more important than the build mechanics for many adopters. The README says most features work in the Community Edition, while advanced features require a Supporter license. Community code is licensed under `AGPL-3.0-or-later`. Files under `supported/` are governed by the proprietary `Nfrastack Supporter License v1`, identified in the README as `NSLv1`. The container directory has a separate MIT license, but the bundled `dbb` binary is not thereby placed under MIT.

That arrangement means installation is not simply a choice between downloading a binary and compiling Go. A team may need to determine whether the required encryption, scheduling, restore, or lifecycle capabilities are present in the edition available to it. The README links to an edition comparison but does not enumerate which advanced feature belongs to which edition. Checking that comparison is necessary before treating a general feature list as an availability guarantee.

Restore, Verification, and Failure Boundaries

Restore support is documented through three interfaces: CLI, interactive guided mode, and config-driven profiles. Backup metadata is represented by checksums and JSON sidecars, while restore can be used independently of the scheduler. This supports a workflow in which a backup is produced during normal operation and later selected for restoration.

The project also documents maintenance commands such as analyze, optimize, vacuum, reindex, compact, and memory purge. The README says these can run after a successful backup or independently. That separation is useful when maintenance policy must differ from backup timing, but it also means operators must decide when the operations should run. The README does not provide rollback semantics, recovery-point or recovery-time objectives, cross-job coordination, or a documented policy for partial restore failures.

Failure behavior is another boundary. The project accepts database connection details, storage credentials, encryption settings, schedules, and hooks in one operational surface. A typo, unavailable destination, failed database command, or invalid schedule can therefore affect a job even when other jobs are independent. The excerpt does not document retry counts, timeout defaults, resume behavior, or whether a failed multi-table backup leaves partial artifacts. The documented checksums and sidecars help with integrity inspection, but they are not a substitute for an application-level restore drill.

Maintenance Signals and Upgrade Responsibilities

The repository is not archived. Its last push was on 2026-10-14, and the listed recent releases include `5.0.5` on 2026-10-07, `5.0.4` on 2026-09-24, and `5.0.3` on 2026-09-23. Those records indicate recent release activity, but they do not establish compatibility with every database version, storage service, or edition.

Upgrading can involve more than replacing the executable. The Makefile derives version information from source, embeds build metadata, supports release and development channels, and has separate Community and supported build targets. Configuration compatibility, container tags, encryption settings, sidecar metadata, restore profiles, and license files should all be checked when moving between versions. The README does not publish an upgrade or migration guide in the excerpt, nor does it document rollback for a failed binary upgrade.

For organizations using the open-core Community Edition, `AGPL-3.0-or-later` obligations need to be reviewed for the intended distribution and modification model. The proprietary license applies to the Supported Edition files and features. This is a licensing boundary to confirm with the project's license texts, not a conclusion about a particular deployment.

Editorial conclusion

Adopt nfrastack/db-backup when one interface must coordinate backups, restores, scheduling, retention, and storage across several database engines. Do not assume that one Community Edition installation includes every feature listed in the README, because the Supporter Edition is separately licensed. Before adoption, compare the edition-specific feature table, verify that every required engine is included, and confirm whether the operating system, source layout, and intended storage backend match the documented deployment paths.

Frequently asked questions

Official sources

1. Issues
2. nfrastack/db-backup on GitHub
3. Project website
4. README
5. Releases