数据备份

日志采集工具上线，本来想少踩点坑，结果日志堆成山没人翻。说到底是采集范围、告警阈值和谁来看这三件事没定清楚，这里聊聊我踩过的弯路。

数据泄露风险管控的短板很少在技术，基本都在流程：权限谁批、账号谁收、日志谁看、导出谁审。设备买得再全，这几步没人负责照样漏，文章给了一套能落地的笨办法。

本机服务器最常见的三个误区：把它当正式环境、只在内网测通、备份和端口全凭默认。第2个最隐蔽，等外面的人打不开才发现。

云备份该备份哪些数据，多数人只备了一半：文件占大头，真正要命的数据库、配置、凭据和状态数据常常漏在备份之外，出事那天才发现。

数据最小化三原则听着像合规术语，核心就一句话：能不收就不收。从收集范围、留存期限、访问权限三块讲清怎么落地，附上几张能直接用的清单。

快照数据能一键回滚，但回滚和恢复不是一回事。备份放在哪、凭证怎么分开管、恢复按什么顺序走，这三件事没理顺，出事那天照样救不回来。

自建开源项目git，装起来不难，难的是权限和备份。两套账号体系、组权限划太粗、只备份裸仓库却漏掉数据库和 LFS，这三个坑都会真真切切踩到。

服务商一纸公告就停服，科技公司爆雷之后，站点数据往往最被动。备份能不能拿回来、多久能迁走，比事后找人吵架管用。以官方公告和合同条款为准。

重装之前没做备份，数据还能不能回来，主要看盘被写到了什么程度。服务器重装系统盘动的是分区表和文件索引，正文数据往往还躺在原处，前提是发现后立刻停手、别再往原盘写东西。

云备份数据恢复详解里最反直觉的一点：备份跑得越勤，出事那天救回来的数据可能越旧。同步型备份、增量链断裂和轮转策略，都会让最新那份变成最没用的一份。