全量备份是什么
全量备份每次都复制所选数据集合的完整内容，不与上一次备份产生依赖关系。它的价值在于恢复链路最简单：任意一份全量都能独立还原，不需要先找基线再按序叠加。代价是存储占用与备份时长随数据量线性增长，数据越大越难塞进有限的备份窗口。
基本信息
| 定义 | 备份选定数据集合的全部内容 |
|---|---|
| 优点 | 恢复只需一份，耗时稳定可预期 |
| 缺点 | 存储与窗口开销随数据量线性增长 |
| 定位 | 增量与差异备份链条的锚点 |
| 常见频率 | 每周一次或每月一次，按恢复目标调整 |
全量与增量差异
| 维度 | 全量备份 | 增量或差异备份 |
|---|---|---|
| 单次耗时 | 与数据总量成正比 | 只与变化量相关 |
| 恢复步骤 | 一份即可还原 | 依赖基线与后续副本的完整链条 |
| 失效影响 | 只损失该次备份 | 链条任一段损坏都会阻断恢复 |
| 存储占用 | 最高 | 较低，可配合去重进一步压缩 |
整目录全量归档
整目录全量归档
tar -czf /backup/full-$(date +%F).tar.gz -C /data app # 创建全量归档
# 校验产物条目数
tar -tzf /backup/full-$(date +%F).tar.gz | wc -l
# 记录校验和并写入日志
sha256sum /backup/full-$(date +%F).tar.gz > /backup/full-$(date +%F).tar.gz.sha256整盘镜像全量
整盘镜像全量
dd if=/dev/sda of=/backup/sda-$(date +%F).img bs=4M status=progress conv=fsync
# 压缩镜像以节省空间
zstd -T0 -10 /backup/sda-$(date +%F).img -o /backup/sda-$(date +%F).img.zst
# 校验镜像结构
fdisk -l /backup/sda-$(date +%F).img典型使用场景
- 周度锚点：为每日增量提供可回溯的基线，链条断裂时仍能从最近全量重建
- 变更前保护：大版本升级、数据迁移、结构改造前留一份完整副本
- 小数据量系统：数据量不大时直接每日全量，省去增量链的管理成本
- 跨环境交付：把完整副本一次性交付到测试或灾备环境，避免逐层叠加
- 合规留档：按季度或年度生成完整副本并归档到离线介质
全量的真正作用是锚点
在增量与差异策略中，全量备份并不只是『多一份数据』，它是整条恢复链的起点：没有可用的全量锚点，后续所有增量都无法独立还原。因此全量的保留期通常要长于增量，清理时也不能早于依赖它的增量副本。
执行前要确认的事
- 一致性方案是否明确：运行中的数据库与活跃文件应先停写、加快照或走应用一致性接口
- 空间是否留足：除本次副本外还要预留上一份副本与增量副本的空间，写满会导致任务失败
- 窗口是否够用：按历史耗时评估，并留出至少一次重试的余量
- 校验是否自动化：任务成功后比对产物大小与条目数，异常时立即告警
- 清理是否滞后：新全量成功后再删除旧全量，避免出现无可用锚点的空窗
对运行中的数据库直接做文件级全量可能得到不一致状态；应先做一致性手段（停写、快照或逻辑导出），而不是假设文件拷完就算备份。
全量备份可与去重、压缩组合使用：多份完整副本之间的重复块被去重后，存储开销接近增量，但恢复时仍只依赖一份。
全量的频率应与增量策略配套设计：每周一次全量加每日增量，通常能把恢复步骤控制在 7 步以内，同时把 RPO 压到一天以内。
失败后的排查顺序
- 先看目标空间：磁盘写满是全量任务失败最常见的原因，且常在任务后段才暴露
- 再看耗时是否溢出窗口，被后续任务或业务重启打断
- 核对权限与属主：以非 root 账号运行时，部分目录读取失败不会立刻报错但会漏文件
- 比对产物大小与历史值，明显偏小说明有文件被跳过