Open WebUI移行前に何を保全する？volume・DB・secretの確認
CHATGPT / AIChatGPTなどの生成AIを活用して運営・記事制作・更新を行っています。制作方針
Docker版Open WebUIを更新・移行する前に、named volumeだけで足りるかを確認。SQLiteのWAL、uploaded files、vector data、WEBUI_SECRET_KEY、外部databaseを分け、復元先を消さない確認順を公式資料から整理します。
先に結論
Docker版Open WebUIを別hostへ移すなら、webui.dbだけのコピーでは足りません。まずComposeやcontainerのmountを確認し、Open WebUIのdata volume（またはdata directory）、uploaded files、vector dataの保存先、同じWEBUI_SECRET_KEYを保全対象として記録します。SQLiteを使う場合はWALも関係するため、稼働中にdatabaseファイルだけをコピーしないでください。
更新だけなら現在のvolumeを誤って消さないbackupとversion確認から、別hostへの移行なら外部database・vector store・secret keyも含めて移行範囲を決めます。restore先volumeを本番volumeと分けてから中身を確かめるのが安全です。
確認日: 2026年10月18日（Asia/Tokyo）
対象: DockerでOpen WebUIを動かし、通常更新または別host移行を検討する初心者向けの確認票
確認方法: Open WebUIとDockerの公式資料による机上調査。containerの実データ、backup archive、復元後の動作は実機確認していません。
最初に「更新」か「移行」かを分ける
container imageを更新するだけなら、Open WebUIのdataはcontainer内ではなくDocker volumeまたはlocal databaseに置かれ、imageを入れ替えてもdataはvolume側に残る構成が案内されています。ただし、これはvolumeを削除・置換してよいという意味ではありません。別hostへ移す場合は、Docker volumeだけでなく、databaseやvector storeが外部serviceに置かれていないか、secret keyをどこから渡しているかも確認が要ります。
| 確認対象 | 何を調べるか | 移行時の判断 |
|---|---|---|
| Open WebUIのdata | Composeのvolumesまたはcontainerのmount先と、実際のnamed volume名 | 公式例のopen-webuiをそのまま使わず、現在の設定と一致するvolumeを記録する |
| SQLite database | /app/backend/data/webui.dbを使っているか、外部PostgreSQLか | SQLiteとPostgreSQLでは保全・復元方法が異なる。外部DBならPostgreSQL側の手順を使う |
| WALとsidecar | SQLiteのwebui.db-wal、復元先に残る-wal／-shm | WAL運用中のDB単体コピーを避け、異なるdatabaseのsidecarを混ぜない |
| filesとvector data | /app/backend/data/uploads、/app/backend/data/vector_db、外部vector database | DBのrecordだけでなく、対応するfile・vectorの実データも保全する |
| secret key | WEBUI_SECRET_KEYのCompose secretや環境設定、同じ値を安全に再設定できるか | 移行先へ同じkeyを秘密管理の仕組みから渡す。値を記事・平文backup一覧へ書かない |
保全範囲を決める確認順
- 起動定義を確認する: Compose fileまたはcontainer設定からimage tag、dataのmount元とcontainer内path、database／vector storeの接続先、secretの渡し方を読み取ります。稼働中の設定を変更する前に、現在の値を安全な場所へ記録します。
- 保存方式を特定する: Open WebUI内蔵SQLiteか外部PostgreSQLかを確認します。Open WebUIのdatabase資料にあるSQLite手順はPostgreSQLには適用できません。vector dataもlocal directoryか外部serviceかを分けます。
- 移すdataを列挙する: 内蔵SQLiteならdatabaseの記録だけでなく、uploadsとvector storeを含むdata directory全体を確認します。別の場所へbind mountしたdirectoryやexternal vector databaseがあれば、named volumeのarchiveには入らないため別枠で保全します。
- volume全体のbackupを作る: 更新前の標準的な入口としてOpen WebUIのbackup例が示すvolumeのtar archiveを使えます。例に出る
open-webuiは仮のvolume名として扱い、実際に確認したsource volumeとbackup保存先へ置き換えてください。archiveの対象volumeと出力先を実行前に再確認します。 - secretを別に保全する: 別host移行では同じ
WEBUI_SECRET_KEYを維持できるか確認します。Open WebUIの資料では自動生成keyがdata directoryの外に置かれる場合も示されています。volume archiveだけに含まれると決めつけず、secret managerやComposeの安全な設定元を確認します。
SQLiteをDB単体で移す場合の注意
Open WebUIのSQLiteはWAL modeを使うため、確定済みでもまだwebui.db-walにある変更があり得ます。Open WebUI公式の個別database手順は、containerを停止し、同じimageを使ってWAL checkpointを実行してからdatabaseをコピーする順です。管理画面のDatabase downloadはwebui.db-walを含まず、直近の変更が漏れる可能性があると説明されています。初心者が迷う場合は、DB単体exportよりOpen WebUI全体のdata保全を優先してください。
既に起動した復元先containerへdatabaseを置き換えるとき、公式手順は古いdestination側のwebui.db-walとwebui.db-shmを除いてからimportするよう案内しています。別databaseのsidecarを混ぜると整合しません。実データを上書き・削除する操作は対象volumeを特定できた場合だけ、停止中の検証用volumeで行ってください。
安全な復元確認と元に戻す準備
公式のrestore例は、archiveを展開する前に対象volume内を消去します。volume名やmount先を誤ると既存dataを失うため、backup用volumeとrestore先を別にし、Compose内のvolume名と実際の割当を照合してください。検証では本番volumeを指定せず、別volumeへ復元し、ログイン、chat履歴、uploaded file、knowledge/vector検索の必要項目を確認します。
- archiveのファイル名、作成時刻、source volume、含めた外部database／fileの一覧を記録する。
- 復元を試す場合は本番containerを止めず、別名volumeと別portを用意して検証する。
- 新versionでdatabase migrationが走る場合、imageを前のtagへ戻すだけではschemaが戻らないことがある。更新前backupを残し、release noteとrestore手順を確認する。
- 新環境で必要なdataを確認するまで、旧volumeと元のsecret設定を削除しない。
ここまでの手順は公式資料から整理した確認方法です。この記事ではarchiveの完全性や特定環境への復元成功を実測していません。復元試験をしていない環境では、backupがあるだけで復旧可能と断定できません。
既存記事との関係
Docker版Open WebUIのOllama接続先を確認する記事はcontainerとhostのネットワークが対象で、本稿のdata保全とは別の判断です。Ollamaで最初の会話を始める手順はローカルLLMの導入を扱います。Dockerの基本的なvolumeとcontainerの関係も必要に応じて参照してください。
参考資料
- Open WebUI公式: Updating Open WebUI（2026年10月18日確認。volume backup/restore、復元先を消去する点、secret keyとrollback）
- Open WebUI公式: Exporting & Importing DB（2026年10月18日確認。SQLite WAL、uploads・vector data、外部PostgreSQLの適用外条件）
- Docker公式: Volumes（2026年10月18日確認。named volumeのbackup、restore、lifecycle）
