Data backup

The Model Hub persists state in two places. Back up both regularly, and always take a backup before upgrading.

 

What	Where	Why it matters
SQL database	Your PostgreSQL or Oracle instance	Stores models metadata, sync state, Git provider configuration, and other application data
Filestore volume	Docker volume mounted at /home/node/.hub	Stores the encryption key used to protect sensitive values (such as Git credentials) saved in the database

 

Note: if you restore the database without the matching filestore (or vice versa), encrypted secrets in the database may become unreadable. Treat the database and filestore as a single backup set.

 

What to back up

1. SQL database

 

Use your organization’s standard backup process for the database engine you chose at install time:

 

• PostgreSQL 18+: managed snapshots, continuous backup, or pg_dump / pg_basebackup according to DBA standards
• Oracle 26ai  RMAN, managed backups, or your platform’s equivalent

 

Back up the Model HUB database (and schema) used by the application. Follow your DBA guidelines for consistency (for example, a snapshot that includes all tables owned by the Model HUB).

 

 

Note: prefer a normal full or incremental database backup over exporting individual tables. The Model HUB schema is maintained by the migration image; do not rely on “recreating the schema on restart” as a substitute for a proper backup and restore procedure.

 

 

Filestore volume

Back up the persistent volume mounted at /home/node/.hub on the model-hub container (the volume named model-hub-filestore-data in the Compose example).

 

This volume includes credentials material such as the KVS encryption key. Losing it can prevent the Model Hub from decrypting database secrets after a restore.

 

How you back it up depends on your platform:

• Docker Compose / local volume:  stop writers if required by your process, then archive the volume data (or snapshot the host disk)
• Cloud disks: use the provider’s disk/volume snapshot features

 

When to back up

On a regular schedule that matches your recovery objectives (for example daily database backups plus filestore snapshots)

• Before every Model Hub upgrade (new `$MODEL_HUB_VERSION`)
• Before major changes to Git provider configuration or authentication
• Before destructive maintenance on the database or host

 

Restore overview

 

1. Restore the SQL database to a consistent point in time.

2. Restore the filestore volume from the same backup window (or a known-compatible pair).

3. Start the Model Hub.

4. Confirm:

•  
  • GET /health returns HTTP 200
  • The UI loads
  • Git provider configuration still works (or re-enter secrets if you intentionally rotated them)
  •  Recent models are visible / sync still functions

 

You should document your restore runbook and test it periodically.