feat: Built-in backup/restore with version safety and selective export #6104

New Issue

GiteaMirror · 2025-11-11T16:45:01-06:00

GiteaMirror commented

2025-11-11 16:45:01 -06:00

Originally created by @Evolver70 on GitHub (Aug 15, 2025).

Check Existing Issues

I have searched the existing issues and discussions.

Problem Description

Currently, OpenWebUI does not provide a built-in backup/restore system for user configurations, model metadata, prompt templates, or chat history. While it's possible to manually back up the /openwebui/data directory (e.g. via Docker volume), this approach has several limitations:

No version tracking: Restoring a database (SQLite) from an older version to a newer OpenWebUI version can lead to compatibility issues or crashes due to schema changes.
No selective restore: Users cannot choose to restore only specific parts (e.g. prompt templates, model settings) without restoring everything.
No integration with Ollama model storage: Locally downloaded models (via Ollama) are not included in any backup, even though they are essential to the user experience.
No user guidance: There is no in-app warning or tooling to help users safely migrate data across versions or machines.

This makes it risky and technically challenging to move OpenWebUI to a new environment or recover from data loss.

Desired Solution you'd like

I'd like to see a built-in backup & restore system in OpenWebUI with the following features:

1. User-Friendly Backup Tool

A "Backup" button in the settings that creates a .zip archive containing:
- config.json (general settings)
- db.sqlite3 (full database)
- playground/ folder (custom prompt templates)
- Optional: chat history (toggle on/off)
Include a manifest.json with:
- OpenWebUI version
- Timestamp
- List of included components

2. Selective Restore & Version Safety

On restore, detect OpenWebUI version mismatch and warn users if the backup is from an older or newer version.
Allow users to selectively restore:
- Only model metadata & settings
- Only prompt templates
- Only general config
- Exclude chat history (for privacy or size)

3. Ollama Model Integration (Optional but valuable)

Detect if Ollama is running locally
Show list of downloaded models (ollama list)
Allow users to:
- Export selected models via ollama export model_name.zip (to include in backup)
- Import models during restore using ollama import
Note: This would depend on Ollama's installation method (native, WSL, Docker), but could work best-effort with clear user guidance.

4. Export as Human-Readable Format (Bonus)

Option to export prompt templates or model settings as .json or .yaml for easier inspection, sharing, or version control.

This would make OpenWebUI much more robust, user-friendly, and suitable for long-term use — especially for non-technical users or those managing multiple deployments.

Alternatives Considered

No response

Additional Context

No response

Originally created by @Evolver70 on GitHub (Aug 15, 2025). ### Check Existing Issues - [x] I have searched the existing issues and discussions. ### Problem Description Currently, OpenWebUI does not provide a built-in backup/restore system for user configurations, model metadata, prompt templates, or chat history. While it's possible to manually back up the `/openwebui/data` directory (e.g. via Docker volume), this approach has several limitations: - No version tracking: Restoring a database (SQLite) from an older version to a newer OpenWebUI version can lead to compatibility issues or crashes due to schema changes. - No selective restore: Users cannot choose to restore only specific parts (e.g. prompt templates, model settings) without restoring everything. - No integration with Ollama model storage: Locally downloaded models (via Ollama) are not included in any backup, even though they are essential to the user experience. - No user guidance: There is no in-app warning or tooling to help users safely migrate data across versions or machines. This makes it risky and technically challenging to move OpenWebUI to a new environment or recover from data loss. ### Desired Solution you'd like I'd like to see a **built-in backup & restore system** in OpenWebUI with the following features: #### 1. **User-Friendly Backup Tool** - A "Backup" button in the settings that creates a `.zip` archive containing: - `config.json` (general settings) - `db.sqlite3` (full database) - `playground/` folder (custom prompt templates) - Optional: chat history (toggle on/off) - Include a `manifest.json` with: - OpenWebUI version - Timestamp - List of included components #### 2. **Selective Restore & Version Safety** - On restore, detect OpenWebUI version mismatch and warn users if the backup is from an older or newer version. - Allow users to selectively restore: - Only model metadata & settings - Only prompt templates - Only general config - Exclude chat history (for privacy or size) #### 3. **Ollama Model Integration (Optional but valuable)** - Detect if Ollama is running locally - Show list of downloaded models (`ollama list`) - Allow users to: - Export selected models via `ollama export model_name.zip` (to include in backup) - Import models during restore using `ollama import` - Note: This would depend on Ollama's installation method (native, WSL, Docker), but could work best-effort with clear user guidance. #### 4. **Export as Human-Readable Format (Bonus)** - Option to export prompt templates or model settings as `.json` or `.yaml` for easier inspection, sharing, or version control. This would make OpenWebUI much more robust, user-friendly, and suitable for long-term use — especially for non-technical users or those managing multiple deployments. ### Alternatives Considered _No response_ ### Additional Context _No response_

GiteaMirror closed this issue

2025-11-11 16:45:01 -06:00

GiteaMirror commented

2025-11-11 16:45:02 -06:00

@Evolver70 commented on GitHub (Aug 15, 2025):

Extra suggestion: Version-Aware Backup Reminder with User Control

To improve data safety, OpenWebUI could help users ensure they have a recent backup that’s compatible with the currently running version.

How it could work:

On startup, OpenWebUI checks if a backup exists for the current app version (by reading version metadata from a manifest.json or similar file inside each backup).
If no backup is found for this version, show a non-intrusive banner or popup:

"No backup found for v0.4.2. It's recommended to create one now for safe recovery."
With options:
- ✅ Create backup now
- 🚫 Dismiss (don’t show again until the version changes)
- 🗑️ Optionally: Prompt to clean up very old or likely incompatible backups (with clear warning)

Why this helps:

Simple and reliable: no need to detect updates — just check if a backup exists for this version.
Works regardless of how the update was applied (Docker, binary, etc.).
Prevents accidental data loss when rolling back or migrating.

Add a user preference:
Include a toggle in the settings to control this behavior:

🔔 Warn me to create a backup after an OpenWebUI update
(Default: enabled)

This way:

Safety-conscious users get gentle, timely reminders.
Advanced or dev users can disable it if unnecessary.
New users are guided toward good backup habits without confusion.

A small feature with a big impact on peace of mind. 💾

Even if OpenWebUI can't scan backup files directly (e.g. when backups are stored outside the container), it could still track the last known backup state internally using its existing database (db.sqlite3 or equivalent).

How it could work:

When a backup is created (manually via UI or triggered via API), OpenWebUI stores two key values in its database:
- last_successful_backup_version (e.g. v0.4.2)
- last_successful_backup_timestamp (e.g. 2025-04-05T14:30:00Z)
On startup, OpenWebUI checks:
- Is there a recorded backup for the current running version?
- If not → show a soft reminder:
  
  "No backup detected for v0.4.2. Consider creating one before making major changes."

Bonus: Manual override button
Add a UI option:

"✅ Mark this version as backed up"
This allows users who manage backups externally (e.g. scripts, manual copies) to signal that the system is safe.

Why this helps:

Works in all environments — even when backup folders aren't mounted into the container.
Lightweight: uses existing infrastructure (no new file scanning or permissions needed).
User-controlled: avoids nagging those who already have processes in place.

Note: It's not 100% foolproof (e.g. user deletes backup later), but it's a practical, UX-friendly nudge that aligns with real-world usage patterns.

@Evolver70 commented on GitHub (Aug 15, 2025): ### Extra suggestion: Version-Aware Backup Reminder with User Control To improve data safety, OpenWebUI could help users ensure they have a recent backup that’s compatible with the currently running version. **How it could work:** - On startup, OpenWebUI checks if a backup exists **for the current app version** (by reading version metadata from a `manifest.json` or similar file inside each backup). - If **no backup is found for this version**, show a non-intrusive banner or popup: > "No backup found for v0.4.2. It's recommended to create one now for safe recovery." - With options: - ✅ **Create backup now** - 🚫 **Dismiss** (don’t show again until the version changes) - 🗑️ **Optionally**: Prompt to clean up very old or likely incompatible backups (with clear warning) **Why this helps:** - Simple and reliable: no need to detect updates — just check if a backup exists *for this version*. - Works regardless of how the update was applied (Docker, binary, etc.). - Prevents accidental data loss when rolling back or migrating. **Add a user preference:** Include a toggle in the settings to control this behavior: > 🔔 **Warn me to create a backup after an OpenWebUI update** > *(Default: enabled)* This way: - Safety-conscious users get gentle, timely reminders. - Advanced or dev users can disable it if unnecessary. - New users are guided toward good backup habits without confusion. A small feature with a big impact on peace of mind. 💾 --- Even if OpenWebUI can't scan backup files directly (e.g. when backups are stored outside the container), it could still **track the last known backup state internally** using its existing database (`db.sqlite3` or equivalent). **How it could work:** - When a backup is created (manually via UI or triggered via API), OpenWebUI stores two key values in its database: - `last_successful_backup_version` (e.g. `v0.4.2`) - `last_successful_backup_timestamp` (e.g. `2025-04-05T14:30:00Z`) - On startup, OpenWebUI checks: - Is there a recorded backup for the **current running version**? - If not → show a soft reminder: > "No backup detected for v0.4.2. Consider creating one before making major changes." **Bonus: Manual override button** Add a UI option: > "✅ Mark this version as backed up" This allows users who manage backups externally (e.g. scripts, manual copies) to signal that the system is safe. **Why this helps:** - Works in all environments — even when backup folders aren't mounted into the container. - Lightweight: uses existing infrastructure (no new file scanning or permissions needed). - User-controlled: avoids nagging those who already have processes in place. **Note:** It's not 100% foolproof (e.g. user deletes backup later), but it's a practical, UX-friendly nudge that aligns with real-world usage patterns.

GiteaMirror referenced this issue

2025-11-11 18:01:11 -06:00

[PR #6104] [MERGED] fix: ollama embed support list[str] or str on input #8616

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#6104