Linux服务器出现服务异常，重启后恢复正常，准备查看之前的错误日志时，却发现只能看到本次开机后的记录。
这种情况会让故障排查变得困难：程序为什么退出、服务为什么启动失败、重启前出现过什么错误，都可能缺少线索。
本文介绍如何检查systemd journal的保存方式、开启日志持久化，并验证日志是否能够跨重启保留。
1. 为什么Linux重启后日志会消失？
在使用systemd的Linux系统中，systemd-journald负责收集和保存多种系统日志，journalctl用于查询这些记录。
日志能否跨重启保留，与存储位置有关：
| 存储方式 | 常见目录 | 重启后的情况 |
|---|---|---|
| 临时存储 | /run/log/journal | 这部分记录会随重启丢失 |
| 持久化存储 | /var/log/journal | 可以查询仍被保留的历史记录 |
在默认journal命名空间中，Storage=auto会根据/var/log/journal目录是否存在选择存储方式；设置为Storage=persistent后，会优先使用持久化目录。但在早期启动或磁盘不可写时，仍可能暂时使用运行时目录。
开启持久化不能找回已经丢失的日志。 如果之前的记录只保存在临时目录中，并且服务器已经重启，需要从应用日志文件、备份或其他日志平台寻找线索。
2. 操作环境与准备
本文适用于使用systemd的Debian 12、Ubuntu 22.04或Ubuntu 24.04服务器，操作对象是宿主机默认的journal日志服务。
所有命令均在服务器终端执行。使用具有sudo权限的账户操作；如果已经使用root登录，可以去掉命令开头的sudo。
普通Docker容器内部不一定运行systemd，不应直接套用本文步骤。
本教程可在莱卡云Linux云服务器上操作。已有服务器的用户，可以直接检查现有环境。
查看官网购买链接： https://www.lcayun.com
9折优惠码：bloglcayun
3. 先检查有没有历史启动日志
查看当前能够读取到的启动记录：
sudo journalctl --list-boots --no-pager输出中会包含启动编号、Boot ID以及对应日志的起止时间。
在常规本机查询中，0通常对应本次启动，-1对应前一个已保留的启动周期。应结合时间判断它是否就是需要排查的那次开机记录。
如果列表中只有本次启动，并不能立即认定持久化配置有问题。服务器刚创建、旧日志已经被清理等情况，也可能出现相同结果。
接着查看journal配置：
sudo systemd-analyze cat-config systemd/journald.conf这条命令会展示磁盘上的主配置和相关覆盖配置，便于找到设置来自哪个文件。它不是日志服务当前运行状态的证明，修改后仍需加载配置并验证。
重点检查[Journal]部分的Storage=：
volatile：使用临时存储。persistent：优先使用持久化存储。auto：根据持久化目录是否存在选择。none：不保存journal记录。
以#开头的行属于注释。如果多个覆盖文件设置了Storage=，还需要检查后面的配置是否覆盖了前面的值。
4. 开启journal日志持久化
4.1 创建配置文件
先创建配置目录：
sudo mkdir -p /etc/systemd/journald.conf.d下面使用60-persistent.conf保存本次设置。如果同名文件已经存在，先备份：
if sudo test -f /etc/systemd/journald.conf.d/60-persistent.conf; then
sudo cp -a /etc/systemd/journald.conf.d/60-persistent.conf \
"/etc/systemd/journald.conf.d/60-persistent.conf.bak.$(date +%Y%m%d-%H%M%S)"
fi写入配置：
sudo tee /etc/systemd/journald.conf.d/60-persistent.conf > /dev/null <<'EOF'
[Journal]
Storage=persistent
EOF写入后，可以再次执行第3节的cat-config命令，确认文件内容正确，并检查是否存在后续覆盖项。
4.2 准备目录并加载配置
创建持久化目录，再按照系统的tmpfiles规则设置目录属性：
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal如果命令报错，应先处理错误，再继续操作。
重启日志服务并执行刷新：
sudo systemctl restart systemd-journald.service &&
sudo journalctl --flush这里使用完整的restart操作。不要拆成先停止、再启动日志服务的两条命令，以免中断已有服务的日志流连接。
检查日志服务状态：
sudo systemctl is-active systemd-journald.service正常运行时应输出：
active服务处于active状态，只能说明日志服务正在运行。是否真正写入持久化目录，还需要继续验证。
5. 验证日志是否保存成功
5.1 写入测试记录并从磁盘查询
先写入一条带有独立标签的测试日志：
printf '%s\n' 'journal persistence test' |
sudo systemd-cat -t journal-persist-check这里的journal-persist-check是测试标签，方便后续准确查询。systemd-cat可以把输入内容交给journal记录。
随后执行同步：
sudo journalctl --sync再明确从持久化目录读取最近5分钟的测试记录：
sudo journalctl --directory=/var/log/journal \
-t journal-persist-check \
--since "5 minutes ago" \
--no-pager正常情况下，应能找到包含以下内容的日志：
journal persistence test这里指定了/var/log/journal，可以避免仅凭默认查询有输出，就误认为日志已经写入持久化目录。--sync用于等待此前写入的journal数据完成同步。
5.2 在下一次计划内重启后复查
在服务器下一次计划内重启后，重新通过SSH登录，执行：
sudo journalctl --list-boots --no-pager核对启动记录的时间。如果前一个已保留的启动周期对应刚才的测试，再查询：
sudo journalctl -b -1 \
-t journal-persist-check \
--no-pager如果能找到重启前写入的测试内容，说明这条日志已经跨重启保留下来。
刚完成配置、尚未重启时，只有本次启动记录属于可能的正常情况。
从持久化目录查到测试记录，并在计划内重启后再次找到它，才完成了本次保存验证。
6. 如何查看重启前的故障日志？
确认历史日志存在后，就可以按启动周期、服务或日志来源缩小范围。
6.1 查看前一个启动周期的末尾日志
sudo journalctl -b -1 -n 100 --no-pager这里查看的是所选启动周期最后100条记录。故障发生得更早时，应扩大查询范围。
6.2 查看对应启动周期的内核日志
sudo journalctl -k -b -1 -n 100 --no-pager这类记录可以为内存不足、磁盘I/O异常等问题提供线索，但仍需要结合完整上下文判断。
6.3 查看指定服务的历史日志
以通过系统服务运行的Nginx为例：
sudo journalctl -b -1 \
-u nginx.service \
-n 100 \
--no-pagernginx.service需要替换为实际服务名称。
这条命令查询的是该服务进入journal的记录。应用自行写入的访问日志、错误日志或业务日志，还需要到实际文件位置查看。
如果日志显示程序通过systemd启动失败，可以继续参考本站文章：
如果排查的是定时任务，则可以结合：
7. 配置后仍然查不到日志，怎么检查？
可以根据现象确定下一步：
| 现象 | 检查方向 |
|---|---|
| 配置写了persistent，但磁盘目录没有测试记录 | 检查后续覆盖配置、日志服务状态和目录写入错误 |
| 只有本次启动记录 | 确认开启后是否已经重启，以及旧记录是否仍被保留 |
| 系统日志正常，某个应用没有记录 | 检查应用是否把日志写入journal，或者使用独立日志文件 |
| 较新的历史记录存在，更早的记录消失 | 检查日志轮转、容量策略及清理任务 |
查看journal占用和所在磁盘的可用空间：
sudo journalctl --disk-usage
df -h /var/log/journal检查日志服务最近的运行信息：
sudo journalctl -u systemd-journald.service \
-b -n 50 --no-pager重点关注写入失败、空间不足、只读文件系统或配置解析错误。
另外，持久化不等于永久保存。journal仍会受到容量、保留策略和人工清理的影响，例如SystemMaxUse=、MaxRetentionSec=等设置。
需要长期留存的重要日志，应另外安排备份或集中采集。本机磁盘上的日志也无法替代异地备份。
8. 写在最后
处理Linux重启后日志丢失的问题，先确认历史记录是否存在，再检查journal使用的存储方式。
开启持久化后，通过测试记录验证磁盘写入，并在下一次计划内重启后复查，比只检查配置文件更可靠。
平时保留好系统和应用日志，出现故障时就能结合时间、启动周期和服务名称逐步定位原因，让后续排查有据可查。
