全量与增量备份必须协同使用：全量提供独立恢复基准点，增量捕获高频变更；推荐“每周全量+每日增量”基础组合，辅以小时级同步和日志备份实现任意时间点恢复，并须定期验证备份有效性。
服务器自动备份任务要兼顾恢复效率、存储成本和数据安全性，增量与全量策略不是二选一，而是必须协同使用的组合关系。核心逻辑是：全量提供可独立恢复的基准点，增量负责高频、轻量的变更捕获——两者缺一不可。
每周一次全量 + 每日一次增量（最通用基础组合）
这是中小规模业务最稳妥、最容易落地的组合。全量在周日凌晨低峰期执行，作为当周所有增量的恢复起点；增量在每天凌晨执行，只备份自上次全量以来变化的文件或数据库块。
- 全量用
tar -czpf或mysqldump生成带日期命名的归档，存本地+NAS双目标 - 增量可用
rsync --link-dest（文件系统）或基于 binlog/LSN 的工具（如 xtrabackup 增量模式） - 务必启用 VSS（Windows）或
--single-transaction（MySQL），避免备份时文件被锁或数据不一致 - 保留最近 4 份全量 + 对应全部增量，旧备份自动清理，防止磁盘撑满
关键数据加小时级增量或同步（应对误删/快速回退）
对用户上传目录、订单库、配置文件等高频变更且高敏感的数据，光靠每日增量不够——误操作可能发生在上午10点，等到次日凌晨才备份，就丢了14小时数据。
- 用
rsync -av --delete或robocopy /MIR每小时推送到 NAS 或另一台服务器 - 不覆盖历史，按小时建子目录（如
/backup/hourly/20260706-19），保留最近12–24小时快照 - 这类同步不替代每日增量，而是补充“时间粒度”，用于快速定位和回退
数据库需叠加日志备份（实现任意时间点恢复）
纯全量+增量只能恢复到某天凌晨的状态，无法还原上午9:23误删的一张表。真正生产环境必须引入事务日志（如 MySQL binlog、PostgreSQL WAL）。
- 开启 binlog 并设置
expire_logs_days = 30，保证日志不被自动清理 - 每15分钟执行一次
mysqlbinlog备份，或用 DTS/Canal 实时同步到对象存储 - 恢复时：先还原最近全量 → 应用后续所有增量 → 重放 binlog 到故障前一秒
- 日志备份必须异地存放（如阿里云 OSS、腾讯云 COS），避免本地机房故障导致全链路失效
备份验证不能跳过（否则等于没备）
自动任务跑成功 ≠ 数据能恢复。很多故障暴露在“第一次真正需要恢复时”。
- 每次备份完成后，自动校验压缩包完整性（
tar -tzf backup.tar.gz > /dev/null）或解压测试头几个文件 - 每月至少一次在测试环境执行完整恢复流程：拉取全量+增量+日志，还原后比对关键表记录数和哈希值
- 把恢复耗时、校验结果写入日志，并接入告警（如企业微信/钉钉机器人通知失败项）
