计算机化系统验证（CSV）中的数据备份与恢复（DBR）

计算机化系统验证（CSV）中的数据备份与恢复（DBR）文件类型验证技术指南适用领域GMP／GxP计算机化系统适用系统LIMS、MES、SCADA、色谱工作站、电子记录系统等编制日期2026年11月法规引用更正（写作前必读）一、欧盟GMP附录11的备份条款是第7.2条（数据存储，DataStorage），不是常被误写的“4.7”。原文表述为：应定期对全部相关数据进行备份；备份数据的完整性与准确性、以及数据恢复能力，应在验证期间检查并定期监控。同一节的7.1条另要求：数据应以物理与电子手段防止损坏，存储的数据应检查可及性、可读性与准确性，保存期内应保证可访问。二、21CFRPart11没有独立的“备份”条款，不能写成“Part11要求备份”。其相关要求体现在§11.10(c)（记录保护，确保在保存期内准确、随时可检索）、§11.10(e)（审计追踪）、§11.10(f)（运行检查的有效性）与§11.300（标识码与口令控制）。三、中国侧最直接的依据是《药品记录与数据管理要求（试行）》（国家药监局公告2020年第74号，2020-06-24发布，2020-12-01施行）：系统生成的数据应定期备份，备份与恢复流程必须经过验证，数据的备份与删除应有相应记录；电子数据的元数据应保存与备份，备份及恢复流程必须经过验证。此外，《药品生产质量管理规范（2010年修订）》附录《计算机化系统》（2015-12-01实施）要求建立数据备份与恢复的操作规程，备份数据存放于单独、安全的地点，保存时间至少满足记录保存时限要求。四、欧盟正在修订附录11，公开征求意见稿已把恢复测试单列条款（16.6），方向是基于风险在验证期间实施、并在备份或恢复流程与工具变更后再次实施，且恢复测试须记录并核验数据在系统中可访问。该稿尚未定稿，本文件所依据的仍是现行7.2条。一、目的与范围（一）目的。确认本计算机化系统的备份策略、备份作业、存储介质与恢复流程可靠可控，证明GxP电子数据、审计追踪与元数据能够被完整、准确、可追溯地恢复，并建立周期性恢复测试、偏差处理与年度回顾机制。核心判断标准只有一句话：备份做成了，不等于数据能恢复。验证要回答的是后者。（二）范围。纳入验证的是系统内全部GxP相关电子原始数据、数据库、审计追踪、配置参数、用户权限与电子签名记录。以下内容可经风险评估后排除：可重新生成的非GxP报表、临时缓存、系统运行日志（但故障排查所需日志应单独保留）。排除项必须在风险评估报告中逐项说明理由。（三）环境要求。所有恢复测试须在独立隔离的沙箱或测试环境执行，环境版本、补丁、字符集、时区与生产保持一致。禁止在生产环境做恢复验证——这是检查中最容易被判为严重缺陷的做法。二、法规依据与条款对应法规文件条款对DBR的具体要求EUGMP附录11（计算机化系统）第7.1条数据以防损坏；存储数据检查可及性、可读性、准确性；保存期内保证可访问同上第7.2条定期备份全部相关数据；备份的完整性与准确性、恢复能力须在验证中检查并定期监控《药品记录与数据管理要求（试行）》电子记录管理要求定期备份；备份与恢复流程必须经过验证；备份与删除应有记录同上数据管理要求电子数据及元数据须保存与备份；备份及恢复流程必须经过验证GMP（2010修订）附录《计算机化系统》数据管理相关条款建立备份与恢复操作规程；备份存放于单独、安全的地点；保存期满足记录保存时限21CFRPart11§11.10(c)、(e)、(f)、§11.300记录保护与随时可检索、审计追踪、运行检查、访问控制（无独立备份条款）PIC/SPI011（计算机化系统良好实践）数据管理与业务连续性章节备份与恢复的程序化要求，灾难恢复演练术语与数据完整性判定沿用ALCOA+：可归因、清晰、同步、原始、准确，加完整、一致、持久、可获得。备份恢复环节最常被破坏的是“完整”“持久”“可获得”三项，验证设计应重点针对这三项。三、风险评估与分级（验证的前置条件）DBR的测试深度、频次与RTO／RPO目标，必须由风险评估确定，不能各系统套用同一套模板。建议按数据影响度分为三级：分级典型系统RPORTO恢复测试频次Tier1MES、LIMS、色谱工作站等直接影响产品放行的系统≤15min～1h≤2～4h每季度一次Tier2文档管理、培训管理、设备管理系统≤24h≤8～24h每半年一次Tier3办公辅助、非GxP数据分析工具≤72h≤72h年度抽查风险评估须识别的典型失效模式：备份任务失败而无告警、备份介质损坏或不可读、备份链断裂、审计追踪未纳入备份、恢复后数据不一致、备份与生产同机房、备份未加密、备份权限失控、恢复操作覆盖生产数据。每一项失效模式都要对应到一条验证测试或一项控制措施，否则风险评估与验证方案是两张皮。四、备份策略设计（一）备份类型与调度全量备份：完整数据库或文件集，作为基准，建议每周一次。增量备份：仅备份上次备份后的变更，每日执行；恢复依赖完整备份链，链上任一环损坏即不可用，因此必须配套链完整性校验。差异备份：备份自基准全量以来的变更，恢复只需全量加最近一份差异，恢复速度快于增量链。事务日志备份：支持时间点恢复（PITR），间隔15～60min，是Tier1系统满足RPO≤15min的必要条件。配置备份：系统参数、用户与权限、审计追踪开关、方法文件、模板、计算公式、限值设定。这一项最易被漏：只备数据库不备配置，恢复后系统“能用但不对”。（二）3-2-1原则与保留期建议执行3-2-1原则：至少3份副本、2种不同介质、1份异地存放（不同建筑或不同园区），以规避火灾、水灾与勒索软件同时损坏。异地必须是真的异地：同机房不同机柜不算。保留期不得短于记录保存期限要求。药品批记录通常需保存至有效期后一年，其余GxP数据按企业文件保存规程执行；备份保留期应在SOP中写明并可由台账验证。（三）介质与安全控制介质受控编号、台账登记、出入库双人复核；离线介质存放于受控环境，防磁、防潮、防高温。传输与存储加密（建议AES-256）；密钥管理与介质分离存放，避免“连介质带密钥一起丢”。每份备份生成哈希校验值（SHA-256），备份完成后自动与源端比对，作为完整性证据留存。备份访问权限最小化，仅授权管理员可读取；所有备份、恢复、介质出入库操作均记入审计追踪或操作日志。定期巡检介质可读性，历史介质按比例抽查读取与哈希校验。五、DBR在验证生命周期中的位置DBR不是独立于4Q之外的另一套验证，而是分布在其中的一个模块：IQ（安装确认）：备份软件与代理安装、存储挂载、目录与权限、加密证书、哈希校验脚本部署、告警通道（邮件／短信／平台）配置确认。OQ（运行确认）：执行本文件第六章的测试集，这是DBR的核心证据来源。PQ（性能确认）：按SOP常态化执行备份，周期性恢复测试，历史介质抽查，纳入年度系统回顾。变更控制：系统升级、数据库版本变更、备份工具或存储架构更换、迁移、扩容，均触发DBR再验证，范围由变更风险评估确定。六、OQ测试用例测试前须预置一套已知数据集，并形成基准核对清单：记录条数、关键数值、样品与批号、时间戳、审计追踪条目数、用户与权限清单、方法模板版本。所有测试留存截图、日志、哈希值与计时记录，作为原始记录归档。编号测试场景测试要点接受标准T-01备份任务自动执行与完整性校验按调度执行全量、增量、日志、配置备份；导出备份日志；计算并比对SHA-256任务无报错；备份包大小合理；哈希与源端一致；备份操作入审计追踪T-02标准恢复（核心用例）在隔离环境按全量加增量／日志链恢复；记录起止时间并计算实测RTO；按第七章清单核对恢复成功；数据与基准一致；审计追踪完整可查；实测RTO达标；业务流程可走通T-03时间点恢复（PITR）恢复到故障发生前的指定时刻精准恢复到指定时间点；此前数据完整，之后数据不出现T-04备份链断裂（负面测试）人为损坏或移除链中一份增量备份后尝试恢复恢复中止并明确报错；不得静默恢复出错误数据T-05异地介质恢复模拟本地机房不可用，改用异地离线介质解密与恢复异地介质可读、可解密、可恢复；数据完整性符合要求T-06备份失败告警人为制造失败条件（空间满、权限失效、网络中断）按预定方式触发告警；告警记录可追溯并通知责任人T-07历史介质可读性抽查（PQ）调取存放超过6个月的介质做读取与哈希校验读取成功；哈希一致；无静默损坏关于T-04的说明：这是最容易被忽略、也最能暴露设计缺陷的一项。若恢复工具在链不完整时仍能“恢复”出一份看似正常的数据库，问题比报错严重得多——它意味着任何一次介质损坏都可能悄悄产出错误数据。测试必须确认工具会拦住这种情况。七、恢复后核对清单恢复成功不等于恢复正确。下表按数据完整性维度逐项核对，建议直接做成《恢复测试记录表》的核对栏：核对对象核对内容对应完整性要素业务数据记录总数、样品与批号、检测结果、原始图谱、关键数值准确、完整元数据创建时间、修改人、设备编号、软件版本、数据文件与记录的关联关系可归因、原始、一致审计追踪恢复后连续、不可修改、时间戳正确；条目数不少于基准；历史追踪未被截断完整、持久用户与权限账户、角色、权限分配、电子签名配置与基准一致可归因、一致配置与方法系统参数、方法文件、模板、计算公式、限值准确、一致字符集与时区中文字符无乱码；时区与生产一致，时间戳不偏移清晰、准确哈希与日志恢复前后哈希比对记录、恢复操作自身是否被记录持久、可获得其中审计追踪与元数据是检查缺陷的高发点：不少企业只核对业务记录条数，恢复后审计追踪被重置或时间戳错位，这属于数据完整性缺陷，不是技术小问题。八、交付物清单数据备份与恢复风险评估报告（含分级、RTO／RPO依据、失效模式与控制措施对应关系）。《数据备份与恢复管理规程》：备份调度、介质管理、恢复申请与审批、告警处置、异地存放要求。CSV验证方案（DBR作为其中章节，含T-01～T-07测试脚本）。原始记录：备份日志、截图、哈希校验记录、RTO计时记录、恢复后核对表。验证报告（结论、偏差与CAPA、遗留风险说明）。周期性恢复测试计划与年度系统回顾报告。业务连续性与灾难恢复预案（DRP），与DBR配套，明确真实灾难下的决策链与通报机制。备份介质台账与出入库记录、加密密钥管理记录。九、常见缺陷与规避只做备份、从不做恢复测试。最普遍的问题：备份成功率100%，但从未验证可恢复性，直接违反附录11第7.2条。在生产环境做恢复验证。一旦覆盖真实数据即为数据丢失事件，且本身不合法。恢复后只核对数据、不核对审计追踪。审计追踪是检查重点，恢复后的连续性与完整性必须留证。备份与生产同机房、无异地副本。看似有备份，实则单点风险未解除。无哈希校验。无法证明备份包未发生静默损坏，也无法证明恢复的是同一份数据。未区分GxP与非GxP数据。备份范围过度或不足，两者都会在检查中被质疑。RTO／RPO只写在方案里，没有实测记录。目标值必须由测试数据支撑。备份失败无告警，长期失败无人发现。应验证告警通道本身有效（T-06）。忽略配置备份。数据库恢复了，权限与方法文件却是默认值，系统“能启动但不可用”。恢复流程无审批、无记录。恢复是对生产数据的写操作，须有申请、审批、执行、复核四个环节并留痕。十、持续维护与再验证触发周期性测试：Tier1每季度、Tier2每半年执行一次完整恢复测试；Tier3年度抽查。变更触发：系统或数据库版本升级、补丁重大变更、备份工具更换、存储架构调整、系统迁移、机房搬迁、加密方案调整，均须在变更后完成恢复测试。年度回顾：汇总备份成功率、恢复测试结果、告警次数与处置、偏差与CAPA、介质状态、留存期合规性，形成系统回顾报告。关注法规动向：附录11修订定稿后，恢复测试的频次依据可能由“定期监控”调整为“基于风险＋变更触发”，届时需同步修订SOP与验证策略，不宜提前按草案执行而放弃现行要求。附：建议配套模板附件A：备份台账（介质编号、备份类型、时间、大小、哈希值、存放位置、保管人）。附件B：恢复测试记录表（含RTO计时、哈希核对、第七章全部核对项）。附件C：备份失败告警处置流程与升级路径。附件D：恢复申请与审批单（含影响评估、QA会签）。附件E：偏差与CAPA记录表。资料来源\h欧盟委员会：EUGMP附录11《计算机化系统》第7.1、7.2条原