Backups

Pro and Team. Database → Backups (admins). A backup job dumps one database with the engine’s own tool, by hand or on a schedule, and keeps the copies in Wharfbase’s data folder.

Engine	Tool	File
PostgreSQL	`pg_dump -Fc`	custom format (`pg_restore`)
MySQL	`mysqldump --single-transaction --routines --triggers --no-tablespaces`	gzipped SQL
MariaDB	`mariadb-dump`, same flags	gzipped SQL
MongoDB	`mongodump --archive --gzip`	archive
Redis, Valkey	`redis-cli --rdb`	RDB snapshot
SQLite	SQLite’s online backup, without a container	gzipped database

Turning it on

The tool runs in a short-lived container started from the database’s own image, so the socket-guard has to allow helper containers:

WB_GUARD_ALLOW_EPHEMERAL=true

Then wharfbase up. The guard only allows helper containers from official database images, with Wharfbase’s label and no host access: see Socket guard.

Jobs

Connection: the job dumps through one of the database’s saved connections, with a remembered password. The user needs read access, plus a few privileges for each engine: see the engine’s page.
Schedule: a cron expression (0 3 * * * is every night at 3), or none for manual runs only.
Retention: keep the newest N copies, and optionally nothing older than D days. Old copies are removed after each successful run.
Run now starts a run at once; every run shows its size, its SHA-256 and the error if it failed.

A run doesn’t start when the data volume has less than 1 GB free. Each run’s file is written to <data>/backups/<database id>/ and can be downloaded from the tab. Databases on other servers (Pro) are dumped there and streamed to this server, so the copy is off that host.

Restoring

Restore… on a backup puts it back, for PostgreSQL, MySQL, MariaDB and MongoDB (admins, paid plans). The restore tool runs next to the database, like the dump, and reads the file from this server.

Where: the backed-up database by default. You can choose another of the same kind (MySQL and MariaDB count as one) and another database name, to restore a copy beside the original and look at it first.
- On PostgreSQL the target database must exist already.
- A MySQL backup of all databases only restores under their own names.
What it needs: a connection that can write, shared or your own. A database tagged production needs its writes unlocked first. If the connection doesn’t remember its password, you type it for this restore only.
Confirming: you type the target database’s name.
Safety backup: before restoring, Wharfbase backs up the target, unless you turn that off. The copy is kept with the database’s backups, marked “before a restore”, and Undo… in the Restores list restores it. If the safety backup fails, nothing is restored.
Checks first: the file must still match its SHA-256.

What each engine does:

Engine	How	If it fails halfway
PostgreSQL	`pg_restore` writes the script, `psql` runs it as one transaction. Objects in the backup are dropped first (with `CASCADE`, so objects that depend on them and aren’t in the backup go too), then recreated.	Nothing changed
MySQL, MariaDB	The dump runs through the `mysql` client: each table is dropped and recreated.	The tables restored so far stay restored: use the safety backup
MongoDB	`mongorestore --drop`: each collection in the backup is replaced.	The same

Redis and SQLite backups are restored by hand: the Backups tab shows how. Any engine can also be restored by hand from a download, for example:

pg_restore --clean --if-exists -h HOST -U USER -d DATABASE FILE
gunzip < FILE | mysql -h HOST -u USER -p

MariaDB: without SHOW CREATE ROUTINE (11.3 and later), mariadb-dump leaves stored procedures out without an error. Give the backup user that privilege if you have any.