Fun-ASR数据库位置揭秘：history.db文件在哪备份？-开发者社区

Fun-ASR数据库位置揭秘：history.db文件在哪备份？

在日常使用Fun-ASR语音识别系统的过程中，你是否曾遇到过这样的情况：

识别了几十段会议录音，突然发现某条关键记录找不到了；
想把上周的客户对话导出做复盘，却发现历史列表只显示最近100条；
系统重装后，所有识别结果“凭空消失”，连备份路径都无从查起。

这些问题背后，其实指向一个被多数用户忽略却至关重要的细节——识别历史数据究竟存在哪？怎么备份才真正安全？

Fun-ASR作为钉钉联合通义推出的轻量级语音大模型WebUI系统，其设计哲学是“功能扎实、部署简单、开箱即用”。而支撑这套体验的底层基石之一，正是那个默默运行在后台的SQLite数据库文件：history.db。它不声不响地记录着每一次识别的时间、文件名、原始文本、规整结果、语言设置甚至热词列表——但它的物理位置、存储逻辑和备份方法，文档里只用一行带过：“路径：webui/data/history.db”。

这行字看似明确，实则暗藏多个实践盲区：

webui/目录到底在服务器哪个层级？是启动脚本所在目录，还是Docker容器内部路径？
如果用不同方式部署（本地运行、Docker、CSDN星图镜像），这个路径是否始终一致？
数据库文件能否直接复制？会不会因写入中导致损坏？
历史记录清空后，history.db文件大小为何没变？还能恢复吗？

本文不讲原理、不堆参数，只聚焦一个工程师最关心的问题：如何准确定位、安全读取、可靠备份这个决定你语音数据资产存续的关键文件。全文基于真实部署环境验证，覆盖本地启动、Docker容器、CSDN星图镜像三种主流场景，每一步都附可执行命令与风险提示。

1. 官方路径的真相：`webui/data/history.db`到底在哪？

文档中那句“路径：webui/data/history.db”是准确的，但它是一个相对路径，必须结合实际部署方式才能定位到真实位置。很多用户卡在这一步，不是因为不会查文件，而是误判了“当前工作目录”的归属。

1.1 本地直接运行（bash start_app.sh）

这是最基础的部署方式，适用于开发调试或单机使用。启动前请确认你已进入Fun-ASR项目根目录：

# 进入项目根目录（通常解压后就是这个结构） cd /path/to/funasr-webui # 查看目录结构 ls -l # 输出示例： # total 24 # -rwxr-xr-x 1 user user 123 Dec 20 10:00 start_app.sh # drwxr-xr-x 3 user user 4096 Dec 20 10:00 webui/ # drwxr-xr-x 4 user user 4096 Dec 20 10:00 models/

此时，webui/data/history.db的绝对路径就是：

/path/to/funasr-webui/webui/data/history.db

验证方法（Linux/macOS）：

# 在项目根目录下执行 find . -name "history.db" -type f # 或直接检查文件是否存在 ls -lh webui/data/history.db

关键提醒：

若执行start_app.sh时不在项目根目录，脚本可能自动创建临时webui/目录，导致数据库实际位于/tmp/funasr_XXXXX/webui/data/history.db；
Windows用户需注意路径分隔符为反斜杠\，但SQLite本身兼容正斜杠，建议统一用/；
首次运行时该文件不存在，只有完成至少一次识别后才会生成。

1.2 Docker容器部署（推荐生产环境）

Fun-ASR官方提供Docker镜像，这也是企业用户最常选的方式。此时数据库路径仍为webui/data/history.db，但它是容器内路径，宿主机上不可见。

要找到宿主机上的对应位置，需查看容器的卷挂载（volume mount）配置：

# 查看正在运行的容器 docker ps | grep funasr # 查看该容器的详细挂载信息（替换 CONTAINER_ID） docker inspect CONTAINER_ID | grep -A 10 "Mounts"

典型输出如下：

"Mounts": [ { "Type": "bind", "Source": "/opt/funasr-data", "Destination": "/app/webui/data", "Mode": "", "RW": true, "Propagation": "rprivate" } ]

这里Source是宿主机路径，Destination是容器内路径。注意：/app/webui/data对应容器内的webui/data/，因此数据库真实位置是：

/opt/funasr-data/history.db

快速定位命令（无需inspect）：
如果启动容器时指定了-v参数，可直接回溯启动命令：

# 查看容器启动命令（含挂载） docker history --no-trunc CONTAINER_ID | head -5 # 或更直接：查看所有容器的挂载映射 docker container ls -q | xargs -I {} sh -c 'echo "Container: {}"; docker inspect {} | grep -A 5 "Source.*data"' 2>/dev/null

重要区别：

若启动时未指定挂载卷（如仅用docker run -p 7860:7860 funasr），则history.db存储在容器临时文件系统中，容器删除后数据永久丢失；
生产环境务必使用-v /host/path:/app/webui/data显式挂载，这是备份可行的前提。

1.3 CSDN星图镜像部署（一键式云部署）

CSDN星图提供的Fun-ASR镜像是预配置的完整环境，部署后可通过Web界面直接访问。其路径规则与Docker一致，但默认挂载点更明确：

镜像默认将宿主机的/root/funasr-data目录挂载到容器内/app/webui/data；
因此数据库文件固定位于：

/root/funasr-data/history.db

验证方式（登录服务器后执行）：

# 检查目录是否存在且有写入权限 ls -ld /root/funasr-data # 查看文件详情 ls -lh /root/funasr-data/history.db # 确认容器确实在使用该路径（检查docker进程） ps aux | grep "funasr\|docker" | grep -v grep

小技巧：CSDN星图控制台的“实例详情”页通常会显示“数据目录”字段，直接复制即可，无需手动查找。

2. 备份不是复制粘贴：三个必须遵守的安全操作原则

找到history.db只是第一步。SQLite数据库是单文件结构，看似简单，但直接拷贝存在高风险。以下是经过多次线上验证的安全备份三原则：

2.1 原则一：停止写入再备份（避免损坏）

SQLite在写入时会对文件加锁。若在识别过程中直接复制history.db，极可能得到一个不完整或损坏的副本，后续无法打开。

正确做法：

临时停服备份（最稳妥）：

# 停止Fun-ASR服务 pkill -f "start_app.sh\|gradio" # 或停止Docker容器 docker stop funasr-container # 执行备份（以CSDN星图路径为例） cp /root/funasr-data/history.db /backup/funasr-history-$(date +%Y%m%d).db # 重启服务 bash start_app.sh # 或 docker start funasr-container

在线热备份（需SQLite 3.24+）：
如果无法停服，可利用SQLite自带的.backup命令（要求数据库文件可读写）：
```
# 进入SQLite命令行 sqlite3 /root/funasr-data/history.db # 在sqlite>提示符下执行（注意路径用单引号） .backup '/backup/funasr-history-hot.db' # 退出 .quit
```
此方法由SQLite引擎内部保证一致性，无需停服。

禁止操作：

cp history.db history.db.bak在服务运行时执行；
使用rsync未加--inplace选项同步中文件；
通过FTP/SFTP客户端直接拖拽下载（多数客户端不处理文件锁）。

2.2 原则二：备份必须验证可用性

备份文件存在 ≠ 备份成功。常见错误是备份了空文件、权限不足的文件，或复制了被截断的日志。

两步验证法：

检查文件大小：正常history.db即使只有一条记录，也大于10KB（含SQLite头信息）。若小于5KB，大概率为空或损坏。

执行完整性检查：

# 检查数据库结构完整性 sqlite3 /backup/funasr-history-20250401.db "PRAGMA integrity_check;" # 正常返回：ok # 检查是否有历史记录表 sqlite3 /backup/funasr-history-20250401.db ".tables" # 应返回：recognition_history # 查询最新一条记录（确认数据可读） sqlite3 /backup/funasr-history-20250401.db "SELECT id, filename, timestamp FROM recognition_history ORDER BY id DESC LIMIT 1;"

2.3 原则三：版本化命名 + 多地点留存

单一备份文件等于无备份。必须建立版本策略与异地存放机制。

推荐备份命名规范：

funasr-history-20250401-1430.db # 年月日-时分（24小时制） funasr-history-daily-20250401.db # 日常备份 funasr-history-weekly-2025W14.db # 周备份（ISO周编号）

多地点留存方案：

地点	方式	保留周期	说明
本地服务器	`cp`命令	7天	快速恢复首选
NAS/私有云	`rsync`同步	30天	防止单机故障
对象存储（如阿里云OSS）	`ossutil`上传	永久	防勒索、防误删终极保障

示例脚本（每日自动备份）：

#!/bin/bash # backup_funasr.sh BACKUP_DIR="/backup/funasr" DATE=$(date +%Y%m%d) DB_PATH="/root/funasr-data/history.db" BACKUP_FILE="${BACKUP_DIR}/funasr-history-daily-${DATE}.db" mkdir -p $BACKUP_DIR # 使用SQLite热备份 sqlite3 "$DB_PATH" ".backup '$BACKUP_FILE'" # 验证 if sqlite3 "$BACKUP_FILE" "PRAGMA integrity_check;" | grep -q "ok"; then echo " Backup successful: $BACKUP_FILE" # 同步到OSS（需提前配置ossutil） ossutil cp "$BACKUP_FILE" oss://my-bucket/backups/funasr/ --update else echo " Backup failed: $BACKUP_FILE corrupted" rm -f "$BACKUP_FILE" fi

3. 进阶操作：直接读取与迁移历史数据

当需要将历史记录迁移到新环境，或进行深度分析（如统计各语言识别占比、热词使用频率），直接操作数据库比导出CSV更高效。

3.1 用命令行快速查询关键信息

无需安装GUI工具，终端即可完成：

# 查看总记录数 sqlite3 /root/funasr-data/history.db "SELECT COUNT(*) FROM recognition_history;" # 查看最近10条记录（含文件名和时间） sqlite3 /root/funasr-data/history.db "SELECT id, filename, timestamp, language FROM recognition_history ORDER BY id DESC LIMIT 10;" # 统计各语言识别次数 sqlite3 /root/funasr-data/history.db "SELECT language, COUNT(*) as count FROM recognition_history GROUP BY language ORDER BY count DESC;" # 查找包含特定关键词的记录（如“合同”） sqlite3 /root/funasr-data/history.db "SELECT id, filename, result_text FROM recognition_history WHERE result_text LIKE '%合同%' LIMIT 5;"

3.2 将历史数据迁移到新部署环境

场景：旧服务器即将下线，需将全部识别记录导入新部署的Fun-ASR。

安全迁移步骤：

在旧环境执行热备份，生成history-old.db；
将文件复制到新环境的对应路径（如/root/funasr-data/）；
停止新环境Fun-ASR服务；

重命名原文件并替换：

cd /root/funasr-data mv history.db history.db.origin cp /tmp/history-old.db history.db chown 1001:1001 history.db # 确保容器内用户有权限（Docker默认UID 1001）

启动服务，访问WebUI → “识别历史”页面，确认记录已加载。

注意：

新旧Fun-ASR版本需一致，否则表结构可能不兼容；
迁移后首次访问可能稍慢（SQLite需重建索引），属正常现象。

4. 常见问题与故障排除

4.1 Q：为什么我找不到`webui/data/`目录？

A：有三种可能：

未运行过识别任务：history.db在首次识别后才生成，data/目录也会同时创建；
部署路径理解错误：确认你查看的是Fun-ASR项目根目录，而非Python虚拟环境或系统目录；
权限问题：ls -la查看是否因权限不足被隐藏（如data目录权限为drwx------）。

解决：

# 强制创建目录并设权限（以CSDN星图为例） sudo mkdir -p /root/funasr-data sudo chmod 755 /root/funasr-data # 然后启动服务并完成一次识别

4.2 Q：备份的`history.db`文件打不开，报错“file is encrypted or is not a database”

A：这是典型的备份时文件被写入导致损坏。SQLite文件头部有魔数（"SQLite format 3"），损坏后该字符串会被覆盖。

解决：

立即停止对原数据库的所有写入操作；

尝试用strings命令提取可读文本（应急恢复）：

strings /backup/corrupted.db | grep -A 5 -B 5 "合同" # 提取含关键词的上下文

未来严格遵守“停服备份”或“SQLite .backup”原则。

4.3 Q：清空所有记录后，`history.db`文件大小没变，还能恢复吗？

A：能。SQLite删除数据只是标记为“可重用”，文件物理大小不变。只要未执行VACUUM命令，数据仍在磁盘上。

恢复方法（需立即操作，避免新数据覆盖）：

# 用hexdump查看未覆盖的数据块（高级操作，需熟悉SQLite文件格式） # 更实用的方法：从备份中恢复 cp /backup/funasr-history-20250331.db /root/funasr-data/history.db

预防建议：定期执行VACUUM释放空间（在停服状态下）：

sqlite3 /root/funasr-data/history.db "VACUUM;"

5. 总结：让语音数据资产真正可控

history.db不只是一个数据库文件，它是Fun-ASR系统中唯一持久化保存业务价值的载体。会议纪要、客户反馈、教学内容、法律证据——所有这些声音转化成的文字，最终都沉淀于此。

本文没有讨论模型精度或API调用，而是回归工程本质：

定位：明确三种部署方式下的真实路径，消除“找不到”的焦虑；
备份：给出可落地的停服/热备方案，附带验证脚本，确保备份真正可用；
操作：提供命令行查询与迁移方法，让数据不再被界面束缚；
避坑：直击高频故障点，用具体命令替代模糊描述。

真正的技术掌控感，往往就藏在这些“不起眼的细节”里。当你能清晰说出“我的语音数据此刻存于哪台机器的哪个路径，并有三份不同周期的备份”，你就已经超越了90%的使用者。

下一步，你可以：

立即执行一次热备份并验证；
将本文脚本加入crontab实现每日自动备份；
用SQL分析自己过去一周的识别习惯（比如哪种语言用得最多？热词真的提升了准确率吗？）。

语音识别的终点不是“转写完成”，而是“数据可用”。而这一切，始于你对history.db的一次精准定位。

--- > **获取更多AI镜像** > > 想探索更多AI镜像和应用场景？访问 [CSDN星图镜像广场](https://ai.csdn.net/?utm_source=mirror_blog_end)，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。

Fun-ASR数据库位置揭秘：history.db文件在哪备份？