台账数据未备份问题整改措施报告.docxVIP

台账数据未备份问题整改措施报告

序号

整改环节

现状描述

根因剖析

风险等级

整改目标

具体措施

责任岗位

完成时限

验收标准

佐证材料

备注

1

制度层面

《数据备份管理办法》V2.1仅覆盖财务、人力、生产三大系统，台账类数据未被纳入强制备份清单，导致“无制度可依”。

制度起草时以“业务连续性”为导向，未将“台账”视为关键信息资产；评审阶段缺少档案、审计、合规三方参与。

高

7日内完成制度升版，将台账数据写入“强制备份”章节，并明确RPO≤4h、RTO≤2h。

①由信息部牵头，档案室、审计部、法务部、财务部四方成立“制度修订小组”，采用“场景推演”方法，模拟台账丢失对年报、审计、税务稽查的影响；②新增第5.3.2条“台账数据备份策略”，按产生频率将台账分为高频（T+0）、中频（T+7）、低频（T+30）三类，分别对应实时快照、每日增量、每月全量；③制度会签前，使用“红线检查”工具扫描文本，确保无遗漏、无冲突；④通过OA发布，同步在知识库建立制度解读图文，阅读量纳入部门KPI。

信息部经理A

2024-05-15

①制度升版文件编号：IT-IM-2024-05；②四方会签记录完整；③红线报告无高危条款。

制度升版PDF、会签单、红线扫描报告

无

2

技术层面

台账数据库部署在2016版MySQL5.5，仅开启binlog，未启用半同步复制，无独立备份节点；备份脚本由DBA手工维护，存在14个月未更新记录。

早期服务器资源紧张，未规划独立备份节点；DBA离职交接时未将脚本纳入Git，导致后续无人敢改。

高

3日内完成“热备+冷备”双轨架构，7日内实现备份自动化、可观测、可演练。

①新购两台2U服务器，部署MySQL8.0主从+半同步复制，使用Orchestrator做高可用切换；②采用xtrabackup每日02:00全量、每30分钟增量，备份文件推送到MinIO对象存储（三副本、纠删码）；③备份脚本纳入GitLab，合并请求需经两名以上DBAReview；④部署Prometheus+Granfana，监控备份耗时、文件大小、校验值；⑤每周四凌晨进行“备份恢复演练”，随机抽取1套台账库恢复到隔离环境，运行数据校验SQL不少于50条，演练报告发送给审计部。

数据库团队B

2024-05-10

①RPO≤4h、RTO≤2h达成；②演练连续3次零失败；③监控大屏绿色7×24。

架构图、Prometheus截图、演练报告

无

3

台账梳理

目前台账散落在5套业务系统、8个Excel共享盘、3名专员本地电脑，无统一台账目录，无法评估备份完整率。

历史上“先业务、后治理”，台账由各部门自发维护；缺少数据Owner概念。

中

5日内完成“台账数据资产清单”100%盘点，并建立“数据Owner”机制。

①使用自研“爬虫+正则”工具扫描网段，自动发现MySQL、SQLServer、Excel、CSV中含“台账”关键字的数据源；②组织4场“台账认领”工作坊，业务科长现场签字确认Owner；③对Excel文件统一迁移至受控文档库，启用版本号+MD5校验；④建立“台账数据地图”看板，实时显示库表数量、备份状态、Owner联系方式；⑤对本地电脑文件使用RPA每日18:00强制同步到加密盘，未同步即弹窗提醒。

数据治理组C

2024-05-12

①清单覆盖率100%；②无Owner台账为0；③数据地图更新延迟≤5min。

台账清单Excel、数据地图截图、Owner签字表

无

4

备份验证

过去12个月仅做“备份成功”检查，未做“恢复可用”验证，导致3月28日发现2月备份包因字符集缺陷无法恢复。

验证流程缺失；验证环境共用性能测试库，数据污染风险高，DBA不愿频繁验证。

高

建立“备份恢复验证”闭环，问题不过夜。

①单独拉起1套KVM虚拟化验证环境，网络隔离，配置16C/64G/2TNVMe，可并发验证6套实例；②制定40条数据校验SQL，覆盖余额、科目、数量、税率、时间戳5大维度；③验证失败即触发Jira紧急工单，30分钟内指派DBA，2小时内修复或重备；④每月首个工作日由审计部随机抽检1份备份包，恢复后出具《数据一致性报告》；⑤验证结果纳入DBA季度绩效，出现1次“不可恢复”扣减20%奖金。

数据库团队B

2024-05-08

①连续30天验证零失败；②审计抽检合格率100%。

校验SQL脚本、一致性报告、绩效记录

无

5

权限管控

台账库账号共