v1.1.0 — free & open source

Database backups that just work on your VPS or cPanel.

Install with one command, add your database, pick how often to back it up. Restoring is just as easy: pick a backup and confirm.

$ curl -fsSL https://raw.githubusercontent.com/tanzid64/tui-db-manager/main/install.sh | sh

Linux & macOS. No root needed — it installs to ~/.local/bin if /usr/local/bin isn't writable. Then run dbk.

See the 5 steps → Star on GitHub

Free forever. If dbk saves you time, a ⭐ helps other people find it. Prefer manual install? Download binaries.

MySQL / MariaDB PostgreSQL MongoDB SQLite Local folder AWS S3 · R2 · B2 · MinIO Google Drive 🔒 Encrypted by default

dbk

dbk — Database Backup
Main Menu

▶ Backup Jobs                           
    Add a database, run a backup now, test the connection
  Schedules
    Back up automatically (daily, hourly, ...)
  Restore
    Pick a backup and restore it into the database
  Storage
    Where backups are kept: local, S3/R2 bucket, Drive
  History
    Recent backups and restores, with errors
  Settings
    Notifications, settings backup, updates

↑/↓ Navigate • Enter Select • q Quit

How it works

From install to restore in 5 steps

Everything happens in the dbk screen with a few keys. Each step also shows the matching command, if you prefer scripts.

1. Install dbk

Run the install command on your server (over SSH, or cPanel → Terminal). It also creates a ready-to-use storage called local at ~/dbk-backups, so there's nothing else to set up before your first backup.

terminal

$ curl -fsSL https://raw.githubusercontent.com/tanzid64/tui-db-manager/main/install.sh | sh
==> Downloading dbk v1.1.0 for linux/amd64...
==> Checksum verified
==> Installing to /usr/local/bin/dbk...
==> Setting up dbk (database + default local storage)...
default local storage "local" -> /home/you/dbk-backups
==> Installation complete! Run 'dbk' to start.

Then start it: type dbk and press Enter.
Move around with ↑ ↓, open with Enter, go back with Esc.

⚠

If the installer says ~/.local/bin is not in your PATH (common on cPanel), run ~/.local/bin/dbk, or add export PATH="$PATH:$HOME/.local/bin" to ~/.bashrc.

2. Add your database

Open Backup Jobs and press a. A short form walks you through it. Your password is stored encrypted on the server and never shown in process lists.

dbk › Backup Jobs › Add

Add New Backup Job — Step 2 of 5: Server Connection
Connection parameters for the database server

▶ Host:     127.0.0.1                    
  Port:     3306
  Username: myaccount_shop
  Password: ••••••••
  [ ] Use TLS

Tab/↓ Next • Enter Next/Submit • Esc Back

Name & type — any name (e.g. shop), then MySQL/MariaDB, PostgreSQL, MongoDB or SQLite (← → to choose). Each type shows ✔ or ✖ tools missing, so you know right away if this computer can back it up.
Connection — host, port, user, password. Ports and users fill in for the type you picked.
SSH tunnel (optional) — for a database on another server that isn't open to the internet. Leave it blank to connect directly. See Remote databases.
Database — dbk lists the databases it can see; pick one.
Storage & keep — local is preselected. Keep last 7 backups, gzip compression and Encrypt backups are on by default.

🔑

Encrypted backups need their key to restore. The key is kept on this server. After adding a job, save a settings backup somewhere else, so you can restore even if the server is lost.

💡

On cPanel, use the database user cPanel created (it starts with your account name, like myaccount_shop) and host localhost or 127.0.0.1.

Prefer files? Import jobs from a bundle, then store the password:

$dbk config import jobs.yaml

$dbk secret set job/shop/password --stdin

3. Test it and back up now

In Backup Jobs, select your job. Press t to check the database connection, then Enter to run a backup right away.

dbk › Backup Jobs

Backup Jobs
Each job backs up one database to a storage

▶ shop   (mysql → local, keep 7, not scheduled) [gz] ✔ OK

✔ Backup saved: shop/shop-20261025-030000.sql.gz (12.1 KB, 1.2s)

Enter/r Back up now • t Test • a Add • e Edit • d Delete • b Restore

Backups are saved as <job>/<job>-<date>-<time>.sql.gz in the job's storage.
Older backups beyond "keep last" are deleted automatically.
Every run — manual or scheduled — appears under History, with the error if it failed.

Same thing from the command line:

$dbk test shop

$dbk run shop

4. Schedule automatic backups

Open Schedules, select the job, press Enter and pick how often. It keeps running after you log out — on a VPS and on cPanel.

dbk › Schedules

Automatic Backup Schedule
How often should shop be backed up?

▶ Frequency: [Every day at 03:00]  Every 12 hours  Every 6 hours
             Every hour  Every Sunday at 03:00  Custom (cron expression)
  Custom cron (only for Custom): 30 2 * * *

✔ "shop" will back up every day at 03:00 (via crontab).
  Log: ~/.config/dbk/logs/shop.log

Use ← → to pick a frequency. Want something else? Type a cron expression such as 30 2 * * * (2:30 every night).
Turn a schedule off with x.
Each scheduled run writes to ~/.config/dbk/logs/<job>.log — the first place to look if something's off.

From the command line:

$dbk schedule install shop --at "0 3 * * *"

$dbk schedule status shop

5. Restore a backup

Open Restore, pick the job, then pick a backup — newest first, from every storage you've used. Type RESTORE and press Enter.

dbk › Restore

Restore
Backups for job shop (from all storages, newest first):

▶ 2026-10-25 03:00  12.1 KB  [bucket] shop/shop-20261025-030000.sql.gz (latest)
  2026-10-24 03:00  12.0 KB  [bucket] shop/shop-20261024-030000.sql.gz
  2026-10-20 03:00  11.8 KB  [local]  shop/shop-20261020-030000.sql.gz

↑/↓ Navigate • Enter Select • Esc Back

The restore replaces the current data in that database, so dbk asks you to type RESTORE first.
Want to check a backup without touching live data? Press Tab on the confirm screen and enter a different database name to restore into.

From the command line (latest backup, or a specific one):

$dbk restore shop --yes

$dbk restore shop --yes --at shop/shop-20261020-030000.sql.gz

Next: choose storage →

Storage

Where should your backups go?

Start with the local folder — it's already set up. For off-server safety, add a bucket or Google Drive and switch your job to it.

💾

Local folder Ready

Created on install at ~/dbk-backups. Fastest, nothing to configure — but it lives on the same server.

🪣

Bucket (S3-compatible)

AWS S3, Cloudflare R2, Backblaze B2, MinIO, Wasabi. Keeps copies safe even if the server is lost.

📁

Google Drive

Uses a service account — no browser login, so it works for scheduled backups.

🔁

Switching storage later is safe. Edit the job (e) and pick the new storage. Older backups stay where they are and still show up in Restore, labelled with their storage. Just don't delete the old storage while you still need them.

Add a bucket in dbk

Open Storage → a → choose s3 (or gdrive). dbk tests it right after you save by writing and deleting a small file. Pick your provider:

Get your keys

Cloudflare dashboard → R2 → Create bucket (e.g. db-backups).
Manage R2 API Tokens → Create API Token → permission Object Read & Write, limited to your bucket.
Copy the Access Key ID, Secret Access Key and your Account ID.

What to type in dbk
Bucket Name	db-backups
Endpoint	<account-id>.r2.cloudflarestorage.com
Region	auto (or leave empty)
Access Key ID	your access key
Secret Access Key	your secret key
Folder in Bucket	optional, e.g. server1

Get your keys

AWS console → S3 → Create bucket; note its region (e.g. eu-central-1).
IAM → Users → create a user just for backups. Allow s3:PutObject, s3:GetObject, s3:DeleteObject, s3:ListBucket on that bucket only.
User → Security credentials → Create access key.

What to type in dbk
Bucket Name	my-db-backups
Endpoint	leave empty
Region	eu-central-1
Access Key ID	AKIA…
Secret Access Key	your secret key
Folder in Bucket	optional

Get your keys

Backblaze → Buckets → Create a Bucket (private). Note the Endpoint shown on the bucket, e.g. s3.us-west-004.backblazeb2.com.
Application Keys → Add a New Application Key with read & write access to that bucket.
Copy the keyID and applicationKey (shown only once).

What to type in dbk
Bucket Name	my-db-backups
Endpoint	s3.us-west-004.backblazeb2.com
Region	us-west-004
Access Key ID	keyID
Secret Access Key	applicationKey
Folder in Bucket	optional

Get your keys

Create a bucket in your MinIO console (or Wasabi dashboard).
Create an access key with read & write access to it.
Use the S3 API address as the endpoint — for MinIO that's usually port 9000, not the console port.

What to type in dbk
Bucket Name	backups
Endpoint	https://minio.example.com:9000 Wasabi: s3.eu-central-1.wasabisys.com
Region	us-east-1 (Wasabi: your bucket's region)
Access Key ID	your access key
Secret Access Key	your secret key
Folder in Bucket	optional

Set up a service account

Google Cloud Console → create a project → APIs & Services → enable Google Drive API.
Credentials → Create credentials → Service account. Open it → Keys → Add key → JSON.
In Google Drive, create a folder and Share it with the service account's email as Editor.
Open the folder; the ID is the last part of the URL: drive.google.com/drive/folders/1A2B3C…

What to type in dbk (type `gdrive`)
Google Drive Folder ID	1A2B3C…
Service Account JSON	paste the whole JSON file

💡

You can type the endpoint without https:// — dbk adds it. Custom endpoints automatically use the URL style these providers expect, so there's no extra switch to find.

VPS & cPanel

Works the same on both

dbk runs as your normal user and schedules backups with crontab, which exists on virtually every VPS and on cPanel shared hosting.

🖥️ On a VPS

Install the database client tools if they're missing:
sudo apt install mariadb-client or postgresql-client (or mongodb-database-tools).
Run the install command as the user who should own the backups.
Schedules keep running after you close SSH — no need to stay logged in.
Check a schedule any time: dbk schedule status <job> or crontab -l.

🌐 On cPanel

Open cPanel → Terminal (or SSH) and run the install command. No root needed.
Use the database user from cPanel → MySQL Databases (e.g. account_dbuser), host localhost.
No special privileges needed — dbk skips the server-wide data (tablespaces) that shared hosting doesn't allow.
Your schedule appears in cPanel → Cron Jobs. Don't edit that line by hand; change it in dbk.

🍎

On a Mac, install the tools with Homebrew: brew install mysql-client (or mariadb), libpq for PostgreSQL. dbk finds them even though Homebrew doesn't add them to your PATH, and Postgres.app works too. dbk keeps its data in ~/Library/Application Support/dbk instead of ~/.config/dbk.

⚠

Backups on the same server aren't enough on their own. If the server or hosting account is lost, so is ~/dbk-backups. Add a bucket or Google Drive for important databases.

Remote databases

Back up a database on another server

Run dbk on one machine and back up databases on others. Connect directly, or through SSH when the database isn't open to the internet. No ssh -L or extra programs needed.

Direct

Enter the server's address and port in Server Connection and leave the SSH step blank. Turn on Use TLS if the database server has SSL enabled.

Only use this when the database port is meant to be reachable over the network. Without TLS, the backup crosses the network unencrypted.

Through SSH Recommended

Fill in the SSH Tunnel step. The database can stay closed to the internet: dbk logs in over SSH and reaches it from inside the server, so Host is usually 127.0.0.1.

Log in with a key file, a password, or ssh-agent.
A key file you pick is copied into dbk's encrypted vault, so scheduled backups don't depend on the file.
The server's identity is pinned when you save the job, and dbk refuses to connect if it changes.

dbk › Backup Jobs › Add

Add New Backup Job — Step 3 of 5: SSH Tunnel (optional)
Leave SSH Host blank to connect directly.

▶ SSH Host:          203.0.113.10         
  SSH Port:          22
  SSH User:          dbkbackup
  Private Key File:  ~/.ssh/dbk_vps
  SSH Password:      optional

✔ Added job "shop" — SSH key stored in the vault; pinned SSH host key SHA256:…

Set up a VPS for SSH backups

Run these on the VPS (Ubuntu/Debian; works for MySQL and MariaDB). The SSH account can only reach MySQL. It has no shell.

1. Keep MySQL private

In mysqld.cnf (MariaDB: 50-server.cnf) set bind-address = 127.0.0.1, restart MySQL, and close the port:

$sudo ufw allow OpenSSH && sudo ufw deny 3306 && sudo ufw enable

2. A database user for dbk

Through SSH, MySQL sees dbk as 127.0.0.1:

CREATE USER 'dbk'@'127.0.0.1' IDENTIFIED BY 'strong-password'; GRANT SELECT, SHOW VIEW, TRIGGER, EVENT, LOCK TABLES ON shop.* TO 'dbk'@'127.0.0.1';

For stored procedures also grant SHOW_ROUTINE ON *.* (MySQL 8) or SELECT ON mysql.proc (MariaDB). To restore with dbk, grant ALL PRIVILEGES ON shop.* instead.

3. An SSH account just for backups

$sudo adduser --disabled-password --gecos "" dbkbackup

On the dbk machine, make a key with ssh-keygen -t ed25519 -f ~/.ssh/dbk_vps -N ''. Then add it to /home/dbkbackup/.ssh/authorized_keys on the VPS as one line:

restrict,port-forwarding,permitopen="127.0.0.1:3306" ssh-ed25519 AAAA… dbk

4. Add the job in dbk

Server Connection: host 127.0.0.1, port 3306, user dbk, TLS off (SSH already encrypts).
SSH Tunnel: your VPS address, user dbkbackup, key ~/.ssh/dbk_vps.
Press t to test. If the databases list on the next step, the tunnel works.

🧰

The computer running dbk still needs the client tools (mysqldump, pg_dump, mongodump), even when the database is remote. You don't need a database server there, only the tools. For a MariaDB server, install the MariaDB client.

Security

Your data stays yours

dbk runs on your server. No account, no outside service, and no one else sees your passwords or backups.

🔒

Encrypted backups Default

New jobs encrypt every backup with age before it leaves the server. S3, R2 or Google Drive only store unreadable .age files. Jobs that send unencrypted backups to the cloud are marked ⚠ not encrypted.

🗝️

Random master key

Each install gets its own random key that protects saved passwords (XChaCha20-Poly1305, Argon2id). Upgrading from 1.0.0 switches you to a random key automatically. Your schedules keep running.

🙈

Passwords stay hidden

Database passwords go to the dump tools through environment variables, never the command line, so other users can't see them in ps. SSH keys and passwords live in the same encrypted vault. Schedule scripts don't contain your key.

📂

Private files

Settings, the password vault, logs and local backups are readable only by your user (0600/0700).

🏠

Nothing leaves without you

No sign-up, no tracking, no third-party backup service. Backups go only to storage you add.

✅

Checked updates

dbk update verifies the download's SHA-256 checksum before replacing the program.

Back up your settings (and your keys)

Your backups are only half the story. To restore on a new server you also need your jobs, storages, passwords and the encryption keys. Save them in one file, protected by a passphrase you choose. Do this after adding or changing a job.

In the app

Open Settings → Export Settings Backup.
Keep Include passwords & encryption keys ticked and enter a passphrase. Remember it: you'll need it to import.
dbk saves ~/dbk-settings-backup.yaml. Copy it off the server (your computer, a password manager, a different bucket).
On a new server: install dbk, then Settings → Import the file with the same passphrase. Your old backups show up in Restore.

From the command line

Save settings, passwords and keys (asks for a passphrase)

dbk config export ~/dbk-settings-backup.yaml --include-secrets

Copy it to your computer (run this on your computer)

scp user@server:dbk-settings-backup.yaml .

Restore on a new server (asks for the passphrase)

dbk config import dbk-settings-backup.yaml

⚠

Don't keep the settings backup only on the same server or in the same bucket as your backups. Anyone with both the file and its passphrase can read your backups, and if the server is lost with the only copy, encrypted backups can't be restored.

Help

Common questions & fixes

My scheduled backup didn't run. Where do I look?

Open the job's log — every scheduled run writes its start, result and any error there:

$tail -n 30 ~/.config/dbk/logs/shop.log

On a Mac the log is in ~/Library/Application Support/dbk/logs/.

If the log has nothing new, check the schedule is installed with dbk schedule status shop. In Schedules, a ⚠ next to a job means it's saved but not installed — press Enter on it to fix.

"client tools are not installed on this computer"

dbk uses the database's own dump tools, and the message names the missing tool and the command to install it. dbk checks before it starts, and the job list marks affected jobs with ⚠ tools missing. Install them on the computer running dbk: mariadb-client or mysql-client (MySQL/MariaDB), postgresql-client (PostgreSQL), mongodb-database-tools (MongoDB), sqlite3 (SQLite). On a Mac: brew install mysql-client or libpq. cPanel servers already have the MySQL tools.

Do I need MySQL installed to back up a remote database?

You don't need a MySQL server, but the computer running dbk needs the MySQL/MariaDB client tools (mysql, mysqldump), even for a remote database or one reached through SSH. Use the client that matches the server: the MariaDB client for MariaDB, the MySQL client for MySQL.

"SSL is required but the server doesn't support it"

Use TLS is on, but the database server has SSL turned off. Edit the job (e) and untick Use TLS. Better still, connect through SSH, which encrypts the connection without needing SSL on the database.

"unknown host key" when using SSH

dbk only connects to an SSH server it can identify. Edit and save the job in the app to pin the server's key, or log in once with ssh user@server so it's added to ~/.ssh/known_hosts. The error shows the fingerprint, which you can also set as ssh.host_key in the job.

The storage test failed

dbk writes, reads back and deletes a small test file. A failure usually means a wrong secret key (403 / Forbidden), a bucket name or region that doesn't match, or an endpoint pointing at a web console instead of the S3 API. Press e on the storage to fix it, then t to test again.

I moved my job from local to S3. Where are my old backups?

Still in the old storage. Restore lists backups from every storage, labelled [local], [bucket] and so on. From the command line, dbk list shop shows the storage in the last column, and dbk restore shop --yes --storage local restores the newest one from there.

Can I restore into a test database first?

Yes. On the confirm screen press Tab and enter another database name, or use dbk restore shop --yes --to shop_test. The target database must already exist.

Where are my passwords stored? Are they safe?

In ~/.config/dbk/dbk.db, encrypted with a random master key that's unique to your install (saved in ~/.config/dbk/env). Both files are readable only by your user. Passwords are passed to the dump tools through environment variables, never on the command line, so other users can't see them in the process list. See Security.

My server died. How do I restore my encrypted backups?

You need your settings backup file and its passphrase. On the new server, install dbk and import it:

$dbk config import dbk-settings-backup.yaml

Your jobs, storages, passwords and keys come back, and Restore lists the backups in your bucket. Without the settings backup, encrypted backups can't be opened, so save one today.

I updated from 1.0.0 and see "replaced the default master key"

That's expected and only happens once. Version 1.0.0 used the same built-in key on every install. 1.1.0 replaces it with a random one, re-encrypts your saved passwords and updates your schedules, which keep running. Nothing to do, but it's a good moment to save a new settings backup.

How do I update dbk?

Run dbk update. Your jobs, storages and schedules are kept.

Coming from an old pre-1.0 build (v1.1–v1.6)? Re-run the install command once — those builds don't see 1.0.0 as newer.

How do I remove dbk completely?

This removes all schedules, settings and the program. Your backup files in ~/dbk-backups and buckets are not deleted.

$dbk uninstall --all --yes

In the app, use Settings → Clean Uninstall. dbk closes and prints what it removed, and anything it couldn't remove along with the reason. On a Mac, if removing a schedule says "Operation not permitted", give your terminal app Full Disk Access (System Settings → Privacy & Security) and run it again.

Commands

Everything from the command line

Handy for scripts and CI. Replace shop with your job name.

Back up & restore

Back up now

dbk run shop

List backups (all storages, newest first)

dbk list shop

Restore the latest backup

dbk restore shop --yes

Restore into another database

dbk restore shop --yes --to shop_test

Schedule & check

Back up every night at 03:00

dbk schedule install shop --at "0 3 * * *"

Is it scheduled?

dbk schedule status shop

Stop scheduling

dbk schedule remove shop

Test a job or a storage

dbk test shop

Settings backup & moving servers

Save jobs, storages, passwords and encryption keys (asks for a passphrase)

dbk config export ~/dbk-settings-backup.yaml --include-secrets

Import on the new server (asks for that passphrase)

dbk config import dbk-settings-backup.yaml

Remote databases (SSH)

Store the job's SSH key in the vault

dbk secret set job/shop/ssh_key --stdin < ~/.ssh/dbk_vps

Or an SSH password / key passphrase

dbk secret set job/shop/ssh_password --stdin

Test the connection through the tunnel

dbk test shop

Maintenance

Update to the latest version

dbk update

Show the version

dbk version

Support the project

Enjoying dbk? Give it a ⭐ on GitHub

dbk is free and open source. A star takes one click, keeps the project going, and helps other developers and hosting users find it.

Star dbk Suggest a feature