网站更新内容的痕迹，全在日志和快照里

页面被改过，它自己是不会开口的。做过几十个站之后我养成一个习惯，拿到一个说”好像被人动过”的站，先不看前台，先去翻两个地方，日志和快照。网站更新内容痕迹全在日志快照里，这话听着像废话，真到用的时候，多数人只记得其中一样。日志告诉你什么时候、谁碰过，快照告诉你碰之前长什么样，缺一头，事情就说不圆。

日志和快照压根是两件事，各管一半

先把这俩分开。日志是流水账，服务器上跑过的每个请求都会留下一行字，nginx 的 access.log、error.log，宝塔面板一般在 /www/wwwlogs/ 下面，Apache 那边通常在 /var/log/httpd/ 或者 /var/log/apache2/，具体路径以你实际环境和服务商页面说明为准。快照是照片，某个时间点的整盘或者整库状态，云厂商的磁盘快照、对象存储的版本控制、CMS 自带的修订版本、你自己 rsync 出来的一份冷备，都算。流水是连着看的，照片只能对着看，用途完全是两码事。有人把快照当日志查，翻半天时间点对不上，白忙。

网站更新内容痕迹全在日志快照里，先动哪一头

顺序别反着来。我一般先看快照，不是恢复，只是把那份快照挂出来看看对应日期的备份目录，确认原来是什么样，心里有底了再去翻日志找变化发生的那一刻。反过来先翻日志也成，就是容易被几万行 access 淹掉，访问量稍微大点的站，一天的日志就够看半天，眼睛都花。先有对照物再找时间点，效率高一截。

日志里最值钱的东西是时间戳

内容改没改，肉眼有时候真看不出来，改个价格、换个电话、塞一句外链，页面看着还是那个页面。这时候就是时间戳干活。文件层面用 stat 看：stat /www/wwwroot/你的站/index.php，会给出 Modify、Change、Access 三个时间，Modify 最直观。目录里找最近被动过的文件，一条命令的事：find /www/wwwroot -type f -mtime -1，把 -1 换成 -3 就是三天内。注意 mtime 是能被改的，touch 一下就能伪造，rsync 加 -t 参数搬运时也会把原文件的修改时间带过来，所以它只能算线索，不能当铁证。真要坐实，还得拿文件的 mtime 去跟 access.log、error.log 里的时间点对，后台登录、上传接口、POST 请求，这几类记录能串起来看。error.log 更值得翻，有人往文件里写东西、PHP 报错、权限不对被打回来，都会在那里留痕迹。

搜索引擎的快照，只能当旁证

还有一类快照是搜索引擎那边的缓存页。它能证明某个时间点上你的页面长什么样，但延迟不好估，收录也可能本身就是旧的，拿来当时间轴上的一个参考点还行，当证据链就别指望了。有时候网站更新内容痕迹全在日志快照里这句话的另一层意思就是，第三方的东西只能参考，自己服务器上那份才作数。

快照不等于备份，别指望它当天救急

这里最容易出岔子。云盘快照有保留周期，按策略滚动删除，一个月前的多半早就没了；CMS 的修订版本只在后台编辑器里生成，走接口改的、直接进数据库改的，一条都不留；数据库没开 binlog，那就什么都追不回来。这些”以为有其实没有”的东西，平时风平浪静的时候一点感觉都没有，出事那天最要命。所以定期按周按月的留几份手动快照不亏，磁盘那点钱跟重建一个站比，真不算什么。

改完不留痕的站，问题多半在权限

还有一种情况是日志翻遍了也看不出谁干的，因为账号是共用的。FTP 一个账号全组人用，后台管理员密码写在群里，phpMyAdmin 挂在公网没做限制，这种站被动了手脚，日志里只能看到一个 IP 登录过，具体是谁说不清。别省这点事，一人一个账号，能上 SFTP 就别用明文的 FTP，后台密码定期换，离职的人第一时间停掉。日志按天切割，保留期留长一点，磁盘不够就压一下，这些配置在面板里都是点几下的事。

真出了事，按这个顺序翻

给你个我自己用的顺序。第一步，先记下发现的时间点，别急着恢复。第二步，找到最近一份状态正常的快照或者备份，确认它对应的日期。第三步，在这个日期和发现时间之间筛 access.log 里的 POST 请求和后台路径，看看有没有陌生 IP。第四步，find 一下这段时间内被改动过的文件，把清单列出来。第五步，比对出来改了哪些，再决定是回滚还是打补丁。回滚这一步要小心，只回滚被改的那几个文件，别整盘往回推，数据库更别轻易覆盖，新产生的内容一盖就全没了。拿不准就先复制一份现场留着，再动手。

最后留一句，日志该开的开，保留期别舍不得，看到”关掉日志能省点磁盘”这种建议直接划掉。快照按周按月留几份，别只信自动策略。真到出事那天，能说话的往往就是你当时懒得关掉的那点痕迹。