结论
根因已经查清了：这次应用中心异常的直接触发点不是 /vol1、/vol2 主存储损坏，也不是你手动卸载的 /vol3，而是系统分区 / 被写满，导致 PostgreSQL 在做 checkpoint 时崩溃。
你贴出的 PostgreSQL 原始日志里，最关键的报错是这两组：
2026-04-19 21:11:48
PANIC: could not write to file "pg_logical/replorigin_checkpoint.tmp": No space left on device
自动恢复后马上又在结束恢复的 checkpoint 再次报：
PANIC: could not write to file "pg_logical/replorigin_checkpoint.tmp": No space left on device
这说明数据库不是先坏了再没空间，而是先遇到磁盘无可用空间，checkpointer 直接崩掉，随后实例反复进入恢复态。应用中心日志从 21:11:49 开始持续出现 database system is in recovery mode，正好和这个时间点严丝合缝对上。
怎么理解这次故障
现在可以把故障链写成一条很清楚的因果链：
4 月 19 日晚，系统分区 / 写满。
PostgreSQL checkpoint 时要写 pg_logical/replorigin_checkpoint.tmp，结果报 No space left on device。
checkpointer 进程 PANIC，数据库实例被迫终止并重启恢复。
恢复日志里的 redo starts at、redo done at 说明 WAL 重放本身走到了尾部。
但恢复结束时还要再做一次 checkpoint，又因为空间不足再次 PANIC。
所以 PostgreSQL 一直卡在 recovery 或 failed，最终到 4 月 21 日 10:30 左右，5432 的本地 socket 根本没创建出来。
依赖数据库的应用中心、trim_sac、accountsrv、ai_manager、share_service 等一起报错，看起来就像“应用全没了”。
这里还有一个容易误判的点：
日志里的 invalid record length at 0/869EE48: wanted 24, got 0，在这段上下文里不是主因，更像 WAL 到末尾时的正常结束提示。真正致命的是后面的 No space left on device。
另外，你贴出来那条 postgres@appcenter FATAL 后面接着 root@mikoshi...，这是终端粘贴把日志输出打断了，不是 PostgreSQL 本身的完整报错正文。
当前状态
我刚才在终端里补查过：
/ 挂载在 /dev/nvme1n1p2。
当前仍然是 63G 总量、61G 已用、可用 0、使用率 100%。
inode 使用率只有 38%，所以不是 inode 耗尽，而是块空间真的满了。
PostgreSQL 数据目录还在，这对恢复是好消息。
从目前证据看，这更像“空间耗尽导致数据库起不来”，而不是“数据库文件已经明显损坏到必须先做 pg_resetwal”。
接下来该怎么做
现在最重要的不是修数据库，而是先把系统分区 / 腾出空间。只要能先释放出几 GB，可恢复的概率很高。
在你当前的 root shell 里，先只做只读定位，不做删除：
看根分区大户：
du -xhd1 /var/lib /var/log /usr /root 2>/dev/null | sort -h
继续细看 /var/lib 里面谁最大：
du -xhd1 /var/lib/* 2>/dev/null | sort -h | tail -n 50
查有没有“已删除但仍被进程占着”的大文件：
lsof +L1 | sort -k7 -n | tail -n 50
查系统分区里的超大文件：
find / -xdev -type f -size +500M -printf '%s %p\n' 2>/dev/null | sort -n | tail -n 100
我建议先别做这些操作：
不要执行 pg_resetwal
不要重建 PostgreSQL cluster
不要删除 PostgreSQL 数据目录
不要先重启数据库碰运气
后续你只要把上面几条只读结果贴出来，我就能继续帮你判断：
该清哪一类文件最安全
先释放多少空间最稳妥
释放空间后是不是只需要启动 postgresql@15-main 就有机会恢复
