公司服务器凌晨报警，安全团队紧急排查，结果发现最关键的登录日志竟然丢了。不是被删除，而是根本没备份。这种事听起来离谱，但在实际运维中并不少见。日志是系统行为的“行车记录仪”，一旦发生入侵或故障，没有完整的日志，等于闭眼查案。
为什么日志不能只靠实时查看？
很多人觉得，只要能实时看到日志就够了，比如用 ELK 或者 Graylog 搭个可视化面板，界面漂亮，搜索方便。但这些工具通常只保留最近几天的数据。硬盘满了就自动清理旧记录。真等到一个月后审计要求提供某天的操作记录，才发现早已被覆盖。
更现实的情况是：攻击者得手后第一件事就是删日志。如果你的日志只存在本地，那等于证据随机器一起被毁。必须有独立于生产环境的备份机制，才能保证日志的完整性和可用性。
定好三个核心参数：频率、保留期、存储位置
一个实用的日志备份策略，首先要明确三点：多久备份一次？备份保留多久？存到哪里去？
频率取决于业务重要程度。普通网站可以每天备份一次，金融类系统建议每小时甚至实时同步。保留期则要看合规要求和存储成本。一般建议至少保留90天，涉及支付或敏感操作的系统最好保留180天以上。
存储位置最关键。绝对不能和原服务器在同一物理机或局域网内。理想做法是上传到异地对象存储，比如阿里云OSS、AWS S3，或者专用的SIEM平台。这样即使主数据中心宕机，日志依然可查。
用脚本自动化，减少人为遗漏
手动拷贝日志不现实，容易漏、容易忘。写个定时任务才是正道。比如Linux下用cron配合rsync：
# 每日凌晨2点打包昨天的日志并推送到备份服务器
0 2 * * * /usr/bin/find /var/log/app/ -name '*.log' -mtime 1 -exec tar -czf /backup/logs/$(date -d yesterday +\%Y\%m\%d).tar.gz {} \;
0 3 * * * /usr/bin/rsync -az /backup/logs/ backup@192.168.10.50:/data/logs/如果是云环境，可以直接调用API上传。比如用Python脚本结合阿里云SDK：
from aliyunsdkcore.client import AcsClient
from aliyunsdkoss.request.v20190517 import PutObjectRequest
client = AcsClient('<your-access-key>', '<your-secret>', 'cn-hangzhou')
request = PutObjectRequest.PutObjectRequest()
request.set_BucketName('logs-backup-bucket')
request.set_ObjectKey('app-logs/20240405.log.gz')
with open('/var/log/app/20240405.log.gz', 'rb') as f:
request.set_Content(f)
client.do_action_with_exception(request)定期验证备份有效性
备份做了不代表能用。曾经有企业每年花几十万做灾备，结果真正出事时发现备份文件损坏，恢复不了。所以要定期抽查，比如每月随机选一天的日志，尝试下载解压，确认内容完整。
还可以加个监控项：如果某台服务器连续24小时没有新日志传入备份系统，就发告警。这可能是服务挂了，也可能是备份链路断了，早点发现总比事后补救强。
日志备份不像防火墙那样看得见摸得着，但它在关键时刻能帮你说话。别等出了事才后悔当初没留证据。