Cinder 备份实战：cinderback 增量链、调度清理与恢复演练

简介：面向OpenStack运维人员与云平台开发者的Cinder卷备份辅助脚本，侧重以Python示例方式梳理卷备份与还原工作流，并针对Cinder Backup Service的部分限制给出可参考的变通实现。压缩包共4个文件，包含1个Python主脚本、1个requirements依赖清单、1个README说明文档及.gitignore配置，整体约11KB，结构轻量，便于直接阅读脚本逻辑与依赖要求。已有315人学习下载，适合需要理解多租户备份场景的初中级云平台工程师参考。脚本覆盖多租户卷备份与还原、按原始卷ID或备份ID恢复、备份轮换与保留数量限制、保留原卷名称和描述、通过临时快照备份使用中卷，以及自动备份元数据的一次性导出与导入；管理员还可控制备份对租户的可见性并完成跨租户恢复，价值在于提供一套可拆解复用的Cinder备份流程设计样本。

1. 备份脚本不是备份策略，先看清 cinderback 补的是哪一环

凌晨两点被告警叫醒，某个业务卷被误删，快照只保了 24 小时，备份目录里空空如也——这种场景在云平台运维里一点都不少见。cinderback 就是在这个背景下被翻出来的一份 Python 写的 OpenStack Cinder 备份脚本助手：它不替代 Cinder 自带的 backup 服务，也不重写快照机制，而是把「建 backup、轮询状态、失败重试、超期清理」这套每天都要手工敲一遍的流程收进配置文件和调度逻辑里。适合两类人：一是已经在跑 Cinder、但备份还停留在手工执行命令或一个裸 cron 上，出问题时说不清到底有没有备成功的团队；二是刚接手云平台存储、想先跑通一条能验证、能恢复的最小备份链路的新人。后面按「链路是什么、怎么装怎么跑、调度怎么配、坑在哪、怎么证明备份能用」一路拆下去。

2. 拆开备份链路：cinderback 到底调了 Cinder 的哪几个接口

在动手装之前，得先弄明白脚本在 Cinder 这一侧到底做了什么。很多人把「备份」当成一个黑匣子，点一下按钮就以为万事大吉，结果真到恢复时才发现增量链断了、属主不对、卷类型不存在。cinderback 的价值恰恰是把这条链路上的每一步显式化，所以先把它调用的接口和语义理清楚，后面看配置项才不会有玄学感。

2.1 全量、增量与快照：三种备份语义先分清

Cinder 的 backup 本质上是对卷数据做一次搬运，落到后端存储（对象存储或 NFS 之类）上，同时把元数据写进数据库。脚本层面能控制的主要是三个开关：是不是增量、要不要走快照、失败时是否强制。这三个开关组合出来的行为差异很大，配错了不是报错，而是「看起来备了、其实不能用」。

选型上我一般这么定：数据库类卷全部走「快照 + 全量」，每天一次；普通文件盘走「快照 + 增量」，每小时或每四小时一次；每周固定做一次全量作为增量链的新锚点。增量不是免费的午餐，它把「备份能不能恢复」这个问题从单点变成了链式依赖，后面第 5 章会专门说这个坑。

提示：增量备份的第一份必须是全量，且父备份在子备份有效期内不能删。清理策略如果只按时间一刀切，很容易把父备份先删掉，留下一个永远恢复不了的子备份。

2.2 用 Python 把从 backup-create 到状态收敛跑通

cinderback 的核心逻辑并不复杂：认证、发起备份、轮询状态、记账。下面这段是最小闭环，把它跑通，脚本里其余部分都只是在这个骨架上加调度和策略。用 keystoneauth1 拿会话、用 python-cinderclient 发请求，比直接手拼 REST 请求省事，也不需要自己处理 token 过期。

# backup_one.py —— 单卷备份的最小闭环，cinderback 内部大致就是这个骨架 import time from keystoneauth1 import loading, session from cinderclient import client as cinder_client # 1) 认证：密码插件，服务账号务必独立于业务项目 loader = loading.get_plugin_loader("password") auth = loader.load_from_options( auth_url="http://控制节点:5000/v3", username="backup_svc", password="从环境变量或密钥管理里取，别写死在文件里", user_domain_name="service", project_name="backup", project_domain_name="service", ) # timeout 传元组：(连接超时, 读取超时)，大卷的 backup-create 响应可能很慢 sess = session.Session(auth=auth, timeout=(10, 120)) # 2) 微版本 3 是当前 Cinder REST API 的主线，region 必须显式给 cinder = cinder_client.Client("3", session=sess, region_name="RegionOne") def create_backup(volume_id, name, incremental=False, from_snapshot=True): b = cinder.backups.create( volume_id, name=name, incremental=incremental, # 增量必须已有同卷的全量父备份 force=False, # 卷处于 in-use 时是否允许备份 snapshot=from_snapshot, # 走快照读数据，减少对业务的 IO 干扰 description="cinderback-daily", ) return b.id def wait_until_done(backup_id, timeout=3600, interval=15): deadline = time.time() + timeout while time.time() < deadline: b = cinder.backups.get(backup_id) if b.status == "available": return b if b.status in ("error", "error_restoring"): raise RuntimeError("backup %s 进入 %s 状态" % (backup_id, b.status)) time.sleep(interval) raise TimeoutError("backup %s 超时未收敛" % backup_id) if __name__ == "__main__": bid = create_backup("卷 UUID", "vol-demo-20250101-full", incremental=False) info = wait_until_done(bid) print(bid, info.size, info.status)

参数上值得说的是三处。incremental决定这次备份是否挂到上一份全量后面，配错了要么浪费空间、要么直接报没有可用的父备份；force在很多环境里默认关着，卷处于 in-use 且没有快照能力时会被 Cinder 直接拒掉，别急着打开，先确认后端驱动支不支持在线备份；timeout和interval决定轮询节奏，大卷（几百 GB 以上）跑一两个小时很正常，超时设太短会让脚本误判失败然后重跑，白占配额。

认证账号的权限也别随意放宽。备份服务账号只需要能读卷、能读写 backup 资源，不需要管理员全权；用管理员账号跑备份短期内最省事，但备份记录的属主会落在管理员项目下，后面普通项目做恢复会看不到自己的备份，这个坑在第 5 章还会提一次。

2.3 台账落在本地：状态机之外的第二个真相源

Cinder 数据库里当然有 backup 记录，但脚本层还需要一份自己的台账。原因很实际：查「这个卷最近七天有没有成功备过」这种问题，走 API 全量拉一遍再过滤，卷多了以后又慢又容易被限流；更重要的是，脚本需要记住哪一份是父备份、哪一份是它的子增量，而 Cinder 侧的parent_id字段在某些驱动实现里并不可靠。

常见做法是在本地放一个 SQLite，字段大致是：卷 UUID、备份 UUID、类型（full / incr）、父备份 UUID、发起时间、结束时间、大小、最终状态、后端位置。写入时机放在状态收敛之后，也就是确认available才落「成功」，error落「失败」并把异常码一起写进去。这样排查的时候一条 SQL 就能回答「昨天哪些卷没备成功」，不用翻日志。

还有一个细节：状态字段只能告诉你「Cinder 认为它成了」，不能告诉你「数据是完整的」。判断后者只能靠抽样恢复，这一点放到最后一章展开。

3. 装好并跑通第一条：鉴权、配置与 dry-run 三件事

cinderback 这类脚本助手最容易翻车的地方不在代码，而在环境。Python 依赖版本不对、鉴权文件放错位置、dry-run 当成真跑，这三件事任意一个出问题，第一次执行就会留下脏数据。所以第一次上手，我建议严格按三步走：先确认依赖和目录约定，再把鉴权跑通，最后用 dry-run 看它准备干什么。

3.1 依赖与目录约定

Python 版本别用系统自带的老版本，3.9 以上比较稳妥，keystoneauth1 和 python-cinderclient 的新版本对旧解释器支持已经不太好。虚拟环境是必须的，别直接往系统 site-packages 里装，控制节点上跑的组件太多，版本冲突起来很难查。

# 1) 建虚拟环境，目录按自己的运维规范放 python3 -m venv /opt/cinderback/venv /opt/cinderback/venv/bin/pip install --upgrade pip /opt/cinderback/venv/bin/pip install \ keystoneauth1 python-cinderclient pyyaml retrying # 2) 目录约定：配置、日志、状态三者分离 mkdir -p /etc/cinderback /var/log/cinderback /var/lib/cinderback chown -R backup:backup /var/log/cinderback /var/lib/cinderback chmod 750 /etc/cinderback # 3) 冒烟测试：只验证能不能连上，不发起任何写操作 /opt/cinderback/venv/bin/python -c " from keystoneauth1 import loading, session from cinderclient import client loader = loading.get_plugin_loader('password') auth = loader.load_from_options(auth_url='http://控制节点:5000/v3', username='backup_svc', password='***', user_domain_name='service', project_name='backup', project_domain_name='service') c = client.Client('3', session=session.Session(auth=auth), region_name='RegionOne') print('volumes:', len(list(c.volumes.list()))) print('backups:', len(list(c.backups.list()))) "

目录分离看着是小事，实际影响排查效率。日志和状态库放同一个目录，日志轮转一执行，状态库有可能被一起动到；配置目录权限放大到 755，里面有服务账号密码就等于把凭据公开了。上面给的是 750，属于够用又不至于过宽的范围。

3.2 鉴权：环境变量、clouds.yaml 还是显式配置

鉴权信息的来源一般有三种：OpenStack 标准的环境变量、clouds.yaml、或者脚本自己的配置文件里显式写。三种都能用，我倾向在自动化场景里用「clouds.yaml + 环境变量指定 profile」，理由是配置集中、改一处所有脚本生效，而且文件权限好控制。

# /etc/cinderback/clouds.yaml，权限建议 600，属主 backup clouds: backup: auth: auth_url: http://控制节点:5000/v3 username: backup_svc password: 从密钥管理注入，不要提交到版本库 project_name: backup project_domain_name: service user_domain_name: service region_name: RegionOne interface: internal identity_api_version: 3

对应地把环境变量设成OS_CLIENT_CONFIG_FILE=/etc/cinderback/clouds.yaml和OS_CLOUD=backup，脚本侧直接loading.get_plugin_loader之外改用os_client_config或keystoneauth1.loading.load_from_options读取即可。注意interface这一项：控制节点上如果 internal 和 public 端点都在，脚本走 internal 更稳，也省掉一次外网绕行；填错的表现是连接超时，而不是认证失败，容易被误判成网络问题。

口令管理上，血泪经验是别把明文密码写进 cron 行里。cron 的进程命令行对同机所有用户可见，ps一敲什么都看得见。要么用 clouds.yaml 加 600 权限，要么用 systemd 的EnvironmentFile=指向一个 600 的文件，后者还能顺带解决环境变量不继承的问题。

3.3 先 dry-run 再真跑

第一次执行绝对不要直接生产跑。cinderback 这类工具一般会提供 dry-run 或者--plan之类的开关，作用是把「准备对哪些卷、按什么顺序、发什么请求」打印出来而不真正下发。没有这个开关的版本，就自己加一个环境变量CINDERBACK_DRY_RUN=1的判断，在create_backup之前 return。

# 只打印计划，不发起任何 backup-create CINDERBACK_DRY_RUN=1 /opt/cinderback/venv/bin/python -m cinderback run \ --config /etc/cinderback/policy.yaml \ --log-file /var/log/cinderback/dryrun.log # 检查计划里三件事：卷数量对不对、全量/增量标记对不对、保留策略会不会立刻删数据 grep -c "PLAN backup" /var/log/cinderback/dryrun.log grep "incremental=true" /var/log/cinderback/dryrun.log | head grep "PLAN delete" /var/log/cinderback/dryrun.log | head

dry-run 的日志要重点看第三项。很多脚本第一次跑的时候，因为本地台账是空的，会把「保留策略」判定成「所有备份都超期」，于是刚建完就开始删——这种情况在真实环境里真的会出现一次，删的还是刚备好的那一份。上线前一定要确认清理逻辑对「本次新建的备份」有豁免，或者干脆第一次只跑备份、把清理开关关掉。

真跑的时候先挑一个测试卷，不要一上来就全量。选一个 10G 左右的空盘，跑一次全量，等它到available，看一眼耗时和大小比例；再跑一次增量，确认父备份被正确识别。这两步通过，说明链路基本通了，再扩到生产卷。

4. 调度与保留：把 cron 换成可观测的批量任务

脚本能单跑之后，下一个问题是「谁来按时按点地跑，以及跑完之后怎么收尾」。用 cron 加一个 Python 脚本是能用的，但一旦卷的数量上去，cron 就变成了新的黑匣子：不知道这一轮跑了多少、失败了几个、下一轮会不会和上一轮撞上。所以调度和保留策略最好一起设计。

4.1 策略表怎么配：卷、周期、保留份数

把「哪些卷、多久备一次、留几份、全量间隔多少」写进 YAML，比在代码里写 if-else 好维护得多。卷的匹配用标签而不是 UUID 列表，原因很实际：卷会新建，UUID 列表永远追不上，而标签在建卷流程里就能打上。

# /etc/cinderback/policy.yaml defaults: interval_hours: 6 # 默认每 6 小时一轮 incremental: true # 默认增量 from_snapshot: true # 默认走快照 full_every: 7 # 每 7 天做一次全量，重置增量链 keep: 14 # 每个卷保留 14 份可用备份 keep_full: 4 # 其中全量至少保留 4 份 concurrency: 3 # 同时进行的备份任务数 rules: - match: metadata.backup_policy: daily-db interval_hours: 24 incremental: false # 数据库卷只做全量，链路简单 keep: 7 - match: metadata.backup_policy: hourly-file interval_hours: 4 keep: 30 keep_full: 8

full_every这个字段容易被忽略，它决定了增量链有多长。链越长，恢复时要按顺序回放的备份越多，任何一环出错整条链都不可用；链太短，全量太密，后端容量又吃不消。我一般把链长控制在 7 到 14 份之间，超过就强制重开一条链。

keep_full和keep必须一起配。只配keep，清理时可能把仅有的全量删掉、留下十几个增量，看着备份数量不少，实际一个都恢复不了。只配keep_full，容量会慢慢涨上去。两个一起卡，才能同时控制成本和可恢复性。

注意：清理策略的执行顺序一定是「先建后删」。反过来的话，某一轮备份失败时会先删掉旧备份、又没建出新的，等于自断退路。

4.2 并发、限速与失败重试

卷一多，串行跑不完。一个 500G 的卷备份两小时，两百个卷排下来就是几天，策略根本走不完整。并发是必须的，但并发数不是越大越好：Cinder 的 backup 服务本身有 worker 数限制，后端对象存储也有带宽上限，并发开太大只会把队列堆满、超时率飙升。

# 调度骨架：线程池 + 信号量限流 + 单卷失败不中断整轮 from concurrent.futures import ThreadPoolExecutor, as_completed import threading, random, time _sem = threading.Semaphore(3) # 后端口径的硬限流，比 max_workers 更稳 def run_one(volume, policy): with _sem: for attempt in range(1, 4): try: bid = create_backup(volume.id, build_name(volume, policy), incremental=policy["incremental"]) return wait_until_done(bid, timeout=policy.get("timeout", 7200)) except Exception as e: # 指数退避 + 抖动，避免失败任务在同一秒集体重试 sleep = min(60, 2 ** attempt) + random.random() * 3 time.sleep(sleep) last = e return last with ThreadPoolExecutor(max_workers=6) as pool: futures = {pool.submit(run_one, v, p): v for v, p in plan} for f in as_completed(futures): record_result(futures[f], f.result()) # 无论成败都落台账

max_workers和信号量分开设，是我踩过的一个小坑：线程池大小决定脚本自己的并发上限，信号量决定打到后端的并发上限，两者分开之后，调整后端压力只需要改一个数字，不用动线程模型。重试次数给 3 次够了，超过说明不是偶发问题，继续重试只会放大压力。

调度器这根「发条」用 cron 还是 systemd timer 都行，我更偏向 systemd timer：日志进 journal、失败可以配OnFailure=、环境变量可以用EnvironmentFile=干净地注入。cron 的麻烦在于它不继承登录环境，OS_CLOUD忘了设就是一轮全失败，而失败往往只体现在脚本自己的日志里。

4.3 备份产物怎么验证，不只看状态

状态available只代表 Cinder 认为数据写完了。真正能证明备份可用的最小证据是三样：备份大小和卷大小比例合理、元数据里卷类型和可用区信息完整、抽样能恢复。前两样可以每轮自动查，第三样按周抽样。

# 每轮结束后的自检：比例异常和元数据缺失都要报出来 def selfcheck(volume, backup): ratio = backup.size / max(volume.size, 1) problems = [] if ratio < 0.3: problems.append("备份体积仅占源卷 %.0f%%，疑似只备了空数据" % (ratio * 100)) if not backup.availability_zone: problems.append("备份缺少可用区信息，跨可用区恢复会失败") if backup.status != "available": problems.append("最终状态为 %s" % backup.status) return problems

比例这一项听起来粗糙，但抓过真实问题：某次后端驱动升级之后，备份任务一直「成功」，体积却只有源卷的百分之几，原因是驱动把空块全跳过了而元数据没跟上，恢复出来是个空盘。这种问题状态字段永远看不出来。

5. 排查清单：五个把备份做成「假成功」的坑

下面这五条都是「日志没报错、状态是绿的、真恢复时发现不行」的类型，按出现频率排。每条按现象、原因、解决三段写，遇到相似的可以直接对号入座。

5.1 增量备份恢复报父备份不存在

现象：增量备份列表里状态全是available，恢复某一份时报找不到父备份，或者恢复到一半失败。

原因：清理策略按时间删掉了全量父备份，而子增量还在保留期内。Cinder 侧删父备份时不一定级联删子备份，也不一定拦住这次删除，于是留下了一条断链。另一个常见诱因是卷被删除后重建、UUID 变了，但本地台账还按旧 UUID 记着父子关系。

解决：清理逻辑里加一条硬约束——父备份只要还有未过期的子备份就不许删，必要时把父备份的保留期自动延长到子备份全部过期之后。台账里同时记录父备份 UUID 和卷 UUID，卷被删时把整条链标记为不可清理但也不再作为新链的锚点，等自然过期。

5.2 备份能建、恢复不了，报卷类型不存在

现象：backup-create一路顺利，backup-restore立刻失败，报 volume type 找不到。

原因：备份里记录的是源卷当时的卷类型，恢复时要按这个类型新建卷。如果这个卷类型后来被改名、删除，或者只在某个可用区存在，恢复就会卡住。跨可用区恢复时更常见，因为卷类型通常是按可用区隔离的。

解决：恢复前先查卷类型是否存在，不存在就在恢复命令里显式指定一个等价类型，而不是硬等默认值。备份元数据里把卷类型、可用区、QoS 关联都记进本地台账，恢复脚本读台账来决定目标参数，别只依赖 Cinder 侧那份记录。

5.3 用管理员账号跑备份，普通项目看不到自己的备份

现象：备份明明成功，业务项目里的人在自己项目下执行backup-list却看不到，以为没备上，重复触发了好几次。

原因：备份资源的属主是发起备份的项目，用管理员账号发起，属主就落到了管理员项目下。Cinder 默认按项目隔离，普通项目自然查不到。

解决：备份服务账号单独建一个，授到需要的项目上，用项目作用域的 token 发起备份；确实需要跨项目统一备份的，就在每个业务项目下各挂一个服务账号，靠 tag 区分。这件事没法靠事后改属主补救，只能在发起时就定下来。

5.4 定时任务时区不一致，导致重复跑和漏跑

现象：某天早上发现同一个卷有两份时间相近的全量备份，另一天又一份都没有。

原因：调度器里写的小时数是本地时间，容器或系统默认时区是 UTC，两边差 8 小时，落到「跨天」的那一小时就出现漂移。脚本里如果还用datetime.now()判断「今天备过没有」，判断结果会跟着漂。

解决：所有时间统一用 UTC 存储和比较，只在展示层转本地时区。台账里存 UTC 时间戳，策略里的interval_hours用时间差判断而不是「几点钟」，这样即使调度器漂了，也不会一天跑两次。

5.5 超时设太短，失败重试把配额打满

现象：备份队列里堆了几十个creating状态的任务，后端对象存储写入变慢，最后连正常的备份也超时。

原因：轮询超时设得比大卷实际耗时短，脚本判定失败后自动重试，而前一次的任务其实还在后端跑。几次重试下来，同一批卷在队列里叠了好几份任务，配额和后端带宽一起被打满。

解决：轮询超时按卷大小动态算，比如每 100G 给 1800 秒再加一个固定余量；重试前先查这个卷有没有creating状态的备份，有就跳过。另外给备份服务配一个并发上限，超限直接排队等下一轮，不要在脚本里无脑堆线程。

6. 恢复演练：把「有备份」变成「能恢复」

备份做得多漂亮都不算数，只有恢复成功一次才算。我现在的习惯是每周抽一个卷做恢复演练，流程固定：从台账里挑一份最新的全量，恢复到新卷，挂到测试实例上做文件系统检查，最后把新卷删掉。整个过程自动化，失败直接告警。

恢复本身不复杂，关键是参数要拎清楚。backup-restore支持指定目标卷、卷类型、可用区，不指定就按备份里的元数据新建。

# restore_drill.py —— 恢复到新卷并做基础校验 from cinderclient import client as cinder_client def restore_to_new(backup_id, volume_type="ssd-test", az="az-test"): b = cinder.backups.get(backup_id) # 恢复前先确认卷类型存在，省得白跑一次 types = {t.name for t in cinder.volume_types.list()} assert volume_type in types, "卷类型 %s 不存在" % volume_type vol = cinder.backups.restore( b.id, volume_id=None, # None 表示新建卷，不要填已有卷 name="drill-%s" % b.id[:8], volume_type=volume_type, availability_zone=az, ) return vol.id def verify(vol_id, expect_min_gb): v = cinder.volumes.get(vol_id) ok = v.status == "available" and v.size >= expect_min_gb # 真实校验还得挂载后看文件系统，这一步交给外部脚本跑 fsck / 校验文件清单 return ok, v.status, v.size

演练要检查的项我固定成一张表，每次照着打勾，不做主观判断：

抽样文件校验这一步最费时间，也最值得。做法很简单：在源卷上留一个固定大小（比如 1G）的校验文件，备份前算好 sha256 记进台账，恢复后在新卷上重算一遍比对。文件不需要很大，但必须是写入过的真实数据，不能是稀疏文件，否则校验通过也说明不了问题。

演练出的卷一定要删干净，不然一个月下来测试项目里堆几十个卷，配额悄悄见底，下一次真恢复就卡在配额上——这个坑我踩过一次，之后再忙都会在脚本最后加一步清理，失败也清理。

从那以后我每上一套新的备份策略，都强制先拿一个 10G 的测试卷走一遍全量、一次增量、一次恢复，三步全过才往生产卷推。备份这件事没有中间状态，要么能恢复，要么等于没有。希望帮到你。

本文还有配套的精品资源，点击获取