Linux：日志轮转、软件维护与备份恢复

维护Linux 维护任务前先保存服务账户、固定状态目录、flock 与 timer，恢复后以任务退出码、journal 和四个日志文件验收。具体配置见配套示例。

前置是完整维护任务。本篇适用 GNU/Linux 与 systemd 249+；核对 2026-10-17。所有命令与脚本未执行，需在目标环境核对权限与影响；以下是读者日后自跑的变更和恢复说明。

配置变更与观察

Linux systemd 变更先记录身份、系统版本、当前单元及其 drop-in，再保存原配置、目标文件和恢复顺序。修改单元后 daemon-reload 重新加载定义；reload 请求应用自己重读配置，两者不能互换。对于本例的 oneshot，没有常驻进程需要热加载环境；EnvironmentFile 会在下一次启动读取。程序/环境文件在服务运行期间不要覆盖，先暂停 timer 并等待或停止当前实例。

# 供日后观察，本轮未执行。
systemctl cat showdocs-maint.service
systemctl show showdocs-maint.service -p Result -p ExecMainStatus -p ActiveState
journalctl -u showdocs-maint.service --since '2026-10-17 00:00:00 UTC' --no-pager
systemctl list-timers showdocs-maint.timer

只读观察也有权限和信息披露边界：日志可包含主机名、路径与用户信息，不直接公开整份输出。用统一时区记录“计划触发、实际开始、结束、退出码”，否则无法判断是否漏跑。修复后再次核对任务产物与结果，不能只看 systemctl 命令本身返回成功。

日志保留与轮转边界

Linux 日志保留在本例按数量而非天数定义：最多 maintenance.log.1、.2、.3 三份归档，当前文件另计。低写入量可能很久不轮转；把三份解释成三天或三次启动都不正确。MAX_BYTES 是下一次开始写入前检查的阈值，单条报告可使当前文件超限，不保证最多占用四倍阈值，也不控制 journal 的空间。

本例不用递归 find、不扫描子目录、不触碰别名或任意 .log 文件，避免“清理受限目录”被扩成整机日志删除。不要再让 logrotate 管理这四个名字，两套轮转会破坏归档顺序和锁约定。长期产品日志应采用发行版维护的 logrotate 或应用内轮转，核对写者重开协议、create 的身份权限与失败处理；没有协议时 copytruncate 仍有丢失窗口。旧 CentOS 样本中给 Nginx 发 USR1 的语义属于 Nginx，不能给任意进程套同一信号。

systemd journal 是另一套存储，可能只保存在 /run，也可能持久保存在 /var/log/journal，依配置而异。应用文件日志、rsyslog 文件和 journal 不是同一份必然重复的数据；需要分别核对保留、访问权限和备份策略，不能删除 journal 文件模拟文件日志轮转。

恢复与备份判断

Linux 恢复顺序是暂停调度、确认无运行实例、保存当前状态、判断故障层、恢复最小必要权限/配置、再验证一次任务。账户 UID 变化时旧文件的数值所有者可能不再对应新账户，不应递归 chown 整个 /var/lib；只核对本任务的固定目录与五个已知文件。

轮转归档与当前日志在同一磁盘，不能抵御磁盘损坏或误删目录。真正备份至少需要独立副本、可解释的保留和读取恢复检查。本例记录的是容量报告，不是数据库备份；tar 成功也不能证明运行中数据库可恢复。持久性、复制和可恢复性应分别判断。

发行版软件包与长期维护

Linux 软件包管理要区分 Debian/Ubuntu 的 dpkg 与 APT、RHEL 系的 RPM 与 DNF：底层包数据库查询、依赖求解、仓库元数据更新是不同动作。文件可能由包管理器安装，也可能是 /usr/local 的手工文件；本例用本地脚本并明确路径，不假装被发行版更新机制维护。

旧文的 CentOS 7、yum、ifcfg、chkconfig 和第三方 RPM URL 保留为历史上下文，不是新主机部署方案。不能为了缺一个 htop 就复制陌生仓库或关闭验证。更新前需核对目标发行版支持、变更说明、配置合并和回退条件，不能从在线“latest”表推断当前兼容性。OpenWrt 的 UCI/procd/QoS 样本仍保留独立平台资料，不并入本例。

完整撤回与精确清理

Linux 清理必须先停止未来触发再停止当前任务，保存需要的日志后删除固定部署文件，最后移除空状态目录与专用账户。以下文本仅在独立教学主机、确认所有文件确属本例且没有其他用途后供读者日后执行。禁止把路径替换成变量或通配符再递归清理。

sudo systemctl disable --now showdocs-maint.timer
sudo systemctl stop showdocs-maint.service
# 清除Persistent时间戳，应在删除timer定义前进行。
sudo systemctl clean --what=state showdocs-maint.timer
# 此处先另行保存需要的日志，再精确列出待删除对象。
sudo ls -la /var/lib/showdocs-maint
sudo rm -- /etc/systemd/system/showdocs-maint.timer /etc/systemd/system/showdocs-maint.service
sudo rm -- /etc/showdocs-maint.env /usr/local/libexec/showdocs-maint.sh
sudo systemctl daemon-reload
sudo rm -f -- /var/lib/showdocs-maint/maintenance.log /var/lib/showdocs-maint/maintenance.log.1 /var/lib/showdocs-maint/maintenance.log.2 /var/lib/showdocs-maint/maintenance.log.3 /var/lib/showdocs-maint/.lock
sudo rmdir -- /var/lib/showdocs-maint
sudo userdel showdocs-maint

rmdir 在存在未知文件时应失败，先调查，不改成 rm -rf。userdel 后同名组是否自动清理由发行版配置决定；确认该组没有任何其他成员/用途后才考虑单独 groupdel。本例不删除共享 /usr/local/libexec、journal 或其他系统日志。锁文件只在所有任务都停止后删除。

练习与参考解答

题目：把 MAX_BYTES 从 1 MiB 调到 10 MiB，能否保证近七天日志可查？禁用 timer 后是否可以立刻删除 .lock？

参考解答：不能，触发由写入量决定且只有三份归档；时间保留需要另行定义策略。disable --now 只停止 timer，已启动的 service 或手动脚本仍可能存在，要确认所有写者停止后才能删锁。保留策略与互斥是两个独立条件。

官方资料

核对 systemd v255 执行环境、systemd timer 状态清理、SUSE 中文计时器说明。中文资料用于交叉核对调度概念，不意味着把 SLES 的系统布局作为 Debian 的安装保证。

归档、同步与备份的不同保证

tar 与 rsync 成功是否证明异地备份可恢复？ tar 将多个成员组织为归档，gzip/bzip2/xz 是压缩格式；.tar 的后缀不能证明内部已压缩。阅读旧例时应先区分创建、列成员、解包，再确认目标目录；-C 改变处理目录，不能让任意归档成员自动安全。追加与删除成员不是任意压缩归档都支持的通用操作，旧 tar/zip 帮助转录和对压缩率、速度的绝对排序撤回。zip -m 会删除源文件，不能混入普通“压缩留副本”的流程。

历史异地备份脚本依次 tar、rsync，成功传输后删除本地包。可吸收的是分别检查归档与传输退出状态、为备份命名、区分源和目标；不能把两个退出码等于零当成可恢复验收。还需要在独立目标读取或恢复、核对内容和权限、明确保留与失败告警。源是运行中的数据库时，应使用该系统支持的一致性备份方式，直接打包目录不足以证明一致。

rsync 的源路径尾部斜线影响复制的是目录还是目录内容，--delete 会删除目标额外项，必须先核对方向和变更清单。传输是否加密取决于所用通道；不是 rsync 的所有模式都自动加密。同盘归档不防磁盘损坏，异地上传也不自动形成备份保留策略。旧脚本的主机地址和业务目录、0777 建目录、删除命令历史、占位 dd/cron/RAID 与运行级别标题均不迁作操作流程；任务调度和资源观察分别由本课程 timer 与诊断篇承接。

缺包、仓库与文件归属

htop 缺包要先 yum update 吗，which 能证明 RPM 归属吗？ No package htop available 只说明当时配置的仓库未找到匹配包，不足以证明需要先升级全系统。EPEL 是额外软件仓库；启用第三方仓库会引入新的来源和更新关系，应先确认发行版、架构、仓库适配、签名和维护责任，不能把历史 yum update 与 EPEL 安装顺序当成通用修复。

RPM 的查询已安装包、检查离线包元数据、列文件、查询文件归属与安装/升级/卸载是不同动作。which 只帮助定位命令，不证明该文件属于哪个包；包数据库查询才能回答受包管理的归属，/usr/local 手工安装的文件可能没有记录。旧文把 which go 命名为“文件属于哪个文件”的解释不再沿用。

历史 lrzsz 的 CentOS 7.7 FTP/HTTP 地址和文件名是环境记录，不是可核验的新安装来源。源码安装的依赖、安装前缀和卸载责任取决于项目，不能把 make install 统一解释为固定 /usr/local 布局，更不能照抄 /uer/local 拼写。原篇的 yum、函数库和 Nginx 源码安装空标题撤回，不推定存在完整流程；Nginx 安装边界见其当前课程。旧 htop 文中的开启 root 登录外链与终端软件名称不作为安装要求或当前推荐。

日志记录、存储与轮转的证据口径

登录记录与应用日志有何区别，rotate 52 是否一定保存52天？ lastlog、last reboot、who 和 users 分别观察账户最近登录、历史重启或当前会话，不能互相替代，也不保证某种身份的全部访问都被记录。应用请求量、错误码与延迟需要对应应用日志字段和时间窗口，不能从会话列表推定容量或活跃用户数。保存系统审计证据时避免公开真实用户名、地址和完整日志。

rsyslog 路由规则、journal 存储和应用文件日志需分别确认。旧 /var/log/message、secure、maillog、cron 等路径只是来源平台的记录，不能据路径不存在认定系统没有日志；先查实际服务和配置生成者。空白“利用系统日志定位问题”和跳到“7用户和组”的章节没有实验内容，明确撤回，不声称已经完成排错练习。

logrotate 中 daily 是调度条件，rotate 52 是保留份数；是否每天产生一份还受实际调用、空文件和错误等影响。create 决定新文件的身份模式，compress/delaycompress 影响压缩时机。重命名日志不会让写者自动切换描述符，旧 Nginx 样本的 USR1 只适用于约定该信号的程序，不能套给所有进程。sharedscripts/postrotate 也不是多写者事务。轮转与备份、审计留存分别设计，不按旧整段配置复制用户名、PID路径或保留天数。