# onedump: database dump jobs defined in one YAML file > onedump is a Go tool that reads a YAML file of backup jobs and runs them, dumping MySQL or PostgreSQL to local disk, S3, Google Drive, Dropbox or SFTP, with a native MySQL dumper, binlog backup and restore, and a slow log parser. The main caveat is that PostgreSQL still needs pg_dump on the machine. **liweiyi88/onedump** — Effortless database administration tool - Repository: https://github.com/liweiyi88/onedump - Stars: 997 · Forks: 73 - Language: Go - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/liweiyi88-onedump ## One YAML file describes every backup job onedump is a database administration tool for backup and restore, and its central idea is that a backup schedule is data rather than code. The tool has one command, and the command loads a config file that contains all the DB backup jobs in YAML format, with every configurable item described in the project's configuration reference. A job names a database driver, a data source name, and one or more storage targets, so one file can hold a nightly local copy, an offsite copy and a compressed copy of the same database. That shape is what makes it usable from a scheduler: the cron entry invokes the same binary every time and the file decides what happens. The repository layout follows the same decomposition, with separate directories for dumper, storage, filesync, binlog, slow, notifier, handler, jobresult, config and env, which is a reasonable map of the features the README lists. ## Install the binary, or run julianli/onedump in a container The project ships binaries through the release process, and the documentation asks you to download the binary for your OS, move it somewhere on your $PATH, for example /usr/local/bin/onedump, and make it executable. Once that is done the tool runs as a plain command: ```bash $ onedump ``` Docker images are published too, and the README gives three reasons to use the image: running onedump in Kubernetes, ECS or any other container environment, avoiding a manual pg_dump install for PostgreSQL, and using mysqldump when the native MySQL dumper does not fit. The image ships the mysql client, postgresql15-client and postgresql16-client, and by default it uses the postgresql16 client. You can pick the other one with an environment variable, and the README gives this example: ```bash docker run -e PG_VERSION=15 julianli/onedump:v1.5.0-arm64 -f config.yaml ``` Both AMD64 and ARM64 images are maintained, and the documentation notes that the AMD64 image is usually the one you want on a production Linux machine. ## A native MySQL dumper, and the pg_dump gap The dependency story is the first thing to understand, because it decides what you can run where. onedump ships a native MySQL dumper, so the binary can dump a MySQL database with no mysqldump installed on the machine, and the MySQL dump is described as having zero dependencies. It can also drive the external dumpers, mysqldump and pg_dump, which the documentation recommends when you need more advanced MySQL dump features or when you are dumping PostgreSQL. Those external tools have to be installed on the host: mysql-client for MySQL and postgresql-client for PostgreSQL. PostgreSQL has no native dumper in the project, which the README states plainly, and that is the constraint that decides where the tool can run. The Docker image sidesteps it by carrying the clients, and the documentation notes you can extend or build the image yourself if you need different contents. ## Job keys, storage targets and a config file that can live in S3 A job has a small set of keys and then a list of storage targets. The documentation's local example writes one MySQL database to two local files: ```yaml jobs: - name: local-dump dbdriver: mysql dbdsn: root@tcp(127.0.0.1)/test_local gzip: true storage: local: - path: /Users/jack/Desktop/mydb.sql - path: /Users/jack/Desktop/mydb2.sql ``` The driver selects the database engine, the DSN carries the connection details, gzip is a switch on compression, and the storage block lists where the dump goes. The same structure also accepts an s3 block with bucket, key, region, access-key-id, secret-access-key and an optional session-token for assumed roles. The config file does not have to be local, either. Passing a bucket turns the file path into an S3 key: ```bash $ onedump -f backup-config/config.yaml --s3-bucket mybucket ``` By default the tool uses whatever AWS environment variables are present, falls back to the default profile in ~/.aws/credentials when none are found, and you can override the credentials with the --aws-key, --aws-region and --aws-secret options. ## The config file holds the database password and the SSH key The remote example in the documentation is where a reviewer should stop and read carefully. The DSN carries the credential in the connection string, and the SSH private key is written into the job as a literal block: ```yaml jobs: - name: ssh-dump dbdriver: mysql dbdsn: user:password@tcp(127.0.0.1:3306)/mydb sshhost: mywebsite.com sshuser: root sshkey: |- -----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAACFwAAAAdzc2gtcn... -----END OPENSSH PRIVATE KEY----- ``` That is a workable configuration format, and it is also a place where secrets end up in a file that has to be copied, mounted or synced. The S3 credentials are no better in the example, since access-key-id and secret-access-key appear inline in the YAML, even though the tool is perfectly capable of reading them from the environment for its own S3 access. If your backup config is going to sit on a shared machine or in a synced directory, treat that file as a secret store and decide deliberately whether the S3 config path is acceptable to you. ## Binlog backup, binlog restore and the slow log parser Beyond plain dumps, the feature list names a set of MySQL specific capabilities. There is binlog backup to AWS S3, which captures the binary log stream rather than a point in time dump, and a restore path that replays binlogs, which is the tool you reach for when a bad write happened after the last full backup. There is a MySQL slow log parser, and the slow/ directory in the repository is where that lives. File movement is handled by resumable and concurrent SFTP transfers, so a large dump over a flaky link continues rather than restarting, and the filesync/ directory backs it. Notifications go out to Slack through the notifier/ directory, and the README also lists a maintained docker image that contains all dependencies. The go.mod file shows the supporting libraries behind these features, including the AWS SDK v2, the go-mysql library for the binlog work, a scheduler, cobra for the command line, a progress bar and yaml.v3 for the config parsing. ## Compared with running mysqldump or pg_dump by hand The honest alternative is the tool you would otherwise reach for, with a cron entry. mysqldump and pg_dump are already on most database hosts, they are the reference implementations for what a dump is, and a shell script around them is ten lines. The difference in approach is what onedump adds around that core. The dump itself becomes one entry in a declarative job list rather than a bespoke script per database, and the same job can write to several destinations at once, including cloud object storage and Google Drive or Dropbox, which a hand written script has to implement one upload at a time. onedump also adds the native MySQL dumper, which removes the client binary from the host entirely, and the binlog and restore features, which are the reason to look past plain dumps. What you give up is direct control: the escaping of the shell pipeline, the ability to hand-edit a command line at 3am, and the certainty that nothing else about the host has changed since you last ran it. ## Release cadence, licence, and a toolchain mismatch in the Dockerfile The project is active but releases are not frequent. The last push to the repository was on 2026-09-02, and the recent release list is v1.11.1 from 2025-11-16, v1.11.0 from 2025-10-16 and v1.10.0 from 2025-06-19. The licence is MIT, carried in the repository as LICENSE, which means no copyleft obligation and no per-use fee for a tool you run on your own infrastructure. One inconsistency is worth flagging before you build images yourself. The checked-in Dockerfile builds from golang:1.21.8-bookworm, while go.mod declares go 1.25.2, so the two files in the same repository disagree about the Go toolchain the project needs. The presence of.goreleaser.yml and a separate Dockerfile.goreleaser suggests the published images are produced by a different path than that file, which is exactly why building from the checked-in Dockerfile deserves a test before you rely on it. ## Conclusion onedump fits an operations team that wants one scheduled command to drive every database backup instead of a scatter of cron entries and shell scripts, and it fits MySQL estates that want to remove the mysqldump binary from the host. It does not fit a PostgreSQL-only shop that refuses to install pg_dump, and it does not fit a security review that will not accept database passwords and SSH private keys inside a YAML file. Verify the source list, MySQL and PostgreSQL, the destination list, and the credential handling before adoption. The last push to the repository was on 2026-09-02, with v1.11.1 published on 2025-11-16. ## FAQ ### How do I install onedump? Binaries are published on the project's releases page, and the documentation asks you to put the binary on your $PATH and make it executable, after which it runs as the onedump command. Docker images are also published, and the image is the easier route when you need pg_dump included. ### Does onedump need mysqldump or pg_dump installed? Not for MySQL, because onedump ships a native MySQL dumper that works with no client binary on the machine. For PostgreSQL, and for advanced MySQL dump features, you need the mysqldump or pg_dump dumper with mysql-client or postgresql-client installed, and the Docker image already includes them. ### Where can onedump read its configuration from? From a local file with the -f option, for example onedump -f /path/to/config.yaml, or from an S3 bucket by adding --s3-bucket, in which case the file path is treated as the S3 key. Every configurable item is described in the project's configuration reference. ### Which storage destinations does onedump support? The README lists the local file system, AWS S3, Google Drive, Dropbox and SFTP, and the source databases are MySQL and PostgreSQL. A single job can list more than one destination. ## Sources - [Issues](https://github.com/liweiyi88/onedump/issues) - [License: MIT](https://github.com/liweiyi88/onedump/blob/main/LICENSE) - [liweiyi88/onedump on GitHub](https://github.com/liweiyi88/onedump) - [README](https://github.com/liweiyi88/onedump/blob/main/README.md) - [Releases](https://github.com/liweiyi88/onedump/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/liweiyi88-onedump