🚨 Critical: Before proceeding, create a complete backup of your metadata. This backup serves as your safety net for rolling back if needed. Refer to the “Back up and Restore” section below for comprehensive backup procedures.
The procedure depends on where Bytebase stores its metadata:
Embedded PostgreSQL — the default. You did not set PG_URL, and the metadata lives in the data directory mounted into the container. Back up that directory.
External PostgreSQL — you set PG_URL, and the metadata lives in the database named in that connection string. Clone that database.
The embedded PostgreSQL listens only on a Unix socket inside the container and shuts down together with Bytebase, so it cannot be cloned from another host. Back up the mounted data directory instead.The examples below assume the docker run command from Deploy with Docker, which mounts ~/.bytebase/data at /var/opt/bytebase. Substitute your own host path.
Start Bytebase with the previous version (the version you were running before the failed upgrade).
After confirming successful restoration, remove ~/.bytebase/data.old.
Restore as root, and with a command that preserves ownership — tar as root and cp -a both do, a plain cp -r does not. Bytebase repairs the permissions of the data directory itself, but not the ownership of the files inside it, and PostgreSQL refuses to start when it does not own them.
Replace <dbname> in the statements below with the database named in your PG_URL — the same value you supplied when you configured External PostgreSQL. To check which one you are using:
Connect to another database on the same PostgreSQL server — postgres always exists — and clone the metadata database:
CREATE DATABASE <dbname>_backup WITH TEMPLATE <dbname>;
WITH TEMPLATE requires that no other session is connected to the source database. Stop Bytebase first, or PostgreSQL fails with source database ... is being accessed by other users.