影刀RPA 数据备份验证自动检查备份文件完整性作者林焱什么情况用什么DBA每天做数据库备份自以为万事大吉。真等哪天数据库崩了打开备份文件一看——空的或者只备份了一半。这不是段子是真事。备份的价值在于能恢复。而能恢复的前提是备份文件是完整的、可用的。影刀RPA可以自动做备份验证检查备份文件是否存在 → 检查文件大小是否异常 → 尝试恢复到一个测试环境 → 验证恢复后的数据是否完整。适合场景每天自动检查昨晚的数据库备份每周做一次完整的备份恢复演练监控备份文件大小趋势突然变小可能备份失败验证异地备份是否同步成功店群矩阵自动化突破运营极限怎么做第一步检查备份文件影刀操作步骤1. 【遍历文件夹】遍历 D:\db_backups\ 目录 2. 对每个备份文件 - 【获取文件大小】记录文件大小 - 【获取文件修改时间】检查是否在今天凌晨生成 - 对比和昨天的备份大小是否差异超过30%importosfromdatetimeimportdatetime backup_dirrD:\db_backupsexpected_datedatetime.now().strftime(%Y%m%d)issues[]forfinos.listdir(backup_dir):pathos.path.join(backup_dir,f)sizeos.path.getsize(path)# 检查1文件大小是否0ifsize0:issues.append(f文件为空:{f})# 检查2文件日期是否匹配file_datedatetime.fromtimestamp(os.path.getmtime(path)).strftime(%Y%m%d)iffile_date!expected_date:issues.append(f文件日期不匹配:{f}(期望{expected_date}实际{file_date}))# 检查3大小波动是否异常对比历史# ...下一段展开ifissues:alert备份异常\n\n.join(issues)# 发送告警第二步大小波动检测备份文件大小突然减少可能意味着备份不完整。importjson# 读取历史大小记录withopen(rD:\backup_history.json,r)asf:historyjson.load(f)forf_name,filesizeincurrent_backups.items():iff_nameinhistory:last_sizehistory[f_name][-1]# 上一次的大小change_pctabs(filesize-last_size)/last_size*100ifchange_pct30:issues.append(f{f_name}: 大小波动{change_pct:.1f}% ({last_size//1024//1024}MB →{filesize//1024//1024}MB))# 更新历史记录forf_name,filesizeincurrent_backups.items():history.setdefault(f_name,[]).append(filesize)history[f_name]history[f_name][-30:]# 只保留最近30天withopen(rD:\backup_history.json,w)asf:json.dump(history,f)第三步恢复演练这是最关键的一步——真正尝试恢复备份到测试库。影刀操作步骤1. 【执行命令行】在测试服务器上恢复备份 # MySQL mysql -h test-db -u root -p test_db backup.sql # PostgreSQL pg_restore -h test-db -U postgres -d test_db backup.dump 2. 【执行命令行】检查恢复结果 mysql -h test-db -u root -e SELECT COUNT(*) FROM users test_db 3. 【读取输出】对比生产库和测试库的行数是否在合理范围importsubprocessdefrestore_and_verify(backup_file,test_db_config):# 恢复cmdfmysql -h{test_db_config[host]}-u{test_db_config[user]}\f-p{test_db_config[password]}{test_db_config[db]}{backup_file}resultsubprocess.run(cmd,shellTrue,capture_outputTrue,timeout600)ifresult.returncode!0:returnFalse,f恢复失败:{result.stderr.decode()}# 验证核心表记录数tables[users,orders,products]fortableintables:count_cmdfmysql -h{test_db_config[host]}-u{test_db_config[user]}\f-p{test_db_config[password]}-e SELECT COUNT(*) FROM{table}{test_db_config[db]}count_resultsubprocess.run(count_cmd,shellTrue,capture_outputTrue)countint(count_result.stdout.decode().strip().split(\n)[1])ifcount0:returnFalse,f表{table}恢复后为空returnTrue,恢复验证通过第四步日报生成reportf # 数据备份验证日报 -{date}## 备份文件检查 - 应备份文件数{expected_count}- 实际文件数{actual_count}- 异常文件{len(issues)}个 ## 大小趋势{format_size_trends()}## 恢复演练 - 演练数据库test_db - 恢复状态{通过ifrestore_okelse失败}- 核心表记录数正常 ## 异地备份同步 - 状态{remote_status}有什么坑temu店群自动化报活动案例坑1恢复演练的环境冲突如果多个人/多个定时任务同时往测试库恢复数据互相覆盖。解决给每次恢复分配唯一的数据库名如test_db_20260628。坑2备份验证本身消耗资源大数据库恢复可能跑半小时占用测试服务器CPU和IO。限制恢复频率——每天检查文件大小每周做一次完整恢复演练即可。坑3备份文件命名不统一有的叫backup_20260628.sql有的叫db_dump_0628.sql.gz。用正则匹配日期re.search(r(\d{8}|\d{4}[-_]\d{2}[-_]\d{2}), filename)。坑4只验证了结构没验证内容恢复成功但某些字段是null——可能原备份就有问题。验证策略要分层L1每日检查文件存在大小合理L2每周完整恢复核心表count检查L3每月抽样比对生产库和恢复库的数据内容总结备份没验证等于没备份。至少做到每天检查文件在不在、每周试一次恢复自动化之后成本很低但收益巨大。
