15年云计算、大数据项目经验,主导多个迁云、搬站等政企行业大型项目。
导 读
最近,某公司“删库事件”轰动一时。由于员工恶意破坏线上生产环境及数据,导致公司系统服务不可用,给商家经营造成了严重影响。经过七天七夜的努力,被删除的数据已经全面找回,该公司也准备了1.5亿元赔付金以弥补客户的损失。
- 首先就明确了各运维岗位职责,各岗位权限最小化,最大化保障数据安全性,一旦发生数据安全事件,将损失降到最小。
- 其次单独的备份管理员存在,一旦生产库发生突发恶性事件,生产员工无法触碰备份环境,保障了备份数据的安全性。
- 同时在执行过程中有密码定期修改、执行计划等过程性措施,防止密码泄露和也保障了备份的完整性,一旦发生问题可以启动紧急事件流程,最小时间内恢复业务运行。
- 在传统的数据库架构上,灾备策略并没有充分考虑物理或逻辑损坏的问题,在特殊情况下无法做到快速恢复数据或根本无法恢复数据;
- 受限于技术能力和成本,大部分企业是通过逻辑或物理全备的方式进行备份,这本身并没有多大的问题;
- 但是在需要恢复的时候,必须考虑:逻辑备份只能恢复到备份时间点的数据,不能进行一致性恢复;物理全备份随着数据量的增长,备份的时间会加长,相应的数据恢复速度会降低,故障恢复时间就难以预估。
- 灾备架构是在业务规划时不得不考虑的一个问题,但大部分企业会停留在一主一备、准实时数据同步的场景;在数据库逻辑故障的情况下,这个架构没有任何优势。
- 备份集的存储策略同样重要,保留多久的数据算合理?保存在哪?需要多少的存储资源?备份集是否有效?谁负责管理这些备份集?
数据同步主备架构,避免主机硬件故障带来的单点问题Oracle DG 、MySQL standby、MSSQL 订阅……
数据延迟备份架构,避免主库错误逻辑变更导致数据不一致问题
Oracle DG: alter database recover ……delay 7200 ……
MySQL : CHANGE MASTER TO MASTER_DELAY = 3600
MongoDB: cfg.members[1].slaveDelay = 3600(严禁在线操作)
多地多中心、混合云灾备架构
物理备份:全备份、增量备份或差异备份,如5全备,1、3、4、6、7增量备份,2差异备份
Oracle RMAN、MySQL xtrabackup、Mongo oplog……
日志备份:Oracle archive log、MSSQL事务日志、MySQL binlog……
逻辑备份:重要的业务表逻辑备份
Oracle expdp、MySQL mydump、Mongo mongodump……
本地存储:本机分配备份盘,保留最新一份全备集合;上传所有备份集到本地存储设备
跨机房存储:本地备份后,通过专线上传到异地机房存储设备
云端存储:本地备份后,通过专线上传到阿里云对象存储OSS
备份存储多地存储,避免机房单点故障
设备分权限访问,避免人为故障,助力数据快速恢复
验证备份集可恢复、数据可用
收集恢复实施文档,故障恢复有文可依
全量+增量恢复演练
数据文件损坏恢复演练
数据库误操作恢复演练
主备环境failover恢复演练
……
配置数据库备份、存储策略
监控数据库运行、数据同步状态
监控备份是否正常执行
监控存储设备使用情况
短信、电话、钉钉、邮件告警
……