那些「当时觉得没必要、事后追悔莫及」的运维习惯
个人站长和正规运维团队最大的区别，不是技术能力，而是没有人在背后兜底。大公司里删库跑路还有备份团队、还有 DBA 复盘；个人站主一个人扛服务器、代码、SEO、内容，任何一次事故都是自己买单。
我运营个人站这些年，踩过的坑里，真正致命的从来不是「技术难题」，而是那些「当时觉得没必要做、能做但懒得做」的小习惯。它们平时毫无存在感，只在出事那一刻集中爆雷。这篇不讲具体命令，讲那些没人告诉过你、但每条都值几千块工资的教训。
一、备份不是「有备份」，而是「验证过能恢复」
「我有备份」是运维里最危险的七个字。我见过（也经历过）的典型场景：
- 定时任务跑了半年，但脚本里的路径写错了，备份文件一直是 0 字节。
- 备份只备了数据库，没备上传目录 / 主题 / 配置文件，恢复后发现图片全没了。
- 备份和源站在同一台机器、同一块盘——机器被服务商停机，备份一起没。
- 备份有，但从来没人试过恢复。真到要用那天，发现 SQL 版本不兼容、编码对不上、外键顺序错乱，恢复失败。
正确的习惯是「恢复演练」：定期（我现在的节奏是每季度一次）真的把备份拿到一台干净机器上，走一遍完整恢复流程，记录耗时和踩到的坑。没演练过的备份，等于没有备份。
备份的三条底线
- 异地：备份不能和源数据在同一物理机。最低成本方案是 rsync 到另一台 VPS，或者用对象存储（S3/Backblaze B2/阿里 OSS）。
- 多版本：只留「最新一份」是不够的。如果你的站被挂马或被误删，最新备份可能已经把脏数据也备进去了。要能回滚到 N 天前——用时间点快照或轮转归档。
- 可验证：备份任务的成功状态要能主动告警，而不是默默失败。最简单的做法是每天检查备份文件大小/时间戳，异常就发个邮件或 Telegram 通知自己。
二、变更前先「能回滚」，而不是先「能上线」
新手改配置的思路是「怎么让它生效」；老手的思路是「万一炸了，我怎么在一分钟内退回上一个状态」。
血泪案例：改 Nginx 配置时直接改线上文件，nginx -t 通过就 reload，结果某个 location 的正则写错，导致所有 PHP 请求 502。这时候你手上没有上一个版本的配置文件，只能凭记忆往回改——而人在慌乱中改配置，出错概率翻倍。
一个几秒钟就能养成的习惯
# 改任何线上配置前，先复制一份带时间戳的副本
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak.$(date +%Y%m%d_%H%M%S)
cp /etc/nginx/sites-enabled/mysite /etc/nginx/sites-enabled/mysite.bak.$(date +%Y%m%d_%H%M%S)
# 更好的做法：整站配置纳入 git 管理
cd /etc/nginx && git init && git add -A && git commit -m "baseline"
# 以后每次改动前 commit，出问题直接 git checkout 回上一个提交
把 /etc/nginx、/etc/mysql、应用配置目录都纳入 Git，是我做过投入产出比最高的一件事。改坏了 git diff 一眼看到改了什么，git checkout . 一秒回滚。
数据库变更更要有回滚脚本
改表结构（加字段、改类型、删索引）比改配置文件危险得多，因为它不可逆。加字段前先想清楚：如果上线后发现问题，怎么退回去？删字段？那数据就没了。
稳妥的迁移习惯：先加新字段（不删旧字段）→ 双写 → 回填数据 → 切换读逻辑 → 观察一段时间 → 最后才删旧字段。每一步都可回滚。别想着一步到位。
三、日志轮转：磁盘写满是最蠢也最常见的宕机原因
个人站宕机的原因里，「磁盘 100%」常年占据前三。而磁盘写满的头号元凶，就是没人管的日志：Nginx access log 几个 G、应用日志疯狂滚动、MySQL 慢查询日志、systemd journal 无限增长。
磁盘写满的后果是链式的：数据库写不进去 → 网站报错 → 你登录上去排查 → 想删日志腾空间 → 发现连 df 输出都来不及看。更糟的是，MySQL 磁盘满时可能损坏数据文件，那就从「小事故」升级成「数据灾难」。
必须做的三件事
- Nginx 日志轮转：大多数发行版自带 logrotate 配置，但确认它真的在跑。同时给日志加上
postrotate里的nginx -s reopen，否则轮转后 Nginx 还在往被删的旧文件句柄写，新文件一直是空的，空间也不释放。 - journald 限制：编辑
/etc/systemd/journald.conf，设SystemMaxUse=500M、MaxRetentionSec=1month，然后systemctl restart systemd-journald。默认不限制的话，journal 能吃光整个盘。 - 磁盘水位告警：与其等宕机，不如在 80% 时就知道。
df -h写成脚本，超过阈值就通知。
#!/bin/bash
# /etc/cron.hourly/disk-alert
THRESHOLD=80
for line in $(df -h --output=pcent,target | tail -n +2 | tr -d '%'); do :; done
# 简化版：检查根分区
USE=$(df / | tail -1 | awk '{print $5}' | tr -d '%')
if [ "$USE" -ge "$THRESHOLD" ]; then
df -h | mail -s "[告警] 磁盘使用率 ${USE}%" you@example.com
fi
四、别在生产环境「试一下」
我犯过最蠢的错误之一：在生产服务器上直接 apt upgrade 一个关键组件（当时的场景是升级 PHP 主版本），想着「小版本升级应该没事」。结果新版本改变了一个默认行为，网站的某个功能静默失效，而我三天后才发现。
生产环境的原则是：任何变更都应该先在能随便折腾的地方验证过。对个人站来说，这意味着：
- 重要升级前，先在本地或一台便宜的测试 VPS 上跑一遍。
- 能用容器隔离的就用容器——把应用跑在 Docker 里，升级就是换个镜像，回滚就是换回旧 tag，干净利落。
- 如果实在没有测试环境，至少做到「低峰期操作 + 事前备份 + 事后立刻验证核心功能」。
「先在生产上试试」省下的十分钟，往往要用几个小时的事故处理来还。
五、安全不是「做了防火墙」就完事
个人站被入侵的场景，绝大多数不是高级黑客攻击，而是基础卫生没做好：
- SSH 开着密码登录 + 弱口令，被暴力破解（正确做法：只允许密钥登录，
PasswordAuthentication no）。 - PHP 应用、CMS、插件长期不更新，被已知漏洞打穿（正确做法：订阅你所用程序的安全通告，及时打补丁）。
- 数据库 3306 端口对公网开放，root 弱密码（正确做法：MySQL 只监听
127.0.0.1，需要远程就开隧道）。 - 网站目录权限给成 777「图省事」，结果被上传 webshell（正确做法：文件 644、目录 755，属主是运行用户）。
这些都不是高深技术，全是「知道但没做」或「嫌麻烦没做」。安全上的每一次偷懒，都是在给未来的自己埋雷。
入侵检测与事后取证
更麻烦的是，被入侵后你还不知道自己被入侵了。个人站被挂马、被植入挖矿程序、被当跳板，往往几个月都发现不了，直到搜索引擎标记「此网站可能被入侵」。
低成本的应对：
- 文件完整性监控：对 Web 目录做定期哈希比对，发现新增/修改的异常文件（尤其是
.php藏在uploads/里的）。 - 登录与进程审计：定期看
last、lastb、ps aux，有没有陌生 IP 登录、有没有异常高 CPU 的进程。 - 出站流量监控：如果服务器突然向陌生 IP 发送大量流量，很可能是被利用做 DDoS 或数据外传。
另外，安全出问题时保留下证据很重要：先别急着重装系统，先备份日志（/var/log）、跑一遍进程和网络连接快照、记录时间线。这些是后续判断「漏洞在哪、丢没丢数据」的唯一依据。
六、把「隐性知识」写下来
这一条听起来最虚，但代价最实在。个人站主脑子里装着大量「只可意会」的东西：某个服务为什么用了特殊参数、某个域名为什么解析到某台机器、某个定时任务到底在干嘛。
问题在于：三个月后的你，已经不记得三个月前的自己为什么这么配了。 而那次事故恰恰需要这些记忆来排查。
最低成本的实践：
- 建一个纯文本笔记（我用 Obsidian），每做一次非标准操作就记一条：做了什么、为什么、怎么回滚。
- 服务器上留一个
/root/NOTES.md，写清楚这台机器上跑了什么、关键路径在哪、有什么「不能动」的东西。 - 把你写过的所有临时脚本放到固定目录（如
/root/scripts/）并加注释，别让它散落在/tmp里随重启蒸发。
这不是给谁看的表演，是在给未来的自己留一条救命绳。事故来临时，能救你的往往不是技术，而是「我当时记下来的那一段说明」。
小结
运维这件事，高手和新手的差距往往不在「会不会」，而在「做没做」。备份验证、变更回滚、日志轮转、生产环境纪律、基础安全、文档记录——这六条每一条都不复杂，但每一条被忽视时都可能带来灾难性的后果。
如果你现在还没做，别想着一次全做完。挑最要命的一条（大概率是「备份 + 验证恢复」）今天就做掉，剩下的排进日程。个人站长没有团队兜底，唯一的保险就是这些看起来「没必要」的习惯。