sql 数据库备份必须全量与增量结合：全量提供独立还原基础，增量节省空间和时间；需规范命名、定期演练、自动化调度并异地加密存储。
SQL 数据库备份不能只靠全量，必须搭配增量策略，才能兼顾恢复速度、存储成本和数据安全。
全量备份：基础但耗资源
全量备份是把整个数据库（或指定库 / 表）在某一时间点的完整副本保存下来。它独立、可直接还原，是所有备份链的起点。
- 适合每日低峰期执行，例如凌晨 2 点自动调用 mysqldump 或pg_dump生成 SQL 文件，或使用 SQL Server Maintenance Plan 做。bak 备份
- 建议压缩存储（如 gzip 或 7z），并校验 MD5/SHA256，防止备份文件损坏
- 保留最近 3–7 天的全量备份，太老的可归档至对象存储（如 S3、MinIO），避免本地磁盘撑满
增量备份：只存变化，节省空间与时间
增量备份记录自上次任意类型备份（全量或上一次增量）以来的数据变更，体积小、速度快，但还原时需按顺序拼接多个备份文件。
- MySQL 可通过 mysqlbinlog 解析二进制日志（binlog）实现逻辑增量；启用 binlog_format=ROW 更可靠
- PostgreSQL 推荐用pg_basebackup + WAL 归档，WAL 文件即物理增量，配合 archive_command 自动同步到远程目录
- SQL Server 可用事务日志备份（BACKUP LOG），每 15–30 分钟执行一次，依赖全量备份存在
备份链管理：保证可还原性是核心
单独备份没用，关键是要形成一条清晰、可验证的还原路径。
- 命名规范很重要：例如full_20240520_0200.sql.gz、incr_20240520_1430.xlog，含日期、时间、类型
- 每天至少一次还原演练（可在测试环境），检查全量 + 最新增量是否真能成功恢复到指定时间点
- 监控备份任务状态和大小：若某次增量只有几十字节，可能意味着日志未正确归档或备份脚本出错
自动化与异地保护不可少
人工备份等于没备份，而所有备份放在同一机房等于单点失效。
- 用 cron（Linux）或 Task Scheduler（Windows）调度脚本，失败时通过邮件或企业微信告警
- 备份文件生成后，立即同步到另一台服务器或云存储，延迟不超过 1 小时
- 对敏感数据备份启用加密（如 gpg 加密 dump 文件，或数据库原生 TDE 功能）
