2026-03-05 19:04:56 +08:00
---
sidebar_position: 2
2026-07-30 21:24:15 +08:00
title: "Backup & Migration"
sidebar_label: "Backup & Migration"
docs: add Tigris as S3-compatible storage backend, fix s3 region field name (#15361)
## Summary
Add Tigris configuration to the Configuration and Backup & migration
pages, using the existing AWS_S3 backend — no code changes required.
Fix `region` → `region_name` in the existing S3 config example in
`backup_and_migration.md`. The code in `s3_conn.py` reads `region_name`,
so the previous field name was silently ignored.
##Context
With MinIO's open-source repository archived (#13840 on
infiniflow/ragflow), users need documented alternatives for object
storage. Tigris is S3-compatible and works with RAGFlow's existing
AWS_S3 backend out of the box.
## Changes
`configurations.md`: Added `### s3 (Tigris)` section after `### minio`,
matching the existing reference style. Includes config block, field
descriptions, and a pointer to `service_conf.yaml.template` for other
S3-compatible backends.
`backup_and_migration.md`: Added Tigris config block under single-bucket
mode. Fixed region → region_name in the existing S3 example. Added
Tigris to the supported backends list.
##Notes
No new files — edits to existing docs only.
Config field names (`access_key`, `secret_key`, `region_name`,
`endpoint_url`, `bucket`, `prefix_path`, `signature_version`,
`addressing_style`) verified against `rag/utils/s3_conn.py`.
2026-06-01 14:47:33 +02:00
slug: /migration
2026-03-05 19:04:56 +08:00
sidebar_custom_props: {
categoryIcon: LucideLocateFixed
}
---
2026-07-30 21:24:15 +08:00
# Backup & Migration
2026-03-05 19:04:56 +08:00
- [Data migration ](#data-migration )
- [Migrate from multi-bucket to single-bucket mode ](#migrate-from-multi-bucket-to-single-bucket-mode )
2026-07-30 21:24:15 +08:00
## Data Migration
2026-03-05 19:04:56 +08:00
:::info KUDOS
This document is contributed by our community contributor [TreeDy ](https://github.com/Treedy2020 ). We may not actively maintain this document.
:::
A common scenario is processing large datasets on a powerful instance (e.g., with a GPU) and then migrating the entire RAGFlow service to a different production environment (e.g., a CPU-only server). This guide explains how to safely back up and restore your data using our provided migration script.
2026-07-30 21:24:15 +08:00
### Identify Your Data
2026-03-05 19:04:56 +08:00
By default, RAGFlow uses Docker volumes to store all persistent data, including your database, uploaded files, and search indexes. You can see these volumes by running:
```bash
docker volume ls
```
The output will look similar to this:
```text
DRIVER VOLUME NAME
local docker_esdata01
local docker_minio_data
local docker_mysql_data
local docker_redis_data
```
These volumes contain all the data you need to migrate.
2026-03-12 19:01:25 +08:00
:::note
The volume name prefix (e.g., `docker_` ) comes from the Docker Compose project name. By default it is `docker` (derived from the directory name). If you started RAGFlow with `docker compose -p <project_name>` , your volumes will be prefixed with `<project_name>_` instead, for example `ragflow_mysql_data` .
:::
2026-07-30 21:24:15 +08:00
### Step 1: Stop RAGFlow Services
2026-03-05 19:04:56 +08:00
Before starting the migration, you must stop all running RAGFlow services on the **source machine ** . Navigate to the project's root directory and run:
```bash
2026-03-12 19:01:25 +08:00
docker compose -f docker/docker-compose.yml down
2026-03-05 19:04:56 +08:00
```
2026-03-12 19:01:25 +08:00
If you started RAGFlow with a custom project name (e.g., `docker compose -p ragflow` ), include it in the command:
```bash
docker compose -p ragflow -f docker/docker-compose.yml down
```
**Important:** Do **not ** use the `-v` flag (e.g., `docker compose down -v` ), as this will delete all your data volumes. The migration script includes a check and will prevent you from running it if services are active.
2026-03-05 19:04:56 +08:00
2026-07-30 21:24:15 +08:00
### Step 2: Back Up Your Data
2026-03-05 19:04:56 +08:00
We provide a convenient script to package all your data volumes into a single backup folder.
For a quick reference of the script's commands and options, you can run:
```bash
bash docker/migration.sh help
```
To create a backup, run the following command from the project's root directory:
```bash
bash docker/migration.sh backup
```
This will create a `backup/` folder in your project root containing compressed archives of your data volumes.
You can also specify a custom name for your backup folder:
```bash
bash docker/migration.sh backup my_ragflow_backup
```
This will create a folder named `my_ragflow_backup/` instead.
2026-03-12 19:01:25 +08:00
If you started RAGFlow with a custom project name (e.g., `docker compose -p ragflow` ), use the `-p` flag so the script can find the correct volumes:
```bash
bash docker/migration.sh -p ragflow backup
bash docker/migration.sh -p ragflow backup my_ragflow_backup
```
2026-07-30 21:24:15 +08:00
### Step 3: Transfer the Backup Folder
2026-03-05 19:04:56 +08:00
Copy the entire backup folder (e.g., `backup/` or `my_ragflow_backup/` ) from your source machine to the RAGFlow project directory on your **target machine ** . You can use tools like `scp` , `rsync` , or a physical drive for the transfer.
2026-07-30 21:24:15 +08:00
### Step 4: Restore Your Data
2026-03-05 19:04:56 +08:00
On the **target machine ** , ensure that RAGFlow services are not running. Then, use the migration script to restore your data from the backup folder.
If your backup folder is named `backup/` , run:
```bash
bash docker/migration.sh restore
```
If you used a custom name, specify it in the command:
```bash
bash docker/migration.sh restore my_ragflow_backup
```
2026-03-12 19:01:25 +08:00
If the target machine uses a custom project name, use the `-p` flag to ensure the volumes are created with the correct prefix:
```bash
bash docker/migration.sh -p ragflow restore
bash docker/migration.sh -p ragflow restore my_ragflow_backup
```
2026-03-05 19:04:56 +08:00
The script will automatically create the necessary Docker volumes and unpack the data.
**Note:** If the script detects that Docker volumes with the same names already exist on the target machine, it will warn you that restoring will overwrite the existing data and ask for confirmation before proceeding.
2026-07-30 21:24:15 +08:00
### Step 5: Start RAGFlow Services
2026-03-05 19:04:56 +08:00
Once the restore process is complete, you can start the RAGFlow services on your new machine:
```bash
2026-03-12 19:01:25 +08:00
docker compose -f docker/docker-compose.yml up -d
```
If you use a custom project name:
```bash
docker compose -p ragflow -f docker/docker-compose.yml up -d
2026-03-05 19:04:56 +08:00
```
2026-03-12 19:01:25 +08:00
**Note:** If you already have built a service by docker compose before, you may need to backup your data for target machine like this guide above and run like:
2026-03-05 19:04:56 +08:00
```bash
2026-03-12 19:01:25 +08:00
# Please backup by `bash docker/migration.sh backup backup_dir_name` before you do the following line.
2026-03-05 19:04:56 +08:00
# !!! this line -v flag will delete the original docker volume
2026-03-12 19:01:25 +08:00
docker compose -f docker/docker-compose.yml down -v
docker compose -f docker/docker-compose.yml up -d
2026-03-05 19:04:56 +08:00
```
Your RAGFlow instance is now running with all the data from your original machine.
2026-07-30 21:24:15 +08:00
## Migrate from Multi-Bucket to Single-Bucket Mode
2026-03-05 19:04:56 +08:00
:::info KUDOS
This document is contributed by our community contributor [arogan178 ](https://github.com/arogan178 ). We may not actively maintain this document.
:::
By default, RAGFlow creates one bucket per Knowledge Base (dataset) and one bucket per user folder. This can be problematic when:
- Your cloud provider charges per bucket
- Your IAM policy restricts bucket creation
- You want all data organized in a single bucket with directory structure
The **Single Bucket Mode ** allows you to configure RAGFlow to use a single bucket with a directory structure instead of multiple buckets.
2026-07-30 21:24:15 +08:00
### How It Works
2026-03-05 19:04:56 +08:00
2026-07-30 21:24:15 +08:00
#### Default Mode (Multiple Buckets)
2026-03-05 19:04:56 +08:00
```
bucket: kb_12345/
└── document_1.pdf
bucket: kb_67890/
└── document_2.pdf
bucket: folder_abc/
└── file_3.txt
```
2026-07-30 21:24:15 +08:00
#### Single Bucket Mode (With Prefix_path)
2026-03-05 19:04:56 +08:00
```
bucket: ragflow-bucket/
└── ragflow/
├── kb_12345/
│ └── document_1.pdf
├── kb_67890/
│ └── document_2.pdf
└── folder_abc/
└── file_3.txt
```
### Configuration
2026-07-30 21:24:15 +08:00
#### MinIO Configuration
2026-03-05 19:04:56 +08:00
Edit your `service_conf.yaml` or set environment variables:
```yaml
minio:
user: "your-access-key"
password: "your-secret-key"
host: "minio.example.com:443"
bucket: "ragflow-bucket" # Default bucket name
prefix_path: "ragflow" # Optional prefix path
```
Or using environment variables:
```bash
export MINIO_USER=your-access-key
export MINIO_PASSWORD=your-secret-key
export MINIO_HOST=minio.example.com:443
export MINIO_BUCKET=ragflow-bucket
export MINIO_PREFIX_PATH=ragflow
```
2026-07-30 21:24:15 +08:00
#### S3 Configuration (Already Supported)
2026-03-05 19:04:56 +08:00
```yaml
s3:
access_key: "your-access-key"
secret_key: "your-secret-key"
endpoint_url: "https://s3.amazonaws.com"
bucket: "my-ragflow-bucket"
prefix_path: "production"
docs: add Tigris as S3-compatible storage backend, fix s3 region field name (#15361)
## Summary
Add Tigris configuration to the Configuration and Backup & migration
pages, using the existing AWS_S3 backend — no code changes required.
Fix `region` → `region_name` in the existing S3 config example in
`backup_and_migration.md`. The code in `s3_conn.py` reads `region_name`,
so the previous field name was silently ignored.
##Context
With MinIO's open-source repository archived (#13840 on
infiniflow/ragflow), users need documented alternatives for object
storage. Tigris is S3-compatible and works with RAGFlow's existing
AWS_S3 backend out of the box.
## Changes
`configurations.md`: Added `### s3 (Tigris)` section after `### minio`,
matching the existing reference style. Includes config block, field
descriptions, and a pointer to `service_conf.yaml.template` for other
S3-compatible backends.
`backup_and_migration.md`: Added Tigris config block under single-bucket
mode. Fixed region → region_name in the existing S3 example. Added
Tigris to the supported backends list.
##Notes
No new files — edits to existing docs only.
Config field names (`access_key`, `secret_key`, `region_name`,
`endpoint_url`, `bucket`, `prefix_path`, `signature_version`,
`addressing_style`) verified against `rag/utils/s3_conn.py`.
2026-06-01 14:47:33 +02:00
region_name: "us-east-1"
2026-03-05 19:04:56 +08:00
```
2026-07-30 21:24:15 +08:00
#### Tigris Configuration
docs: add Tigris as S3-compatible storage backend, fix s3 region field name (#15361)
## Summary
Add Tigris configuration to the Configuration and Backup & migration
pages, using the existing AWS_S3 backend — no code changes required.
Fix `region` → `region_name` in the existing S3 config example in
`backup_and_migration.md`. The code in `s3_conn.py` reads `region_name`,
so the previous field name was silently ignored.
##Context
With MinIO's open-source repository archived (#13840 on
infiniflow/ragflow), users need documented alternatives for object
storage. Tigris is S3-compatible and works with RAGFlow's existing
AWS_S3 backend out of the box.
## Changes
`configurations.md`: Added `### s3 (Tigris)` section after `### minio`,
matching the existing reference style. Includes config block, field
descriptions, and a pointer to `service_conf.yaml.template` for other
S3-compatible backends.
`backup_and_migration.md`: Added Tigris config block under single-bucket
mode. Fixed region → region_name in the existing S3 example. Added
Tigris to the supported backends list.
##Notes
No new files — edits to existing docs only.
Config field names (`access_key`, `secret_key`, `region_name`,
`endpoint_url`, `bucket`, `prefix_path`, `signature_version`,
`addressing_style`) verified against `rag/utils/s3_conn.py`.
2026-06-01 14:47:33 +02:00
[Tigris ](https://www.tigrisdata.com ) is an S3-compatible object storage service that works with RAGFlow's `AWS_S3` backend. Set `STORAGE_IMPL=AWS_S3` in your `.env` file:
```yaml
s3:
access_key: "tid_YOUR_ACCESS_KEY"
secret_key: "tsec_YOUR_SECRET_KEY"
region_name: "auto"
endpoint_url: "https://t3.storage.dev"
bucket: "ragflow"
prefix_path: "ragflow"
signature_version: "v4"
addressing_style: "virtual"
```
See [S3 (Tigris) ](/configurations#s3-tigris ) for full setup instructions.
2026-07-30 21:24:15 +08:00
### Iam Policy Example
2026-03-05 19:04:56 +08:00
When using single bucket mode, you only need permissions for one bucket:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:*"],
"Resource": [
"arn:aws:s3:::ragflow-bucket",
"arn:aws:s3:::ragflow-bucket/*"
]
}
]
}
```
2026-07-30 21:24:15 +08:00
### Migration from Multi-Bucket to Single Bucket
2026-03-05 19:04:56 +08:00
If you're migrating from multi-bucket mode to single-bucket mode:
1. **Set environment variables ** for the new configuration
2. **Restart RAGFlow ** services
3. **Migrate existing data ** (optional):
```bash
# Example using mc (MinIO Client)
mc alias set old-minio http://old-minio:9000 ACCESS_KEY SECRET_KEY
mc alias set new-minio https://new-minio:443 ACCESS_KEY SECRET_KEY
# List all knowledge base buckets
mc ls old-minio/ | grep kb_ | while read -r line; do
bucket=$(echo $line | awk '{print $5}')
# Copy each bucket to the new structure
mc cp --recursive old-minio/$bucket/ new-minio/ragflow-bucket/ragflow/$bucket/
done
```
2026-07-30 21:24:15 +08:00
### Toggle Between Modes
2026-03-05 19:04:56 +08:00
2026-07-30 21:24:15 +08:00
#### Enable Single Bucket Mode
2026-03-05 19:04:56 +08:00
```yaml
minio:
bucket: "my-single-bucket"
prefix_path: "ragflow"
```
2026-07-30 21:24:15 +08:00
#### Disable (Use Multi-Bucket Mode)
2026-03-05 19:04:56 +08:00
```yaml
minio:
# Leave bucket and prefix_path empty or commented out
# bucket: ''
# prefix_path: ''
```
### Troubleshooting
2026-07-30 21:24:15 +08:00
#### Issue: Access Denied Errors
2026-03-05 19:04:56 +08:00
**Solution**: Ensure your IAM policy grants access to the bucket specified in the configuration.
2026-07-30 21:24:15 +08:00
#### Issue: Files Not Found After Switching Modes
2026-03-05 19:04:56 +08:00
**Solution**: The path structure changes between modes. You'll need to migrate existing data.
2026-07-30 21:24:15 +08:00
#### Issue: Connection Fails with HTTPS
2026-03-05 19:04:56 +08:00
**Solution**: Ensure `secure: True` is set in the MinIO connection (automatically handled for port 443).
2026-07-30 21:24:15 +08:00
### Storage Backends Supported
2026-03-05 19:04:56 +08:00
- ✅ **MinIO ** - Full support with single bucket mode
- ✅ **AWS S3 ** - Full support with single bucket mode
docs: add Tigris as S3-compatible storage backend, fix s3 region field name (#15361)
## Summary
Add Tigris configuration to the Configuration and Backup & migration
pages, using the existing AWS_S3 backend — no code changes required.
Fix `region` → `region_name` in the existing S3 config example in
`backup_and_migration.md`. The code in `s3_conn.py` reads `region_name`,
so the previous field name was silently ignored.
##Context
With MinIO's open-source repository archived (#13840 on
infiniflow/ragflow), users need documented alternatives for object
storage. Tigris is S3-compatible and works with RAGFlow's existing
AWS_S3 backend out of the box.
## Changes
`configurations.md`: Added `### s3 (Tigris)` section after `### minio`,
matching the existing reference style. Includes config block, field
descriptions, and a pointer to `service_conf.yaml.template` for other
S3-compatible backends.
`backup_and_migration.md`: Added Tigris config block under single-bucket
mode. Fixed region → region_name in the existing S3 example. Added
Tigris to the supported backends list.
##Notes
No new files — edits to existing docs only.
Config field names (`access_key`, `secret_key`, `region_name`,
`endpoint_url`, `bucket`, `prefix_path`, `signature_version`,
`addressing_style`) verified against `rag/utils/s3_conn.py`.
2026-06-01 14:47:33 +02:00
- ✅ **Tigris ** - Full support with single bucket mode (uses `AWS_S3` backend)
2026-03-05 19:04:56 +08:00
- ✅ **Alibaba OSS ** - Full support with single bucket mode
- ✅ **Azure Blob ** - Uses container-based structure (different paradigm)
- ⚠️ **OpenDAL ** - Depends on underlying storage backend
2026-07-30 21:24:15 +08:00
### Performance Considerations
2026-03-05 19:04:56 +08:00
- **Single bucket mode** may have slightly better performance for bucket listing operations
- **Multi-bucket mode** provides better isolation and organization for large deployments
- Choose based on your specific requirements and infrastructure constraints