5.4 数据持久化策略与备份

5.4 数据持久化策略与备份

本节摘要：仓库运营学——为有状态容器制定持久化纪律：数据库箱子的标准配置（卷、配额、重启策略三件套）、旁路备份法（临时箱子加卷）、跨机迁移的打包过船流程。本节把前面所有知识拧成一套能上生产的动作。

备份不是选项，是岗位责任

上一节学会了卷，本节回答运营的终极问题：卷里的数据怎么保住。卷不会被拆箱带走，但会被磁盘故障吞掉、被误操作删掉、被宿主机故障连坐。没有备份的数据库箱子，等于把家产放在没有消防的仓库里。本节的目标是让你带走三样东西：一套标准的有状态容器配置、一个不需要停止服务的备份手法、一条跨机迁移的完整流程。

有状态容器的标准配置

数据库类箱子（最典型的有状态应用）有一套约定俗成的"三件套"配置——卷挂载、资源配额、重启策略，缺一不可：

# 数据库箱子的标准起吊姿势（以 Redis 为例）
docker run -d \
  --name prod-cache \
  --network fleet-net \
  -v cache-data:/data \
  --memory 512m --memory-swap 512m \
  --cpus 1 \
  --restart unless-stopped \
  redis:7-alpine \
  redis-server --appendonly yes
# -v cache-data:/data            持久化：数据落卷
# --memory/--cpus                载重核定（4.5 节纪律）
# --restart unless-stopped       值夜自动化（4.1 节纪律）
# --appendonly yes               应用层持久化开关：Redis 开启追加日志落盘
​

注意最后一行的应用层持久化开关——容器层持久化（卷）与应用层持久化（落盘机制）是两个层面，都要打开。卷保证"磁盘比容器命长"，应用自身的落盘机制保证"内存数据写进磁盘"。只挂卷不开落盘的应用，重启后照样丢内存态数据。

旁路备份法：不停车取货

经典难题：备份期间不能停服务。容器世界的巧解是旁路备份法——起一只一次性临时箱子，挂载同一个卷，把卷数据打包到标准输出，落成宿主机上的压缩包。全程业务箱子照常跑：

# 旁路备份：临时箱子挂卷打包，输出重定向到宿主机文件
docker run --rm \
  -v cache-data:/data:ro \
  -v "$(pwd)/backups:/backup" \
  alpine \
  tar czf /backup/cache-$(date +%Y%m%d).tar.gz -C /data .
# -v cache-data:/data:ro    以只读方式挂同一个卷（:ro 保证备份过程不污染数据）
# -v 本地目录:/backup       备份产物的落地点
# tar czf ...               打包压缩整个卷内容
# --rm                      打包完自动离场，不留痕迹

# 验货：备份包在宿主机上
ls -lh backups/
# -rw-r--r-- 1 root root 1.8M Aug 30 11:02 cache-20260830.tar.gz
​

这套手法的数据流值得画出来看——业务箱子全程无感，备份箱子只是仓库的另一位访客：

图 5-3：旁路备份法——业务不停车取货

这套手法的精髓是"卷是公共仓库，谁都能凭凭据（挂载）来打包"。数据库正在写入时打包有一致性风险——严格场景应配合数据库自身的快照或备份命令（先让数据库落盘再打包卷），轻量场景定期打包已经胜过裸奔。

恢复前先验包——压缩包能列出内容才算完好。这十秒钟的检查能挡住"备份包其实是空的"这类灾难性乌龙（定时任务磁盘写满时真的会发生）：

# 验包：能列出文件清单，这份备份才算数
docker run --rm -v "$(pwd)/backups:/backup:ro" alpine \
  tar tzf /backup/cache-20260830.tar.gz
# ./
# ./appendonly.aof
# ./dump.rdb
# 清单非空且文件齐全，再进入恢复流程
​

恢复与迁移演练

备份的价值在恢复演练里验证。把刚才的备份包恢复到一个新卷：

# 建一个新卷，用同样的旁路手法把备份包解开进卷
docker volume create cache-restore
docker run --rm \
  -v cache-restore:/data \
  -v "$(pwd)/backups:/backup:ro" \
  alpine \
  sh -c "cd /data && tar xzf /backup/cache-20260830.tar.gz"

# 起一只箱子验证恢复结果
docker run -d --name restore-check -v cache-restore:/data alpine sleep 60
docker exec restore-check ls /data
# appendonly.aof  dump.rdb ...   <- 数据回来了，演练通过

docker rm -f restore-check
​

跨机迁移是备份的孪生技能：把备份包传到目标机器，按上面的恢复流程解进目标机的新卷，业务箱子在目标机挂新卷起吊——迁移 = 备份 + 恢复 + 换台机器起吊。卷本身不必跨机"搬运"，打包过船即可。

备份的频率与保留策略照业务价值定。经验起点：每天一次全量备份包，保留最近七天加每月归档一份；备份包务必异地存放至少一份（同机备份防不了宿主机故障）。把旁路备份命令写进定时任务即可自动化——Linux 上配一条 cron，Windows 计划任务同理，跑完顺手检查产物大小，备份包体积骤降往往是数据异常的前兆，值得加一条告警。

一页纸的持久化纪律

把本章的运营规则归拢成值班手册的一页纸：所有持久数据必须落卷（可写层只放临时文件）；卷名按"应用-用途"规范命名（order-db-data 而不是随机代号）；数据库箱子三件套齐配（卷、配额、重启策略）；备份按旁路法自动化（定时任务跑 tar 流程，备份包异地存放一份）；恢复演练常态化（没恢复过的备份等于没有备份）；prune 类清理命令前必看清单（上一节的警告在此复读一遍）。

本节要点回顾

• 有状态容器三件套：卷挂载、资源配额、重启策略；配额与重启策略来自第 4 章纪律。
• 容器层持久化（卷）与应用层持久化（落盘开关）是两个层面，都要打开。
• 旁路备份法：临时只读挂卷打包，业务不停车；--rm 保证临时箱子用完离场。
• 迁移 = 备份 + 恢复 + 换机起吊，卷数据打包过船，不必搬运卷本身。
• 纪律六条：必落卷、规范命名、三件套、自动备份、恢复演练、清理前看清单。

航道与仓库齐备。下一章把手工组队升级为工程化编队——Compose 声明文件，一键起航。