最近重新检查备份目录，发现“文件每天都在生成”很容易带来一种虚假的安心。备份真正有价值的条件，是能在需要时找到、读取并恢复。
我把检查分成四件事：来源是否完整、文件是否可读、保留周期是否合理、恢复步骤是否实际跑过。数据库最好使用应用支持的导出或一致性快照；只复制正在写入的数据目录，可能得到结构完整但事务不一致的副本。
sha256sum backup-file
tar -tf archive.tar | head
gzip -t database.sql.gz校验和能发现传输或存储损坏，但不能证明内容正确。因此还需要定期把备份恢复到隔离目录或测试实例，确认权限、字符集、依赖版本和启动步骤。
备份也不应一直在线挂载在原机器上。误操作、入侵或磁盘故障可能同时影响源数据和本地备份。至少保留一份不同介质或不同权限域的副本，并限制备份账户只能写入必要位置。
今天补上的不是更多复制命令，而是一份简短恢复记录：备份在哪里、需要哪些密钥、恢复顺序是什么、最后一次成功演练是什么时候。能回答这些问题，备份才算真正完成。
今天整理小站时顺手检查了证书续期。浏览器显示“安全”并不代表续期链路一定正常；真正容易出问题的是几个月前配置过、后来又改动的验证路径和服务重载。
先看证书本身的有效期：
openssl x509 -in fullchain.pem -noout -subject -issuer -dates然后确认自动任务确实存在，而不是只记得“以前启用过”：
systemctl status certbot.timer
systemctl list-timers certbot.timer这次最有价值的步骤仍然是模拟续期：
certbot renew --dry-run模拟成功后，还要关注部署钩子。如果前端服务读取的是证书副本或合并后的 PEM，仅更新 Let’s Encrypt 目录并不会让正在运行的进程自动加载新证书。部署钩子应先生成目标文件、验证配置，再 reload 服务。
最后从外部访问一次 HTTPS，核对域名、证书链和页面响应。证书管理看起来是低频工作，但越是低频，越应该把步骤写成清单和自动化检查，避免到期当天才重新回忆整条链路。