如何备份和迁移Fun-ASR的历史数据库（history.db）-育师

如何备份和迁移Fun-ASR的历史数据库（history.db）

在语音识别系统逐渐成为智能办公、会议纪要和客服质检的关键工具时，用户往往积累了大量有价值的识别记录。这些数据不仅是工作成果的体现，也可能包含后续分析或模型优化所需的重要语料。对于使用 Fun-ASR 的开发者和团队来说，一个看似简单却至关重要的问题浮出水面：当更换设备、重装系统或需要共享历史记录时，如何确保“识别历史”不丢失？

答案藏在一个名为history.db的文件里。

从一次误删说起：为什么 history.db 值得被重视？

不少用户第一次意识到history.db的重要性，是在不小心删除项目目录后发现——所有曾经识别过的音频记录都消失了。没有导出功能，也没有云端同步提示，一切仿佛从未发生。

这背后的原因其实很清晰：Fun-ASR 使用 SQLite 作为本地持久化存储引擎，将每一次识别任务的关键信息写入位于webui/data/history.db的单个数据库文件中。这个设计极大简化了部署流程，无需额外安装数据库服务，但也意味着——你的全部历史，就在这一个文件里。

一旦它损坏、被覆盖或未及时备份，数据恢复将变得极为困难。

所以，掌握它的备份与迁移方法，并非高阶运维技巧，而是保障工作效率的基础能力。

深入理解：history.db 到底存了什么？

history.db是一个标准的 SQLite 数据库文件，结构简洁但信息丰富。通过 Python 脚本可以轻松查看其内容：

import sqlite3 conn = sqlite3.connect('webui/data/history.db') cursor = conn.cursor() # 查看 records 表结构 cursor.execute("PRAGMA table_info(records)") print("表结构：") for col in cursor.fetchall(): print(col) # 查询最近10条记录 cursor.execute(""" SELECT id, timestamp, filename, language, result_text FROM records ORDER BY timestamp DESC LIMIT 10 """) rows = cursor.fetchall() print("\n最近10条识别记录：") for row in rows: print(f"ID: {row[0]}, 时间: {row[1]}, 文件: {row[2]}, 语言: {row[3]}") print(f"文本: {row[4][:100]}...") print("-" * 50) conn.close()

典型的字段包括：

id: 自增主键
timestamp: 任务完成时间戳
filename: 音频原始文件名（注意是名称而非路径）
language: 目标识别语言
result_text: 最终输出文本（可能经过ITN规整）
hotwords: 使用的热词列表
config_md5: 当前识别配置的哈希值，用于快速比对设置差异

这些元数据构成了完整的识别上下文，使得用户可以在 WebUI 中按时间、关键词搜索、重新导出结果，甚至对比不同参数下的识别效果。

正因为如此，保护好这个.db文件，本质上就是在保护你积累的“语音资产”。

实战操作：四步完成安全迁移

迁移的本质很简单——复制文件。但在实际操作中，稍有不慎就会导致失败。以下是经过验证的安全流程。

第一步：彻底关闭 Fun-ASR 服务

这是最关键的一步。SQLite 在写入过程中会加锁，若此时强行复制，可能导致数据库损坏或出现“database is locked”错误。

如果你是通过脚本启动的：

# 查找并终止进程 ps aux | grep python kill -9 <PID>

或者直接关闭运行start_app.sh的终端窗口。

🛑 切记不要只刷新页面或退出浏览器，后端仍在运行！

第二步：定位并备份 history.db

进入项目根目录，找到目标文件：

cd /path/to/Fun-ASR

推荐采用带时间戳的命名方式，便于版本管理：

# 创建备份目录 mkdir -p ./backup # 执行备份 cp webui/data/history.db ./backup/history.db_$(date +%Y%m%d_%H%M%S).bak

这样每次备份都有明确的时间标识，避免混淆。

你还可以加入自动清理旧备份的逻辑：

# 清理30天前的备份 find ./backup -name "history.db_*.bak" -mtime +30 -delete

将其写入定时任务（crontab），即可实现无人值守的周期性备份。

第三步：迁移到新环境

将备份文件传输到目标机器（可通过U盘、scp、rsync等方式）：

# 示例：使用 scp 上传到远程服务器 scp ./backup/history.db_20250405_100000.bak user@new-host:/home/user/Fun-ASR/webui/data/history.db

在新环境中确保目录结构完整：

mkdir -p webui/data/

然后替换为备份文件：

cp /path/to/received/history.db webui/data/history.db

务必确认文件名为history.db，且权限可读可写：

chmod 644 webui/data/history.db

第四步：启动验证

启动服务：

bash start_app.sh

访问http://localhost:7860，点击【识别历史】模块。

✅ 成功标志：
- 页面正常加载；
- 原有的识别记录完整显示；
- 可搜索、查看详情、再次下载文本。

如果一切正常，说明迁移成功。

常见问题与应对策略

迁移后记录为空或不显示？

别急着重来，先排查以下几个常见原因：

1. 文件路径错误

最常见的是把history.db放到了错误目录，比如./data/而不是webui/data/。请严格对照官方目录结构。

2. 文件权限不足

Linux/macOS 下，若当前运行用户无读取权限，会导致加载失败。执行：

ls -l webui/data/history.db

应看到类似-rw-r--r--的权限。否则用以下命令修复：

chmod 644 webui/data/history.db

3. 数据库文件已损坏

可使用 SQLite 内建命令检查完整性：

sqlite3 webui/data/history.db "PRAGMA integrity_check;"

若返回不是ok，则说明文件损坏。此时只能尝试从更早的备份恢复。

数据库越来越大，影响系统响应速度怎么办？

随着识别任务增多，history.db可能达到几百MB甚至上GB。虽然 SQLite 对大文件支持良好，但频繁查询仍会影响前端性能。

建议采取以下措施：

定期归档与清理

在 WebUI 中手动删除不再需要的记录。若数量庞大，可直接操作数据库：

-- 删除超过3个月的记录 DELETE FROM records WHERE timestamp < '2025-01-01'; -- 重建表以释放空间（VACUUM） VACUUM;

⚠️ 注意：执行前务必备份！

导出重要数据后重建

保留关键任务的识别结果（如导出为 CSV），然后删除原history.db，重启系统自动生成空数据库。这是一种“轻装上阵”的有效做法。

多人共用一台服务器怎么处理？

目前 Fun-ASR 默认不支持多用户隔离，所有人均访问同一个history.db，容易造成记录混杂。

可行的解决方案有三种：

方案一：独立工作目录

为每位用户分配独立的 Fun-ASR 副本：

/user_a/Fun-ASR/ /user_b/Fun-ASR/

各自拥有独立的history.db，互不干扰。

方案二：动态配置路径

修改启动脚本或配置文件，使不同用户连接不同的数据路径：

# 启动时指定环境变量 DATABASE_PATH=/home/user_a/data/history.db bash start_app.sh

需后端代码支持该变量读取。

方案三：容器化部署（推荐）

使用 Docker 为每个用户创建独立容器实例：

version: '3' services: funasr: image: funasr/webui volumes: - ./user_data/history.db:/app/webui/data/history.db ports: - "7861:7860"

既实现资源隔离，又便于统一管理和扩展。

高阶建议：让备份更智能、更安全

自动化备份脚本示例

#!/bin/bash # 自动备份 history.db 并保留最近7天 PROJECT_DIR="/home/user/Fun-ASR" BACKUP_DIR="$PROJECT_DIR/backup" DATE_STAMP=$(date +"%Y%m%d_%H%M%S") # 创建备份目录 mkdir -p "$BACKUP_DIR" # 执行备份 cp "$PROJECT_DIR/webui/data/history.db" "$BACKUP_DIR/history.db.$DATE_STAMP.bak" # 清理7天前的备份 find "$BACKUP_DIR" -name "history.db.*.bak" -mtime +7 -delete echo "Backup completed: history.db.$DATE_STAMP.bak"

加入 crontab 实现每日凌晨自动执行：

0 2 * * * /home/user/scripts/backup_funasr.sh

敏感数据如何防护？

若识别内容涉及隐私（如客户对话、内部会议），仅本地存储存在泄露风险。

可考虑以下增强方案：

文件级加密

使用gpg或openssl对备份文件加密：

# 加密 openssl aes-256-cbc -salt -in history.db.bak -out history.db.bak.enc # 解密 openssl aes-256-cbc -d -salt -in history.db.bak.enc -out history.db.bak

密码建议由密码管理器保管。

使用 sqlcipher 替代 SQLite

sqlcipher是 SQLite 的加密分支，支持透明加密：

import sqlite3 from pysqlcipher3 import dbapi2 as sqlite conn = sqlite.connect('webui/data/history.db') conn.execute("PRAGMA key='your-strong-password'")

但需修改 Fun-ASR 后端依赖，属于深度定制。

关于云同步的警告

不少人试图将webui/data/文件夹放入网盘（如iCloud、百度网盘、OneDrive）实现“自动同步”。这种做法风险极高。

SQLite 文件在写入时会产生临时文件和锁机制（如-wal,-shm），而大多数网盘无法正确处理这类并发状态，极易导致：

数据库损坏
同步冲突
应用崩溃

✅ 正确做法是：
1. 停止服务
2. 手动复制history.db
3. 触发同步
4. 启动服务

即“离线同步”，杜绝实时监控目录。

写在最后：小文件，大价值

history.db看似只是一个不起眼的数据库文件，但它承载的是用户的使用轨迹、识别成果和潜在的数据资产。它的轻量设计降低了入门门槛，也提醒我们：越是简单的机制，越需要谨慎对待。

在未来，我们可以期待 Fun-ASR 引入更多高级特性，例如：
- 支持导出/导入历史记录包（.funasr-history）
- 提供 WebUI 内置一键备份按钮
- 接入轻量级后端服务实现多端同步
- 结合对象存储实现自动归档

但在当下，掌握手动备份与迁移的能力，依然是每一位使用者必须具备的基本功。

毕竟，技术可以迭代，但数据一旦丢失，就再也回不来了。

如何备份和迁移Fun-ASR的历史数据库（history.db）