设计恢复流程

在 LabHub 中继续学习

一句话总结

恢复的关键全在于顺序与验证。在真正走完流程并测量耗时之前，RTO 只是愿望，不是数字。

流程图: 顺序与验证 · 先经过临时路径是关键。 · 实际计时 · 从备份存储取得文件、验证、启动服务以及一致性检查的时间

为什么需要它

即使备份制作得很好，恢复仍会失败，原因通常出在流程上。

不知道该使用哪个备份（全量？增量？哪一代？）
恢复顺序错误（先解开增量，或颠倒顺序）
恢复位置选错，覆盖了当前系统
文件已恢复，但服务无法启动（权限、SELinux、UID 映射）

工作原理

安全的恢复顺序

# 1. 임시 경로로 먼저 푼다 — 절대 바로 덮어쓰지 않는다
mkdir -p /restore/check
tar -xzf /backup/full-2026-08-20.tar.gz -C /restore/check

# 2. 내용을 확인한다
find /restore/check -type f | wc -l
diff -r /restore/check/etc/nginx /etc/nginx | head -40

# 3. 필요한 것만 옮긴다
rsync -aHAX --numeric-ids /restore/check/etc/nginx/ /etc/nginx/

先经过临时路径是关键。 直接用 -C / 解包是一项无法撤销的操作。

增量恢复的顺序

必须严格遵循全量 → 增量 0 → 增量 1 → ……的顺序。使用 tar 的 --listed-incremental 制作的增量包还包含删除信息；顺序错误时，本应存在的文件也可能消失。

tar --listed-incremental=/dev/null -xzf full.tar.gz -C /restore/
tar --listed-incremental=/dev/null -xzf inc0.tar.gz -C /restore/
tar --listed-incremental=/dev/null -xzf inc1.tar.gz -C /restore/

恢复时惯例使用 --listed-incremental=/dev/null，表示不更新快照文件。

选择性恢复

无需解开整个归档，也可以只取出特定文件。

tar -tzf backup.tar.gz | grep nginx.conf
tar -xzf backup.tar.gz -C /restore/ src/conf/nginx.conf
tar -xzf backup.tar.gz -C /restore/ --strip-components=1 src/conf/

--strip-components=N 会在解包时移除前面的 N 个路径组成部分，适用于归档结构与恢复位置不同的情况。

测量时间

要确认 RTO，必须实际计时。

START=$(date +%s)
# ... 복구 절차 전체 ...
END=$(date +%s)
echo "복구 소요: $((END - START))초"

计时范围不能只有解包耗时，还必须包括从备份存储取得文件、验证、启动服务以及一致性检查的时间，这才是真实的 RTO。在实践中，无法满足 RTO 的首要原因往往不是解包缓慢，而是通过网络获取备份所花的时间。

恢复后的验证

文件数量与总大小是否符合预期
权限与所有者是否正确（是否使用了 --numeric-ids）
服务能否启动
能否通过应用的一致性检查

有备份不等于能够恢复

备份成功日志只表示生成了文件。要说‘能够恢复’，还必须确认三件事。

能否读取——压缩数据未损坏，解密密钥仍然可用。
是否完整——所需内容是否齐全（模式、数据、序列、扩展）。
能否在时限内完成——实际恢复通常比预计耗时长得多。

第三项最容易失守。如果恢复 500GB 需要 6 小时，而 RTO 是 1 小时，那么这份备份不能用于灾难恢复。要满足 RTO，必须使用副本或快照——逻辑备份是最后一道防线，不是首选手段。

方式	恢复时间	恢复点	用途
逻辑转储(pg_dump)	慢（小时级）	转储时刻	迁移、部分恢复
物理备份 + WAL	中等（分钟至小时）	任意时刻	灾难恢复
存储快照	快（分钟级）	快照时刻	快速回滚
提升只读副本	最快（秒级）	接近实时	高可用

恢复演练中真正测量的内容

不能以‘恢复成功’为终点，还要留下数字。

## 복구 리허설 2026-09-06

- 대상: labhub-prod DB (실 용량 142GB)
- 백업 시각: 2026-09-05 12:30 KST
- 복원 목표 시점: 2026-09-05 18:00 KST (PITR)

| 단계 | 걸린 시간 |
|---|---|
| 백업 내려받기 | 21분 |
| 기본 백업 복원 | 47분 |
| WAL 재생 (5.5시간분) | 33분 |
| 서비스 기동·검증 | 9분 |
| **합계 (RTO 실측)** | **1시간 50분** |

- 검증: 행 수 대조 3개 표 일치, 최근 주문 10건 육안 확인, 애플리케이션 기동 성공
- 발견: WAL 아카이브에 12분 구멍(2026-09-05 14:02~14:14) — 아카이빙 재시도 설정 필요
- RPO 실측: 12분 (목표 5분 미달 — 개선 필요)

没有发现问题的演练，几乎等于没有演练。 第一次执行时，几乎总会发现某些遗漏。

何时进行

最低限度是每季度一次。在此期间，模式、容量与基础设施都会变化。
更换备份方式或存储后必须立即演练。
新人加入时，让他只按照操作文档完成一次，这时最容易暴露文档缺漏。

演练必须在与生产隔离的环境中进行。向生产数据库执行恢复的那一刻，它就不再是演练，而是事故。

生产现场常见的情况

‘恢复完成了，但服务起不来。’ 原因通常集中在 UID/GID 映射、SELinux 上下文、文件系统能力差异（不支持 ACL），以及内核或库版本差异。--numeric-ids 与 --selinux 分别用于应对前两项。

恢复文档只存放在恢复负责人的笔记本里。 恰恰可能在那台笔记本无法使用时，才最需要执行恢复。

下一实验要做什么

使用前面创建的备份集进行恢复演练。按照安全顺序恢复，与原始数据比较，完成选择性恢复和按顺序恢复增量备份，并且实际计时，判断是否满足 RTO。