GoBackup: a Go CLI that dumps databases and files to cloud storage on a schedule

The gap GoBackup fills on a small application server

Most backup tooling assumes either a managed database or a fleet. GoBackup assumes neither. It targets the single application server that runs PostgreSQL, a Redis instance, and a directory of uploaded files, where the operator wants a nightly dump pushed off the machine and does not want to maintain a Ruby runtime to get it.

The README states the project was inspired by backup/backup and exists partly to replace it "without Ruby dependency." That framing explains the shape of the tool: a statically compiled Go binary, no interpreter, no gem bundle to keep patched. The README also claims one-time setup that can run for years without maintenance, citing a Ruby China deployment that has backed up daily since 2017. That is the vendor's own account of its production use, not an independent measurement.

Who it is for is narrow and worth stating plainly: operators of small and mid-sized servers who are comfortable editing a YAML file and who already have a bucket somewhere. It is not a platform, not a managed service, and not a tool for coordinating backups across a cluster.

How a backup run actually flows from config to bucket

The repository layout maps directly onto the pipeline. A model in gobackup.yml names one or more databases, one or more storages, and a compressor. At run time the database adapter in database/ invokes the native dump client for that engine and writes the output to a temporary file. The archive/ package can also tar up paths or files. The compressor/ package then compresses the result, and if an encryptor is configured, encryptor/ applies it before the storage/ package uploads to the destination.

That reliance on native clients is the architectural decision that matters most. GoBackup shells out rather than reimplementing dump formats, which is why the Dockerfile installs postgresql18-client, mysql-client, mariadb-backup, redis, mongodb-tools, sqlite and the Microsoft sqlpackage tool. It also means the binary alone is not sufficient for every engine: the corresponding client must exist on the host or in the container. If you install via the shell script onto a slim host, MySQL and PostgreSQL dumps will fail until you install those clients yourself.

The splitter/ package handles splitting a large archive into multiple parts, which matters when an object storage backend or an upload path has a size ceiling. The scheduler/ package wraps gocron for cron and interval schedules. The metrics/ package exposes Prometheus client bindings, so a daemon run can be scraped, though the README does not document the endpoint path.

Installing GoBackup and running a first PostgreSQL backup

The README gives two install paths. The shell installer downloads a binary to /usr/local/bin/gobackup:

curl -sSL https://gobackup.github.io/install | sh

Homebrew is the other option:

brew install gobackup

GoBackup looks for its config in ~/.gobackup/gobackup.yml or /etc/gobackup/gobackup.yml. A minimal PostgreSQL-to-S3 model looks like this, adapted from the README example:

models:
  gitlab_app:
    databases:
      gitlab_db:
        type: postgresql
        database: gitlab_production
        username: gitlab
        password:
    storages:
      s3:
        type: s3
        bucket: my_app_backup
        region: us-east-1
        path: backups
        access_key_id: $S3_ACCESS_KEY_Id
        secret_access_key: $S3_SECRET_ACCESS_KEY
    compress_with:
      type: tgz

Note the dollar-sign references: credentials are read from the environment rather than written literally into the file. Run a one-off backup with:

gobackup perform

To run it on a schedule, add a schedule block and start the daemon:

    schedule:
      cron: "5 4 * * sun"

gobackup start

The README shows the daemon logging the config path and then the line `Starting API server on port http://127.0.0.1:2703`. Visiting that address in a browser shows the web UI. Use `gobackup run` instead of `start` if you want the process in the foreground without the daemon behaviour. The README also documents two signals: `kill -HUP <pid>` reloads configuration, and `kill -QUIT <pid>` shuts down gracefully.

Where the design stops being a good fit

The most consequential limitation is recovery granularity. GoBackup produces periodic full dumps. Nothing in the README describes incremental backups, WAL archiving, binlog streaming, or point-in-time recovery. If a table is dropped at 14:00 and your last dump was at 04:05, the best you can do is restore the 04:05 state and lose the intervening hours. For a small application that may be acceptable; for anything with a recovery point objective measured in minutes, it is disqualifying.

The configuration file is also a plaintext credential store by default. The README example shows `password:` empty for PostgreSQL and `password: password` for MySQL, with environment variable substitution available for storage keys. Environment variables help, but the config is still read from a predictable path on the host, and there is no documented mechanism for a secrets manager or an encrypted config store. The README does not document rollback of a restore, either, so the restore path itself is something you will be testing on your own.

There is a version skew in the documentation worth flagging. The `gobackup -h` output pasted into the README reports VERSION: 1.3.0 and lists only perform, start, run and help, while the releases list shows v3.1.1. Treat the help text in the README as illustrative rather than current. Finally, the Dockerfile installs the MSSQL ODBC driver and mssql-tools only for amd64, with a comment noting that the arm64 package is actually an x86_64 binary. If you are on arm64 and need SQL Server backups, that path is not covered.

How GoBackup differs from pgBackRest and pgbackweb

The closest comparison for PostgreSQL users is pgBackRest, and the difference is philosophical rather than cosmetic. pgBackRest is engine-specific: it understands PostgreSQL's WAL stream, supports full, differential and incremental backups, and can perform point-in-time recovery. GoBackup is engine-agnostic: it shells out to pg_dump, gets a logical dump, and knows nothing about WAL. You get breadth across ten database engines and twenty storage backends, and you give up recovery precision within the dump interval.

pgbackweb sits in a different place again, as a web-fronted management layer for PostgreSQL backup rather than a general multi-engine CLI. If your environment is PostgreSQL and nothing else, and you want a browser interface as the primary interaction, that shape may suit you better than a YAML file and a daemon. GoBackup does ship a web UI, but the README presents it as a companion to the daemon, not as the main way to configure backups.

The honest summary: GoBackup wins on breadth and on the absence of a runtime dependency. It loses on depth for any single engine.

Maintenance, upgrade surface, and what MIT means here

The last push to the repository was on 2026-08-14, and the most recent release is v3.1.1 from 2026-07-06. The project is not archived. The three most recent releases span v3.0.0 in December 2025, v3.1.0 in May 2026, and v3.1.1 in July 2026, so major-version bumps are infrequent and the release cadence is measured in months.

Upgrade cost is mostly the config schema and the client binaries. The jump from v2 to v3 is the kind of change that historically invalidates configuration, so pinning a version and reading the release notes before moving is the practical approach. Because GoBackup delegates to native clients, an upgrade also inherits whatever the host's pg_dump or mysqldump supports. If you run the Docker image, the client versions are baked in at image build time and change when the image is rebuilt, which can shift behaviour without any change to your YAML.

The MIT license is permissive: you can use it commercially, modify it, and redistribute it. It comes with no warranty, which matters for a tool whose entire job is producing the artifact you will restore from. Nothing in the license obliges anyone to fix a bug in the dump path, and the README does not describe a support contract or commercial backing.

Editorial conclusion

GoBackup fits small teams running a handful of application servers who want database dumps landing in object storage without writing shell scripts or maintaining a Ruby toolchain. It is the wrong choice if you need point-in-time recovery, incremental backups, or a central control plane across dozens of hosts, since the design is a per-server daemon writing periodic full dumps and the README does not document any of those capabilities. Before adopting it, read gobackup_test.yml against your own database versions, confirm the Docker image carries the client binaries your engine needs, and decide whether the plaintext credentials in gobackup.yml are acceptable on the host.

Frequently asked questions

Official sources

1. gobackup/gobackup on GitHub
2. License: MIT
3. Project website
4. README
5. Releases