先把当时的情况摆出来。Grafana 9.5 用内置 SQLite 存配置，某天开始所有面板打开都报 500，日志里是 database disk image is malformed，重启也没恢复。
把日志和配置对完，能解释这个现象的基本就这几处。服务器异常掉电，SQLite 的 WAL 文件没写完，主库损坏。另一种情况是Grafana 进程还在写的时候直接拷贝了数据库文件做备份。
不容易想到的是，磁盘写满过，数据库文件尾部被截断。还有一种情况，两个 Grafana 实例共用同一个 SQLite 文件。
先停服务并把数据库文件备份出来
systemctl stop grafana-server && cp /var/lib/grafana/grafana.db /root/grafana.db.bak做一次完整性检查
sqlite3 /var/lib/grafana/grafana.db 'pragma integrity_check;'能修就修，修不动就导出再导入
sqlite3 /var/lib/grafana/grafana.db '.dump' > g.sql && sqlite3 new.db < g.sql等前面都确认过，再换回新库并重启验证
chown grafana:grafana new.db && systemctl start grafana-server怎么算真的好了，看的是同一批现象。Grafana 登录正常，面板能打开并出图，日志里不再出现 malformed 记录，integrity_check 返回 ok。
容易忽略的是，多实例部署就别用 SQLite，换成 MySQL 或 Postgres；备份要在停服务或者用 sqlite3 .backup 的方式做，直接 cp 很容易拷到半写状态。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。