定时备份脚本编写：每天凌晨自动执行
在本地部署的 AI 应用日益普及的今天，一个看似不起眼的问题正悄然浮现：数据丢了怎么办？
比如你用了几天 Fun-ASR WebUI 做语音识别，攒了一堆历史记录、调好了热词、配置了 VAD 参数，结果某天重启系统后发现history.db没了——所有努力归零。这种“明明没动它，怎么就没了”的崩溃体验，几乎每个本地用户都经历过。
问题根源其实很清晰：这些关键数据默认存在本地磁盘上，比如/opt/Fun-ASR/webui/data/目录下，而系统本身并不提供自动备份机制。一旦遭遇磁盘故障、误删操作或升级失败，后果就是不可逆的数据丢失。
那有没有办法让系统自己“默默把事做好”？答案是肯定的——只要结合 Linux 的cron 定时任务和一段精巧的Bash 脚本，就能实现每天凌晨自动完成数据打包、归档和清理，全程无需人工干预。
设想一下这样的场景：每天早上你打开电脑前，系统已经悄悄完成了昨晚的数据快照。即使当天出问题，也能轻松恢复到前一天的状态。这不仅是安全感的提升，更是从“玩具级工具”迈向“生产可用系统”的关键一步。
要实现这个目标，核心在于两个技术组件的协同工作：一个是时间调度器 cron，另一个是执行逻辑的 Bash 脚本。
先来看cron——这个自 Unix 时代起就存在的守护进程，至今仍是 Linux 系统中最稳定可靠的定时执行工具。它的原理非常直接：每分钟唤醒一次，检查当前时间是否匹配任何预设任务，如果匹配，就调用 shell 执行对应命令。
我们最关心的是它的五段式时间表达法：
* * * * * command-to-be-executed │ │ │ │ │ │ │ │ │ └── 星期几 (0–6, 0=Sunday) │ │ │ └──── 月份 (1–12) │ │ └────── 日期 (1–31) │ └──────── 小时 (0–23) └────────── 分钟 (0–59)比如想让脚本每天凌晨两点运行，只需要这样一行配置：
0 2 * * * /home/user/funasr_backup.sh >> /home/user/logs/backup.log 2>&1这里有几个细节值得注意：
- 使用绝对路径避免环境变量差异导致命令找不到；
->>追加输出日志，2>&1把错误也一起捕获，方便事后排查；
- 编辑任务用crontab -e，而不是直接修改系统文件，更安全且自动加载。
但光有“闹钟”还不够，还得有个“做事的人”。这就是 Bash 脚本登场的时候了。
下面这段脚本，虽然只有几十行，却完整覆盖了备份的核心流程：
#!/bin/bash # === 配置区 === SOURCE_DIR="/opt/Fun-ASR/webui/data" BACKUP_ROOT="/opt/backups/funasr" DATE=$(date +"%Y%m%d_%H%M") LOG_FILE="$BACKUP_ROOT/backup.log" # 创建备份根目录（若不存在） mkdir -p "$BACKUP_ROOT" # 日志函数 log() { echo "[$(date '+%F %T')] $1" | tee -a "$LOG_FILE" } # 开始备份 log "开始备份 Fun-ASR 数据..." # 检查源目录是否存在 if [ ! -d "$SOURCE_DIR" ]; then log "错误：源目录不存在 $SOURCE_DIR" exit 1 fi # 目标压缩包 TARGET_TAR="$BACKUP_ROOT/funasr_data_$DATE.tar.gz" # 打包并压缩 data 目录 tar -czf "$TARGET_TAR" -C "$(dirname $SOURCE_DIR)" "$(basename $SOURCE_DIR)" 2>>"$LOG_FILE" if [ $? -eq 0 ]; then log "备份成功：$TARGET_TAR" else log "错误：备份失败，请检查磁盘空间或权限" exit 1 fi # 可选：清理7天前的旧备份 find "$BACKUP_ROOT" -name "funasr_data_*.tar.gz" -mtime +7 -exec rm {} \; log "已清理7天前的旧备份文件" exit 0别看代码平实，里面藏着不少工程经验：
- 时间戳命名：用
%Y%m%d_%H%M格式生成文件名，确保每次备份不覆盖，还能直观看出创建时间； - tar 的
-C参数：先切换目录再打包，避免压缩包里出现冗余路径层级； - 日志双写策略：
tee -a同时输出到终端和文件，既能在调试时看到实时反馈，又保留长期记录； - 错误码判断：
$? -eq 0判断上一条命令是否成功，决定后续流程走向； - 自动清理机制：通过
find ... -mtime +7 -exec rm删除超过七天的备份，防止磁盘被撑爆。
这套组合拳下来，整个流程完全闭环：触发 → 准备 → 打包 → 归档 → 清理 → 记录，环环相扣。
而且它不只是为 Fun-ASR 设计的。稍作修改，就能用于 Whisper WebUI、LobeChat 甚至自建 Git 仓库的定期快照。本质上，这是一种通用的轻量级数据保护模式。
不过，在实际部署时还有一些“坑”需要注意。
首先是权限问题。如果你用普通用户启动 WebUI，却用 root 添加了 crontab，脚本很可能因为无权读取data/目录而失败。最佳做法是：谁运行服务，谁设置定时任务。保持用户一致，能省去大量权限调试时间。
其次是存储位置的选择。很多人图方便，把备份也放在系统盘。但如果系统盘坏了呢？建议将BACKUP_ROOT指向独立挂载的存储设备，或者干脆通过rsync同步到另一台机器上。哪怕只是多一层复制，也能显著提高容灾能力。
更进一步的话，还可以加入加密和监控。
例如使用gpg对敏感备份进行加密：
tar -czf - ... | gpg -c > "$TARGET_TAR.gpg"再配合rclone推送到远程对象存储：
rclone copy "$BACKUP_ROOT" remote:backups/funasr --backup-dir="remote:old_backups/$(date +%Y%m)"甚至可以写个简单的监控脚本，每天早上检查日志中是否有“备份成功”字样，如果没有，就发邮件或微信通知你。
这些都是可选项，但它们共同指向一个理念：自动化不是为了偷懒，而是为了让系统更可靠。
回头想想，Fun-ASR 的价值确实在于其强大的语音识别能力，但真正决定它能否被长期使用的，往往是这些“幕后功夫”。就像一辆车，发动机固然重要，但刹车、气囊、胎压监测这些保障性设计，才决定了你敢不敢开上高速。
所以，不要小看这一段小小的备份脚本。它背后体现的是对数据资产的尊重，是对系统稳定性的敬畏，也是一种典型的工程思维落地。
当你不再担心“删库跑路”，才能真正专注于模型调优、识别精度提升这些更有价值的事。
最后提醒一句：写完脚本后别忘了给它加上执行权限：
chmod +x funasr_backup.sh然后手动运行一次，看看能不能正常生成压缩包、写入日志、删除旧文件。确认没问题后再交给 cron。毕竟，能验证的自动化，才算真的自动化。
等到一切就绪，你会发现，那个曾经让你提心吊胆的本地 AI 工具，已经悄悄变得像个成熟的服务了——安静、稳定、值得信赖。
