Bluecherry 常用命令与运维实战（核心篇）

目标：给出 Bluecherry 3.1.14 生产运维的命令手册与实战案例——服务管理、流与设备运维、录像/事件查询、存储治理、备份恢复、监控告警、用户安全，并把实测过程中踩到的真实故障（RTSP 认证、孤儿索引、备份静默跳过等）沉淀为可复用的排障手册。全部命令与输出均来自本机实测环境。

一、环境信息

项目	内容
操作系统	Ubuntu 22.04.5 LTS（隔离环境模拟裸机，行为与物理机一致）
软件版本	Bluecherry 3.1.14（包版本 `3:3.1.14`），nginx 1.18.0 / PHP 7.4.33 / MySQL 8.0.43
实测设备	两路 ffmpeg 合成 RTSP 流：LabCam（持续录像，设备ID 1）、MotionCam（移动侦测，设备ID 2）
实测日期	2026-10-28
配套阅读	《Bluecherry .deb 裸机部署实战》（安装）、《Bluecherry 配置参数详解》（参数）

二、前置条件

已完成安装且 systemctl is-active bluecherry nginx php7.4-fpm mysql 全部 active；
Web 示例账号 Admin/q1w2e3r4（登录入口 https://<服务器IP>:7001）；
有 MySQL 命令行权限（运维脚本统一从 /etc/bluecherry.conf 解析凭据，见 7.2）；
ffmpeg/ffprobe 可用（流验证用，apt-get install -y ffmpeg）。

三、服务与进程管理

3.1 四服务架构与启停

服务	单元	职责	常用操作
bluecherry	bluecherry.service	bc-server 录像核心（RTSP 拉流/录像/转发）	`systemctl restart bluecherry`（改计划/接口配置后）
nginx	nginx.service	Web 界面 HTTPS 7001	`systemctl reload nginx`（改站点/证书后）
php7.4-fpm	php7.4-fpm.service	Web 界面 PHP 执行	基本免维护
mysql	mysql.service	元数据库	数据库维护窗口重启

实操速查（实测）：

systemctl is-active bluecherry nginx php7.4-fpm   # 状态一览 → active×4
systemctl restart bluecherry                      # 重启录像核心（Web 不断）
journalctl -u bluecherry -f                       # 跟踪录像核心日志
tail -f /var/log/bluecherry.log                   # 同上，文件视图
ss -ltnp | grep -E "7001|7002|3306"               # 端口核验（nginx/bc-server/mysqld）

端口监听实测回显：

LISTEN 0 511  0.0.0.0:7001  users:(("nginx",...))
LISTEN 0 10         *:7002  users:(("MAIN",...))
LISTEN 0 151        *:3306  users:(("mysqld",...))

3.2 日志分级与读法

bc-server 日志行格式：级别(设备ID/设备名): 消息，级别 I（info）/W（warn）/E（error）：

I(1/LabCam): Stream started: h264, 1/90000(s) 1/90000(c); aac   ← 拉流成功
I(1/LabCam): Device 1: Starting schedule transition to 'continuous' ← 计划切换
W(1/LabCam): Likely timestamping error. Ignoring.               ← 时间戳警告（合成流/个别摄像头常见，自动忽略）
I(): Storage path /var/lib/bluecherry/recordings below threshold: 41.3% <= 95.0% ← 存储自检（每5分钟）

常用过滤：

journalctl -u bluecherry --since "1 hour ago" | grep -cE "^E"        # 近1小时错误数
journalctl -u bluecherry --since "1 hour ago" | grep "Motion event"  # 侦测触发流水
journalctl -u bluecherry --since "1 hour ago" | grep -iE "signal|disconnect"  # 掉线记录

3.3 资源占用基线（实测，2 路测试流）

● bluecherry.service    Memory: 224.7M
● nginx.service         Memory: 8.3M
● php7.4-fpm.service    Memory: 14.8M
● mysql.service         Memory: 395.1M

基线解读：bc-server 约 225MB（随路数增长）、MySQL 缓冲池为主约 395MB——2 路起的小型部署 2GB 内存即可跑，生产按路数线性外推并预留突发。

四、摄像头与流运维

4.1 设备清单与状态

# 设备清单（含计划/启停状态）
mysql -u root -p bluecherry -e \
 "select id,device_name,protocol,device,disabled,substr(schedule,1,3) as plan3,schedule_override_global from Devices;" 2>/dev/null

实测回显：

id  device_name  protocol  device            disabled  plan3  schedule_override_global
1   LabCam       IP-RTSP   127.0.0.1|8554|/cam1   0     CCC    0
2   MotionCam    IP-RTSP   127.0.0.1|8554|/cam2   0     MMM    1

# 临时停用/启用某路（bc-server 5 秒内停止/恢复该路拉流）
mysql -u root -p bluecherry -e "update Devices set disabled=1 where id=2;"   # 停用
mysql -u root -p bluecherry -e "update Devices set disabled=0 where id=2;"   # 启用

4.2 各类流地址与验证命令（核心速查）

用途	地址/命令
摄像头原始流（源）	`rtsp://<摄像头用户>:<密码>@<摄像头IP>:554/<路径>`
Bluecherry 转发流（客户端观看）	`rtsp://<Web账号>:<Web密码>@<服务器IP>:7002/live/<设备ID>`（必须带认证，实测不带凭据 ffprobe 直接 401 无输出）
Web 实时预览	浏览器 `https://<服务器IP>:7001`（HLS，由 `G_LIVEVIEW_VIDEO_METHOD` 控制）
流健康验证	`timeout 8 ffprobe -v error -show_entries stream=codec_name,width,height -of csv=p=0 <流地址>`

转发流验证实测（设备ID=1，账号 Admin）：

timeout 8 ffprobe -v error -show_entries stream=codec_name,width,height \
  -of csv=p=0 rtsp://Admin:q1w2e3r4@127.0.0.1:7002/live/1

实测回显：

h264,640,480
aac

💡 技术拓展：7002 转发流的本质是 bc-server 把摄像头流重新分发——多个客户端都从 bc-server 取流而不是直连摄像头，既解决摄像头并发连接数限制（消费级摄像头常限 3~5 个 RTSP 客户端），也统一了认证出口。客户端认证用 Web 账号（Users 表），可按用户控制可见设备。

4.3 拉流故障诊断三板斧

按顺序执行（实测有效的排查路径）：

# 1. 源流通不通（绕过 bc-server 直连摄像头）
timeout 8 ffprobe -v error -show_entries stream=codec_name -of csv=p=0 rtsp://user:pass@摄像头IP:554/路径

# 2. bc-server 有没有在拉（设备级日志）
journalctl -u bluecherry --since "10 min ago" | grep "1/LabCam" | tail -5

# 3. 摄像头侧网络（端口连通性）
nc -zvw3 <摄像头IP> 554

实测判读：第 1 步失败→摄像头/网络问题；第 1 步成功但日志无 Stream started→核对 Devices 表 device 串（主机|端口|路径）与 rtsp_user/pass；日志 401→摄像头认证错；UDP 黑屏→rtsp_rtp_prefer_tcp=1 改 TCP（见排障实录 10.1）。

五、录像与事件运维

5.1 事件查询（EventsCam 表）

# 最近 10 条事件（motion/continuous）
mysql -u root -p bluecherry -e \
 "select id,device_id,type_id,from_unixtime(time) as t,length,level_id,media_id
  from EventsCam order by id desc limit 10;" 2>/dev/null

实测回显（节选）：

id  device_id  type_id     t                    length  level_id  media_id
5   2          motion      2026-10-28 09:44:36  2       2         9
4   2          motion      2026-10-28 09:44:24  2       2         9
...
2   1          continuous  2026-10-28 09:26:21  0       2         6

# 按设备+类型+时间窗统计（周报素材）
mysql -u root -p bluecherry -e \
 "select device_id,type_id,date(from_unixtime(time)) as d,count(*) as cnt
  from EventsCam where time > unix_timestamp(now()) - 86400
  group by device_id,type_id,d;" 2>/dev/null

5.2 媒体索引与录像文件定位（Media 表）

# 按时间找录像文件（回放取证常用）
mysql -u root -p bluecherry -e \
 "select id,device_id,filepath,from_unixtime(start) as s,from_unixtime(end) as e,size,archive
  from Media where start between unix_timestamp('2026-10-28 09:00:00')
  and unix_timestamp('2026-10-28 10:00:00') order by id;" 2>/dev/null

实测回显（节选）：

id  device_id  filepath                                                        s                    e                    size     archive
6   1          /var/lib/bluecherry/recordings/2026/10/28/000001/09-26-21.mp4  2026-10-28 09:26:21  2026-10-28 09:40:28  0        1
8   1          /var/lib/bluecherry/recordings/2026/10/28/000001/09-41-30.mp4  2026-10-28 09:41:30  1970-01-01 00:00:00  NULL     0

字段读法：end=1970-01-01/size=NULL 表示正在写入的活动段（收尾后补全）；文件名带 -motion 后缀即移动侦测段（与持续段同目录并存）。

# 取证：直接把 mp4 拷走（缩略图同名 .jpg）
scp root@<服务器>:/var/lib/bluecherry/recordings/2026/10/28/000001/09-26-21.mp4 ./

5.3 事件归档（防清理）

# 把某段录像标记为归档（存储清理会跳过归档段）
mysql -u root -p bluecherry -e "update Media set archive=1 where id=6;" 2>/dev/null
mysql -u root -p bluecherry -e "select id,archive,filepath from Media where archive=1;" 2>/dev/null

实测回显：

id  archive  filepath
6   1        /var/lib/bluecherry/recordings/2026/10/28/000001/09-26-21.mp4

Web 后台的 Archive 按钮即写此标志；重要证据录像先归档再做存储治理。

六、存储管理

6.1 水位机制与多路径

mysql -u root -p bluecherry -e "select id,path,max_thresh,min_thresh,priority,free_space from Storage;" 2>/dev/null

实测回显：

id  path                             max_thresh  min_thresh  priority  free_space
1   /var/lib/bluecherry/recordings   95          90          1         133704138752

机制（实测日志佐证）：bc-server 每 5 分钟自检，使用率 ≥ max_thresh（95%）自动清理到 min_thresh（90%），从旧到新、跳过 archive=1。多盘扩展：Storage 表按 priority 加行（如 /mnt/disk2/recordings priority=2），写满优先级 1 再写 2。

容量速算（本机实测口径）：640×480@15fps 测试流 H.264 约 1.4 Mbps → 单路全天约 14GB；1080p 主码流典型 4~~6 Mbps → 单路全天 43~~65GB。规划公式：磁盘 ≈ 码率 × 路数 × 天数 ÷ 8 × 86400。

6.2 未跟踪文件清理（官方脚本）

场景：手工拷入/残留的 .mkv/.jpg 不在 Media 索引里（"untracked"）。官方脚本 remove_untracked_media_files.sh 比对 DB 与文件系统清单（实测脚本逻辑：只处理 .mkv 与 .jpg，.jpg 仅当同名 .mkv 也不在库时才列删除）：

systemctl stop bluecherry                      # ① 脚本要求 bc-server 已停（实测有 WARNING 提示）
bash /usr/share/bluecherry/remove_untracked_media_files.sh    # ② 生成比对清单
ls /tmp/bluecherry_cleanup.*                   # ③ 核对清单（.rm.list 待删/.ok.list 保留）
rm $(cat /tmp/bluecherry_cleanup.rm.list 2>/dev/null)         # ④ 确认后执行
systemctl start bluecherry                     # ⑤ 恢复服务

实测运行回显（节选）：

WARNING! bc-server is running. It must be stopped for stable result of this script
Dumping DB list from Media table

⚠️ 该脚本不处理反向孤儿（文件被删但 Media 行还在），见 6.3。

6.3 反向孤儿（索引行存在、文件丢失）清理

实测场景：手工 rm 了一个录像文件，Media 行残留（人肉删除文件是错误操作，但要有兜底手段）：

# ① 导出全部索引路径并筛出文件已丢失的行
mysql -u root -p bluecherry -N -e "select filepath from Media;" 2>/dev/null \
 | while read f; do [ -f "$f" ] || echo "$f"; done > /tmp/orphan_rows.txt
cat /tmp/orphan_rows.txt    # 人工确认（本实测恰为被删的 09-40-28.mp4）

# ② 确认无误后清理索引行（先备份，见第七章）
mysqldump --single-transaction -u root -p bluecherry Media > /root/media_pre_clean.sql
while read f; do
  mysql -u root -p bluecherry -e "delete from Media where filepath='$f';" 2>/dev/null
done < /tmp/orphan_rows.txt

# ③ 验证归零
mysql -u root -p bluecherry -N -e "select filepath from Media;" 2>/dev/null \
 | while read f; do [ -f "$f" ] || echo "$f"; done | wc -l    # → 0（实测）

实测：删除孤儿行前 orphan=1，清理后归零，bc-server 与 Web 回放均无异常。

6.4 录像目录占用速查

du -sh /var/lib/bluecherry/recordings                     # 总占用
du -sh /var/lib/bluecherry/recordings/*/*/*               # 按天分布（定位暴涨日）
ls /var/lib/bluecherry/recordings/2026/10/28/000001/ | wc -l   # 单设备当日文件数
find /var/lib/bluecherry/recordings -name "*.mp4" -size +1G -ls   # 异常大文件

七、备份与恢复

7.1 备份对象与组合

对象	路径	方式
元数据（24 张表：设备/用户/事件/索引/配置）	MySQL `bluecherry` 库	mysqldump（官方脚本或手动）
录像文件	`/var/lib/bluecherry/recordings/`	rsync/快照，与 DB 备份同时间窗（索引与文件必须配对）
服务端配置	`/etc/bluecherry.conf` + nginx 站点	文件备份
监控历史	`/var/lib/bluecherry/monitor.rrd`	可选（丢失只影响历史图表）

7.2 官方数据库备份脚本（backup_db.sh）

脚本机制（实测源码）：从 /usr/share/bluecherry/load_db_creds.sh 解析 /etc/bluecherry.conf 拿数据库凭据 → 检查 G_CRON_BKP_ENABLED 是否为 yes（否则静默退出！） → 输出到 <最高优先级Storage路径>/db_backup.sql.gz（本机即 /var/lib/bluecherry/recordings/db_backup.sql.gz）→ 可选 G_CRON_BKP_PARAMS 附加 mysqldump 参数。

启用并实测：

# ① 启用开关（默认表中无此参数——不启用则脚本静默跳过，真实坑！）
mysql -u root -p bluecherry -e \
 "insert into GlobalSettings(parameter,value) values ('G_CRON_BKP_ENABLED','yes');" 2>/dev/null
# ② 追加参数避免 MySQL 8.0 PROCESS 权限告警（见排障实录 10.5）
mysql -u root -p bluecherry -e \
 "insert into GlobalSettings(parameter,value) values ('G_CRON_BKP_PARAMS','--no-tablespaces');" 2>/dev/null
# ③ 执行
bash /usr/share/bluecherry/backup_db.sh
ls -la /var/lib/bluecherry/recordings/db_backup.sql.gz

实测回显：

-rw-r--r-- 1 root root 4934 Oct 28 09:47 /var/lib/bluecherry/recordings/db_backup.sql.gz

生产建议：改用 G_CRON_BKP_PARAMS 排除大表（如 --ignore-table=bluecherry.EventLog），并把输出路径指向非录像盘。

7.3 手动备份（立即可用）

# 方式一：借用官方凭据加载器（凭据不出现在命令行）
. /usr/share/bluecherry/load_db_creds.sh
mysqldump --single-transaction --no-tablespaces -h"${host:-localhost}" \
  bluecherry -u"$user" -p"$password" 2>/dev/null | gzip > /root/bluecherry-db-$(date +%F).sql.gz

# 方式二：录像目录增量同步（异机）
rsync -a --delete /var/lib/bluecherry/recordings/ backup@<备份机>:/srv/nvr/recordings/

# 方式三：全栈一键（配置 + 库 + 索引一致性说明）
tar czf /root/bc-conf-$(date +%F).tgz /etc/bluecherry.conf /etc/nginx/sites-enabled/bluecherry.conf

7.4 恢复流程（实录级步骤）

# ① 停录像核心（防止恢复期间写入）
systemctl stop bluecherry
# ② 恢复数据库
gunzip < bluecherry-db-2026-10-28.sql.gz | mysql -u root -p bluecherry
# ③ 恢复录像目录（与库同代快照）
rsync -a /backup/recordings/ /var/lib/bluecherry/recordings/
# ④ 索引一致性兜底：按 6.2/6.3 清两侧孤儿
# ⑤ 恢复配置并启动
tar xzf bc-conf-*.tgz -C /
systemctl start bluecherry
journalctl -u bluecherry --since "1 min ago" | grep -E "Stream started"   # 逐路确认拉流恢复

⚠️ 元数据与录像文件是配对关系：只恢复库不恢复文件（或反之）都会产生孤儿，必须用同一时间点的组合，再用 6.2/6.3 双向兜底。

八、监控与健康检查

8.1 健康检查接口（机器可读）

前提：/etc/bluecherry.conf 配置 access_token（配置方法与 401 实测见《Bluecherry 配置参数详解》8.3）。

curl -sk -H "Authorization: Bearer bluecherry-health-token" https://127.0.0.1:7001/ajax/health.php/ping

实测回显：

{
    "status": 200,
    "message": "Service is healthy"
}

8.2 系统统计接口（JSON）

curl -sk -H "Authorization: Bearer bluecherry-health-token" https://127.0.0.1:7001/ajax/stats.php | head -c 600

实测回显（节选）：

{"cpuUsage":17.47,"ram":{"total":20840210432,"free":17362542592},
"disks":[{"fs":"/dev/mapper/vgubuntu-root","type":"ext4","total":199826395136,"free":117282775040}],
"devices":[{"id":1,"stream":"STREAM_ONLINE","state":"STREAM_ONLINE",...}]}

字段读法：cpuUsage（%）/ram（字节）/disks（含录像盘剩余）/devices[].stream（STREAM_ONLINE=拉流正常）——外接 Prometheus/node_exporter 类体系的兜底检查项。Web 后台的实时图表由 rrdtool 生成（/var/lib/bluecherry/monitor.rrd）。

# 当前在线用户会话（安全审计）
mysql -u root -p bluecherry -e "select ip,from_unixtime(time) as last_seen from ActiveUsers;" 2>/dev/null

九、用户与安全运维

9.1 用户与权限速查

mysql -u root -p bluecherry -e "select id,username,permission_mask,debug_level from Users;" 2>/dev/null

权限位 permission_mask 按位控制（Web 访问/设备列表/PTZ/计划/备份等），生产给值班账号只开 Web+设备权限；
Web 后台 → Users 界面增删改即可，SQL 仅用于审计。

9.2 忘记 Admin 密码的恢复（SQL 实测可用）

密码存储格式：md5(明文密码 + salt)（salt 存于 Users.salt，本实测通过 md5 复算精确匹配验证了该公式）：

# 思路：重置为已知值。生成新盐，写入 md5(新密码+盐)
NEWSALT=$(tr -dc A-Za-z0-9 </dev/urandom | head -c 8)
NEWPWD='q1w2e3r4'
HASH=$(php -r "echo md5('${NEWPWD}${NEWSALT}');")
mysql -u root -p bluecherry -e \
 "update Users set salt='${NEWSALT}', password='${HASH}' where username='Admin';" 2>/dev/null

随后用 Admin/q1w2e3r4 登录。⭐ 完成后立即在 Web 后台改掉（避免 shell 历史残留）。

9.3 安全基线清单（部署后逐项核对）

改默认密码（Admin/bluecherry → 强口令）；
MySQL bluecherry 账号改强口令（/etc/bluecherry.conf 同步改）；
7001/7002 不暴露公网（防火墙只放内网/VPN 网段）；远程访问走反代 + 正式证书；
G_ENABLE_TELNET=0、G_DISABLE_DEBUG_OUTPUT=1；
开启信号丢失通知（signal_loss_notification=1）与 SMTP；
定期核对 ActiveUsers 会话与 Users 表。

十、排障实录（核心沉淀）

以下 7 案例全部为本机实测过程中真实发生/复现的故障，按"现象 → 定位 → 修复"整理。

10.1 RTSP 转发流 401（"有地址但拉不到流"）

现象：ffprobe rtsp://<IP>:7002/live/1 长时间无输出、超时退出，Web 端预览正常。
定位：7002 流要求 Web 账号认证，匿名请求被拒（ffprobe -v error 下 401 表现为无流输出而非显式报错——易误判为网络问题）。
修复：URL 中带凭据 rtsp://Admin:<密码>@<IP>:7002/live/1，实测立即出流（h264,640,480 / aac）。
教训：RTSP 侧"超时无输出"先试认证，再查网络；ffprobe 加 -v error 时 401 不显式提示。

10.2 改录像计划不生效（schedule_override_global）

现象：SQL 把设备计划改为全 M，日志无任何 schedule transition，仍在持续录像。
定位：Devices.schedule_override_global=0 时逐设备计划被全局 G_DEV_SCED 覆盖（详见《Bluecherry 配置参数详解》6.2）。
修复：update Devices set schedule_override_global=1 where id=2; systemctl restart bluecherry，日志出现 Schedule transition to 'motion' 即生效。
教训：逐设备计划有两道开关（覆盖位 + 计划串），且计划引擎在重启时重估。

10.3 数据库文件不同步（反向孤儿索引）

现象：手工删除一个 mp4 后，Web 事件列表仍指向该文件，回放报错。
定位：select filepath from Media 逐行 [ -f ] 检查，确认行存文件失（实测 /tmp/bluecherry_cleanup.db.list.raw 与实际目录比对）。
修复：按 6.3 流程备份 Media 表后删除孤儿行，复检归零；bc-server 无需重启。
教训：录像文件只能通过归档/水位机制让系统自己删；人肉 rm 后必须做索引兜底。

10.4 官方备份脚本静默跳过

现象：bash /usr/share/bluecherry/backup_db.sh 无输出无报错，备份文件不存在。
定位：读脚本源码——G_CRON_BKP_ENABLED 不是 yes 时直接 exit，而全新安装的 GlobalSettings 表没有这个参数（默认值缺失）。
修复：insert 参数为 yes 后再跑，实测生成 db_backup.sql.gz（4934 字节）。
教训："脚本无输出"≠"执行成功"，静默退出分支要看源码；备份有效性要用 ls -la + 定期恢复演练验证。

10.5 备份报 PROCESS 权限错误

现象：backup_db.sh 输出 mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump tablespaces，但 gzip 文件仍生成。
定位：MySQL 8.0.21+ 的 mysqldump 默认 dump tablespaces，需 PROCESS 特权；bluecherry 业务账号无此特权（非致命，表数据完整）。
修复：追加 --no-tablespaces（本例配到 G_CRON_BKP_PARAMS 参数里）或给账号授权 GRANT PROCESS ON *.*。
教训：mysqldump 8.0 的告警要区分致命/非致命，判断依据是退出码与产物完整性。

10.6 清理脚本与 bc-server 并发

现象：运行 remove_untracked_media_files.sh 时输出 WARNING! bc-server is running. It must be stopped for stable result of this script。
定位：脚本生成 DB/文件系统两份清单做比对，bc-server 同时在写新段会造成清单快照不一致。
修复：维护窗口 systemctl stop bluecherry → 跑脚本 → start。脚本比对的口径是 .mkv/.jpg 未跟踪文件，.mp4 段不受影响。
教训：任何"全量扫描比对"类维护都要先停写入方。

10.7 无核显环境 VAAPI 告警

现象：日志持续 Failed to open VAAPI device /dev/dri/card0 ... falling back to software decoding。
定位：G_VAAPI_DEVICE 默认指向 /dev/dri/card0，纯 CPU 服务器无此设备；bc-server 自动回退软解，录像功能完全正常。
修复：无需处理；有 Intel 核显的机器确认 /dev/dri/card0 存在即可享受硬解降 CPU。
教训：硬件加速日志分级判断——有 fallback 行为的告警优先确认业务结果。

十一、常见问题（FAQ）

Q1：7001 打不开？ 顺序查：systemctl is-active nginx（Web 前端）→ ss -ltnp | grep 7001（监听）→ 防火墙（ufw status）→ 记得用 https（http 会 400）。

Q2：某路摄像头掉了如何快速恢复？ 三板斧（4.3 节）：直连摄像头 ffprobe → 设备日志 grep "ID/名称" → nc -zvw3 IP 554。多数是摄像头侧重启/网络抖动，bc-server 会自动重连（Stream started 重新出现即恢复）。

Q3：如何把某段录像导出给警方/客户？ 直接按 5.2 定位 mp4 + 同名 jpg 拷出（通用 MP4 容器，任何播放器可放）；也可 Web 后台事件页 Export（支持片段裁剪）。

Q4：事件/录像太多想批量归档？ update Media set archive=1 where device_id=N and start < unix_timestamp('2026-06-01');（先 select 确认范围）。归档段不参与水位清理，注意长期归档要自己另存。

Q5：怎么只重启 Web 不动录像？ systemctl restart nginx php7.4-fpm——bc-server 不受影响，录像连续。

Q6：磁盘快满了应急怎么做？ 短期：降 G_MAX_RECORD_TIME（小文件更早轮转释放句柄）+ update Media set archive=0 where archive=1 and …（取消非必要归档）+ Storage 阈值调低触发自动清理；中期：加存储路径（Storage 加行）或缩保留天数。

Q7：日志文件会不会无限涨？ /var/log/bluecherry.log 走系统 logrotate；G_DISABLE_ALL_LOGS=0 保持，排障期可临时 debug_level=3 逐设备开 debug（记得改回 2）。

Q8：升级版本的正确姿势？ apt update && apt install --only-upgrade bluecherry → 升级前先跑 7.3 手动备份 → 升级后 journalctl -u bluecherry 确认逐路 Stream started；数据库 schema 由包自动迁移（3.1.14 公告确认兼容保留既有配置与录像）。

十二、参考链接

服务端源码仓库（脚本与日志实现）：https://github.com/bluecherrydvr/bluecherry-apps
服务端 3.1.14 发布公告（DB 同步/监控改进背景）：https://forums.bluecherrydvr.com/t/server-release-3-1-14/1050
官方论坛运维讨论区：https://forums.bluecherrydvr.com
站内配套：《Bluecherry 介绍与选型指南》、《Bluecherry .deb 裸机部署实战》、《Bluecherry 配置参数详解》