当前，数据安全受到多方面的威胁。有来自系统软硬件的非人为故障，有运维工程师的误操作，甚至是黑客或内部人员的恶意删除。2017年1月31日，全球最大的代码托管服务平台Gitlab由于工程师的误操作，删除了5000个项目和700个用户账号的数据，虽然多方补救，但部分数据最终没能恢复。近几年黑客入侵用户系统后加密磁盘，以此来勒索的事件也层出不穷。更有来自黑客或内部人员的恶意删除，导致业务的极大损失。
如何彻底杜绝此类风险，确保数据安全，需要全方位的技术保障措施：备份、反入侵、分权限管理、快速回档等技术手段都不可或缺，而且必须覆盖每一类存储产品。
UCloud作为业界领先的云服务商，提供了全面的各类存储产品，开发了完整和成熟的数据安全机制。并且在为数万家用户提供可靠线上服务的过程中，积累了丰富的经验。下文提到的数个案例，其实就发生在UCloud平台上。通过我们的产品和专业及时的服务，这些用户最终得以恢复数据，避免由此造成的损失。
一般地说，用户搭建数据库有如下三种方式：使用公有云提供的DB PaaS托管服务，如UCloud UDB，由云服务商来负责DB的搭建及运维；用户也可以使用公有云的云主机和云盘来自行搭建数据库；或者在私有云环境下搭建。在这三种情况下，UCloud都提供了专业的数据安全机制，来切实有效的保证用户的数据安全。
接下来将介绍UCloud针对数据库数据安全的七种“武器”。具体而言，本文主要回答如下三个问题：
1. 数据库的备份容灾机制如何完善？
2. 数据被破坏丢失后如何快速恢复？
3. 数据库运维人员的权限如何有效控制？
UDB PaaS托管服务
如果需要得到最专业的数据库安全服务，用户的首选就是云服务商提供的DB PaaS服务。譬如说，UDB是UCloud提供的云数据库服务，支持各种主流的数据库产品。自2013年上线以来，运营了数以万计的UDB实例。
UDB远远不只是帮用户搭建DB那么简单，事实上这部分功能只是UDB价值的冰山一角。UDB提供了完备的数据库搭建、运维、性能调优、资源扩缩容等服务。其高可用、高性能、便捷易用等特性帮助用户大量减轻了运维负担。同时，数据库团队还自研了分布式架构、读写分离、存储计算分离等特性，进一步提高云数据库的性能和可用性。在数据的备份恢复机制上，UDB提供自动备份、秒级恢复、监控告警、问题诊断等服务。
武器一：UDB备份机制
面对不可预测的误操作或者人为恶意操作，数据库自身的备份机制就显得尤为重要。UDB的备份机制具体如下：
（1）UDB的备份模式
a、自动备份每天自动进行一次备份（默认备份时间为00:00—06:00的某一整点），备份可以保存7天。备份模式包括物理备份和逻辑备份两种。
b、用户可以对某些关键时间点的重要数据进行手动备份，允许保留个数为3个。
**
（2）UDB备份文件存储**
a、备份文件存储在UCloud独立的备份资源池中，安全性有保障。
b、备份文件的副本始终保持多份异地冗余。
（3）备份文件转存
针对用户个性化的备份文件存储需求，UDB支持备份文件下载：
a、Web控制台或API支持下载备份文件（包括自动备份和手动备份）。
b、Web控制台或API支持下载二进制日志文件（MySQL的binlog） 用户在下载备份文件后，可转存到自有的存储系统或者UCloud平台上的存储类产品（UDisk、UFS、UFile等），理论上采用公有云存储产品更为安全可靠。
（4）备份成功率保障机制
a、UDB的自动备份具备有效的告警机制，如果备份失败，则会自动触发告警
b、UDB后台会定期进行备份成功率的巡检，通过SPT反馈备份情况给到用户。
武器二：数据恢复方案
针对误操作或者人为恶意造成的数据库删除，UDB提供了一系列数据恢复方案。
a、对UDB实例中的库做删除，比如drop/delete操作，可以从源实例通过回档功能恢复到操作的前一刻，回档到一个全新的实例。
b、UDB实例被删除后，它原先的备份将持续自动保留7天，7天内仍然可从备份恢复为一个全新实例。
c、出现最极端的情况，实例被删、备份文件全部被删，那该怎么办呢？UDB后端在一定有效期内仍然保留有操作当天的最新备份，应对该极端情况。由于这份备份是系统内部维护，用户并不能直接访问。所以即便发生运维人员恶意删除，此份备份依然存在，仍然可以使用该备份来数据恢复。
武器三：从本地备份到跨云备份
为了确保数据的绝对安全，必须做到数据的多份备份，可以从本地磁盘的多份备份到跨区域备份，甚至实现跨云平台的多云备份。
数据库数据可靠性受底层有效的RAID保护，实例级的冗余则包括主实例采用高可用架构，后端主备双节点，保证数据双份冗余。控制台一键创建从实例，主实例可以一主带N从，包括可用区级（主从在同可用区）和地域级（主从跨可用区），保证实例级冗余。
UCloud还提供数据传输产品UDTS，在数据库可靠性更高要求的场景，主实例可以通过UDTS搭建异地或者两地三中心的UDB集群架构，进一步保障数据安全。此外，UDTS也适用于多云部署的场景，其支持多种数据库类型、双向迁移的能力，可以帮助使用者将数据平滑地做跨云的迁移和备份。某电商便是借此实现了UCloud和T云之间的数据同步。
UDB数据恢复案例
场景一：数据库误变更
游戏行业业务变更快、变更多，是比较容易造成数据库误操作或者不当变更的情况，此时如何快速恢复到变更前状态就成为了棘手的问题。某游戏用户在版本发布时造成数据库的schema变更字段出错，发现出错时，已经对游戏服造成了巨大影响。此时，管理人员对影响的UDB实例做了一个回档操作，恢复至变更前一刻，精确到秒级，挽回了损失。再对源实例进行必要数据的导出，补偿到回档的新实例，避免数据丢失。
场景二：数据库误删除
在运维权限管理混乱时，安全性就存在巨大的隐患，任何人都有可能对核心资源进行不正当操作。某互联网App用户的运维人员由于看错信息，造成核心UDB实例误删除。因UDB实例会每天自动备份，此时管理人员在控制台找到UDB实例当天的最新备份，做了恢复操作，恢复为一个全新UDB实例，减少了损失。
场景三：数据库误回收
在生产环境里，最为担心的是资源的回收未及时发现，例如（1）运维人员在资源整合时，删除了某个数据库实例；（2）过期资源未及时续费被自动回收，事后过了很长时间才反应过来，但为时已晚。针对该场景，UDB实例后端在一定有效期内，仍然保留一份当天的最新备份，通过数据全量恢复的模式，帮助不少用户找回数据。
使用云主机自建DB
如果用户出于各种原因考虑，不愿意使用公有云的DB PaaS托管服务，而是希望使用公有云IaaS产品来自行搭建DB。UCloud同样提供了专业的数据安全产品，那就是数据方舟。方舟是当前业界独一无二的数据备份产品。通过在虚拟化层的I/O路径改造，方舟可以把用户的原始块设备存储放在后端去存储，并且能实现按秒的回滚。
武器四：数据方舟持续保护
对于数据备份产品，有两个重要的能力评估指标——恢复点目标（RPO）和恢复时间目标（RTO），目前数据方舟的RPO已经达到秒级别，默认支持12小时内恢复任意一秒，24小时内任意整点恢复，3天内的任意零点恢复，用户甚至可以自由定制备份链秒级、小时级、天级的保护范围，并且是恢复到一块新的磁盘上；而数据方舟的RTO则能够达到最短5分钟内恢复，即使是TB级别的数据量，也可以做到半小时内恢复。
数据方舟是如何在技术上做到对用户数据的持续保护呢？数据方舟后端使用了分层混合存储设计，用户的实时I/O会通过旁路以oplog的方式记录到方舟的接入节点（FRONT）上，由于方舟接入节点采用了高速磁盘设备，能够扛住用户大量的I/O写操作。
流式计算节点SHUFFLE会拉取接入节点的oplog进行批量处理，主要是进行数据分片（sharding），并将数据分片推送到最终存储层（ARKER）进行存储。随着时间的流逝，ARKER也会不断对数据进行合并，最终形成base/天级/小时/秒 四个级别的数据备份链。
用户恢复时，会调动后端集群所有节点的能力进行并行计算，加快恢复速度。值得一提的是，用户恢复时当前的磁盘数据是保留的，数据会回滚到一块新的磁盘上，这样做的目的是如果用户回滚后后悔，也能够回到恢复前的数据状态。
数据方舟恢复数据案例
案例一：勒索病毒
2017年5月“永恒之蓝”病毒爆发，全球大量Windows主机受到感染，企业重要文件被加密，只有支付高额赎金才能解密恢复文件。万户印刷公司的一台云服务器也遭受到了病毒攻击，用户的印刷文件被加密。
案例二：误操作导致文件系统异常
2017年12月，某AI公司遭遇到了重大危机，其运维人员在对存放重要数据的云硬盘进行扩容时，违规操作，导致硬盘出现了文件系统故障，数据无法访问。问题磁盘有着多个分区，该公司缺乏对多分区磁盘进行文件系统修复的经验，不敢贸然修复，担忧会因此导致数据进一步损坏。
案例三：游戏回档
2019年3月，某知名端游公司出现了严重的运营事故，一个道具的复制漏洞导致了游戏的平衡性失调，严重影响玩家体验，因此需要快速完成回档，保证对玩家的影响降低到最小。
这些案例中，用户最终都通过UCloud旗下的数据方舟产品进行恢复，迅速找回了所需要的数据。
私有云DB的数据安全备份
如果用户的DB搭建在私有云环境下，没关系， UCloud的对象存储产品UFile是一个海量的通用存储产品。通过和第三方产品结合，即便是私有云的DB同样可以利用公有云海量及可靠的存储服务，实现数据的高可靠性。
武器五：UFile对象存储帮助数据库备份
块存储上数据的保护不仅可以通过数据方舟解决，用户还可以使用基于 UFile 做数据持久化的 JuiceFS 存储数据库备份，JuiceFS 是为云端设计的 POSIX 共享文件系统，具有如下特点：
- 云端：采用云服务中的对象存储作为后端，综合性价比极高。
- POSIX：兼容标准 POSIX 接口，可以像本地文件系统一样使用。
- 共享：上千台机器同时挂载，高性能并发读写，共享数据。
UFile是UCloud自研的对象存储系统，兼容s3协议，具备高可用、高可靠和低成本的数据存储服务，提供多副本、跨地域等数据冗余机制，支持三地及以上的跨地域灾备功能。使用UFile用户可以实现高可靠、低成本的云上和跨云的数据备份，包括数据库备份、日志、大数据文件等。
基于UFile+JuiceFS搭建MySQL备份
UCloud用户下厨房是国内最大的专注于家庭美食领域的社区，目前拥有超过四千万注册用户，海量的业务也让下厨房对数据库的冗余和备份格外的重视，并且总结出一套非常高效和可靠数据库灾备经验。
除建立了跨可用区的主从节点外，下厨房会进行定时的整库备份和实时的binlog备份。下厨房的数据库备份借助了UFile、JuiceFS和Percona Xtrbackup。使用JuiceFS用户可以无需修改代码就可以替换之前的本地备份。并且可利用JuiceFS后端的对象存储来解决无限存储空间、跨区域复制以及低成本等问题。下厨房的策略是保留 7 天内的 Percona XtraBackup 整库备份、3 年内的 binlog 以及 1 年内的周级 mysqldump。
除此之外下厨房还想到了一个非常具备脑洞的备份验证方案。有了备份还无法做到高枕无忧，因为有时备份文件会出错，等到需要恢复时才发现备份出错就已经晚了。但是备份的验证是个非常耗时的工作，需要拷贝备份到本地进行恢复。下厨房利用JuiceFS的快照功能，克隆一份备份文件，在不影响原备份文件的情况下快速做验证，省下大量拷贝的时间。
详细实践可参考链接：https://juicefs.com/blog/cn/p...
账号和权限控制
在具备一定的备份和恢复机制下，数据库运维管理人员的权限控制问题仍然不可忽视，例如将数据库操作权限和备份权限进行分离、权限审批和操作执行分离、增加数据库命令隔离层等。
武器六：子账号
在权限管理控制方面，UCloud支持用户为自己的账户开设子账号，并定义为相应的角色。角色是一组产品权限的集合。若某成员的角色被修改，则其相应的权限也随之变更。子账号的存在有助于贯彻“最小权限管理”原则，只赋予工作职责所需的权限。大部分成员或许只需云资源的只读权限，少量操作者可拥有修改的权限，而删除权限必须通过管理员的审核。
多级账号权限控制，可以有效的控制多级人员的操作权限，最大程度的降低来自内部人员恶意操作的可能。
武器七：安全锁
安全锁是云资源高危操作的二次验证服务。开启该服务后，每次进行删除资源等危险操作时，需要通过手机短信校验身份才可。
受安全锁保护的高危操作例如有：
产品
操作
主机
开机、关机、删除实例
物理机
关机、删除实例
云数据库 UDB
删除实例、关闭
云内存存储 UMem
释放内存
对象存储 UFile
删除bucket、删除ufile geo bucket
云硬盘 UDisk
删除实例
写在最后
黑格尔曾说：“人类从历史中学到的唯一教训，就是人类无法从历史中学到任何教训。”云服务发展到今天，已经实现了多种完备的数据安全方案。如本文提到的UCloud七种武器，无论用户使用哪一种方式部署数据库，必有一款适合你。企业在今后发生数据库机器故障、误操作、恶意删除等情形时，能否充分利用云服务商提供的数据备份、恢复机制以及账号权限控制等能力，是解决数据丢失问题的关键。