全量与增量备份必须协同使用：全量提供独立恢复基准点，增量捕获高频变更；推荐“每周全量+每日增量”基础组合，辅以小时级同步和日志备份实现任意时间点恢复，并须定期验证备份有效性。

服务器自动备份任务要兼顾恢复效率、存储成本和数据安全性，增量与全量策略不是二选一，而是必须协同使用的组合关系。核心逻辑是：全量提供可独立恢复的基准点，增量负责高频、轻量的变更捕获——两者缺一不可。

每周一次全量 + 每日一次增量（最通用基础组合）

这是中小规模业务最稳妥、最容易落地的组合。全量在周日凌晨低峰期执行，作为当周所有增量的恢复起点；增量在每天凌晨执行，只备份自上次全量以来变化的文件或数据库块。

• 全量用 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）或解压测试头几个文件
• 每月至少一次在测试环境执行完整恢复流程：拉取全量+增量+日志，还原后比对关键表记录数和哈希值
• 把恢复耗时、校验结果写入日志，并接入告警（如企业微信/钉钉机器人通知失败项）