If —pg is specified, the metadata will be stored in the specified external PostgreSQL database. Below shows how to back up and restore the Bytebase metadata, let’s assume the metadata is stored in metadb
.
metadb
Create a new db metadb_new
:
Restore metdata to the new db:
You need to first stop Bytebase otherwise its connection to the metadata db will prevent renaming the database.
Also, you can not rename the connecting database so you need to connect to the PostgreSQL instance using a different database like postgres
.
Rename existing metadb
to metadb_old
:
Rename metadb_new
to the metadb
, which will serve as the new metadata db:
Restart Bytebase and verify the metadata is restored properly. Afterwards, you can drop the old database:
metadb2
The dump file records the Bytebase metadata schema change history, and it’s database specific. So we
need to change the existing record value from metadb
to metadb2
first, which means to transfer
the change history to metadb2
.
Locate the migration_history
table in the dump file, and for each record, find the value metadb
which corresponds to the namespace
column, change each occurrence from metadb
to metadb2
.
metadb2
Create a new db metadb2
:
Restore metdata to the new db:
Restart Bytebase and verify the metadata is restored properly. Afterwards, you can drop the old database:
If External PostgreSQL is not configured, then
Bytebase will store the metadata under the —data directory.
You can back up the --data
directory or the pgdata
subfolder.
You should periodically back up the entire —data directory if any data is stored there.
If Bytebase is running and not in the readonly mode, and you want to take the backup, then the underlying data volume must support snapshot feature where the entire directory can take a snapshot at the same time, otherwise it may produce a corrupted backup bundle.
If —pg is specified, the metadata will be stored in the specified external PostgreSQL database. Below shows how to back up and restore the Bytebase metadata, let’s assume the metadata is stored in metadb
.
metadb
Create a new db metadb_new
:
Restore metdata to the new db:
You need to first stop Bytebase otherwise its connection to the metadata db will prevent renaming the database.
Also, you can not rename the connecting database so you need to connect to the PostgreSQL instance using a different database like postgres
.
Rename existing metadb
to metadb_old
:
Rename metadb_new
to the metadb
, which will serve as the new metadata db:
Restart Bytebase and verify the metadata is restored properly. Afterwards, you can drop the old database:
metadb2
The dump file records the Bytebase metadata schema change history, and it’s database specific. So we
need to change the existing record value from metadb
to metadb2
first, which means to transfer
the change history to metadb2
.
Locate the migration_history
table in the dump file, and for each record, find the value metadb
which corresponds to the namespace
column, change each occurrence from metadb
to metadb2
.
metadb2
Create a new db metadb2
:
Restore metdata to the new db:
Restart Bytebase and verify the metadata is restored properly. Afterwards, you can drop the old database:
If External PostgreSQL is not configured, then
Bytebase will store the metadata under the —data directory.
You can back up the --data
directory or the pgdata
subfolder.
You should periodically back up the entire —data directory if any data is stored there.
If Bytebase is running and not in the readonly mode, and you want to take the backup, then the underlying data volume must support snapshot feature where the entire directory can take a snapshot at the same time, otherwise it may produce a corrupted backup bundle.