结论先行：日志平台的多副本解决的是磁盘坏掉，不是"日志没了"。误删、越权修改、上游设备改了配置导致采集中断、以及平台自身的索引损坏，都会在几份副本上同时发生。要让日志在需要的时候拿得出来，需要三样东西分开定：备的是原始日志还是索引、备到哪一层去、以及恢复的时间目标是多少。
本文只谈日志这类证据本身怎么单独留一份，不谈留存期该定多长，也不谈平台侧怎么防篡改——那两件事分别属于成本账和完整性设计。
副本不等于备份，差在哪
多数日志平台在存储层就做了副本，常见的是一式两份或三份。这套机制针对的是硬件故障：一块盘坏了，另一块还在，业务不中断。它工作得很好，也因此容易让人产生一种错觉——数据已经很安全了。
但副本防不住下面四种情况，原因很朴素：副本是同步的。
- 误删：管理员执行了一次范围写错的清理，删除动作在几秒内同步到所有副本。
- 越权修改：拿到高权限的人改动或删除记录，同样同步。
- 逻辑损坏：索引重建、字段映射改错、解析规则升级出问题，坏掉的是数据本身，副本复制的是坏数据。
- 采集中断：上游设备或采集端停止上报，平台侧一切正常，只是这段时间的数据从来没有进来过。
前三种属于"进去了但坏了"，第四种属于"根本没进来"。这四种情况里，备份只能解决前三种的一部分，第四种要靠采集侧的缺口监测——两者不是一回事，不能互相替代。
备什么：原始日志，不是索引
这是这件事上最关键的一个判断。日志平台里有两种东西：原始日志（采集进来的一行一行原文）和索引（为了查询而建立的结构化数据）。
索引是可以重建的，原始日志不能。所以备份的对象应当是原始日志，索引留在平台侧、坏了再重建就行。反过来，如果只备份了平台的整机镜像或数据库快照，表面上看很完整，实际会遇到两个麻烦：恢复要连同平台版本一起还原，环境一变还原可能失败；以及快照体积大，频率做不高，真出事时能退回去的时间点很粗。
备份原始日志的好处还有一个：它和平台解耦。哪怕将来换一套日志平台，这批原始日志依然能被重新导入、重新解析，历史数据不会随着产品替换一起作废。
备到哪一层去：三档，按需组合
备份不是越远越好，而是要分层。常见的三档各自有不同的防护目标和成本：
| 档位 | 防护对象 | 恢复粒度 | 代价 |
|---|---|---|---|
| 同机房另一套存储 | 平台自身故障、索引损坏 | 小时级 | 低，但不防机房级事故 |
| 异地机房或对象存储 | 机房级事故、单点不可用 | 小时到天级 | 中，主要是流量与存储费用 |
| 离线介质或不可变存储 | 勒索类攻击、内部越权删改 | 天级 | 高，恢复慢，但这一档才有"最后一道"的意义 |
三档里最容易被跳过的是第三档，而它恰恰是面对勒索与内部越权时的分水岭。前两档都是在线可写的，一旦账号权限落到对方手里，备份会被一起处理掉。离线或不可变存储的价值不在于快，在于"写进去就改不掉"，代价是恢复慢，能退回去的时间点也粗。
怎么组合取决于日志里放的是什么。如果只是运维排障用的常规日志，前两档够用；如果日志承担合规留存与事后取证的职责，第三档就不能省。
恢复目标要单独定两个数
备份方案里最常被含糊带过的是恢复目标。这里需要两个不同的数字，很多人把它们混成一个：
- 能退回去多远：最坏情况下，可以接受丢掉最近多长时间的数据。这决定了备份频率。
- 多久能恢复：从决定恢复到数据可查，能接受多长时间。这决定了备份形态和恢复演练的必要性。
两个数字要分开定，因为它们指向不同的投入。想要"最多丢一小时"，就要提高备份频率，成本落在带宽与存储上；想要"两小时能查回来"，就要做恢复演练和预置环境，成本落在人力和流程上。
有一类场景需要特别说：出事之后往往不是要恢复全部历史，而是要恢复某一小段时间、某一批对象的数据。如果备份形态只能整份还原，那么"恢复一小段"实际上做不成，最后会变成把整份数据还原到另一套环境再挑出来——时间成本远超预期。所以备份形态要能支持按时间范围和按对象局部提取，这一点在选型或自查时值得单独问一句。
怎么证明恢复得回来
备份这件事的特点是：不做演练的话，它的可用性永远是未知数。备份任务日志显示"成功"，只说明数据写出去了，不说明能读回来。
验证可以做得很轻，但要真的做，四项就够：
- 抽一份恢复：随机挑某一周的备份，恢复到临时环境，确认能按时间范围和对象查到具体记录。
- 核对可比对的东西：恢复后的条数、时间跨度、关键字段与平台侧原始数据比对，差异要能解释。
- 记录耗时：把恢复用了多久如实记下来，这个数字是下次定恢复目标时的依据，也是出事时向业务方承诺的底气。
- 确认权限：谁能发起恢复、谁批准、恢复出来的数据放在哪、用完怎么清理。这一项在合规场景里和备份本身同样重要。
频率上，通常建议与现有巡检节奏绑定，比如每季度跟一次日常巡检一起做，不额外占一次排期。做过的记录要留着，因为审计问的往往不是"有没有备份"，而是"最近一次恢复验证是什么时候做的、结果是什么"。
边界与前提
要承认一件事：备份日志的成本不低，而且随着留存期线性增长。如果日志量很大、留存期又长，全量备份三年并不现实，通常的做法是对近期数据做完整备份、对远期数据只保留归档副本并降低验证频率。
另外，备份不能替代采集侧的完整性。日志没采进来，备份里也不会有。两者的分工要写清楚：备份管"已经进来的数据别丢"，采集侧管"该进来的数据都进来了"。深圳市奇摩计算机有限公司在交付日志平台时，会把这两条分开写进运维文档，因为一旦混在一起，出问题时容易互相推。
如果现网已经有日志平台，但没人说得清最近一次恢复验证是什么时候做的，这件事值得排在下一轮巡检的最前面。欢迎预约咨询，我们可以一起把这几项先过一遍。