为什么你的知识库经不起一次断电
上周同事小李删错配置，想翻文档查原始设置，结果发现知识库数据库坏了。更糟的是，最近一次完整备份是三个月前。他只能靠记忆和零散聊天记录一点点还原，整整折腾了两天。
这事儿不是个例。很多团队把知识库当成“静态仓库”，以为写进去就万事大吉。可硬盘会坏、系统会崩、人会误操作。没有靠谱的备份策略，知识库再全也没用。
定好备份频率：不是越频繁越好
每天备份一次听起来安全，但如果知识库改动频繁，一天一备可能还是丢数据。我们组的做法是：每日增量 + 每周全量。工作日傍晚自动跑一次增量备份，周末做一次完整归档。这样既不拖慢系统，又能控制损失在24小时内。
别只存本地：异地才是底线
见过太多人把备份文件放在同一机房的另一台服务器上。一旦机房停电或起火，主库和备份一起完蛋。我们现在用的是阿里云OSS+本地NAS双存策略。每天的备份自动同步到云端，哪怕办公室进水也不怕。
自动化脚本示例：让机器干活
手动备份迟早会漏。我们用一段简单脚本定时执行：
#!/bin/bash
# 增量备份脚本 example
DATE=$(date +%Y%m%d)
mysqldump -u wikiuser -p'password' --single-transaction wikidb \
--where="updated_at > DATE_SUB(NOW(), INTERVAL 1 DAY)" \
> /backup/wiki_incremental_$DATE.sql
# 自动压缩并上传至OSS
tar -zcf /backup/wiki_$DATE.tar.gz /backup/wiki_incremental_$DATE.sql
ossutil cp /backup/wiki_$DATE.tar.gz oss://your-bucket/backups/定期恢复测试：别等到真出事才试
去年我们搞了一次“灾难演练”：模拟主库损坏，从备份恢复。结果发现有个权限配置漏了，导致恢复后无法登录。这种问题只有真走一遍才会暴露。现在每季度拉一次恢复流程，确保链路通畅。
版本保留策略：别让磁盘爆掉
备份不是越多越好。我们保留最近7天的增量、4周的周备、以及每季度一次的年度快照。超过时间的自动清理。用crontab加个定时任务：
# 清理7天前的增量备份
find /backup -name 'wiki_incremental_*.sql' -mtime +7 -delete
# 清理3个月前的周备
find /backup -name 'wiki_weekly_*.tar.gz' -mtime +90 -delete权限与加密：别让人顺手牵羊
知识库里有内部架构图、账号模板，甚至部分敏感配置。备份文件一样重要。我们对所有备份启用AES-256加密，密钥由运维组长单独保管。访问云端存储也设了IP白名单，防止外泄。
监控告警：让异常无处藏身
再好的策略也可能失效。比如某次OSS同步因网络超时失败，但没人察觉。后来我们在Zabbix里加了监控项：每天检查最新备份文件是否存在、大小是否正常。一旦异常，企业微信立刻推送给负责人。