企业核心数据库数十TB且日益数据量增长，数据备份有啥好解决方案？

对于 结构化数据的数据库来说。备份我觉得还是比较容易解决的。我们采用的是爱数的备份一体机。可用容量在90T以上。配合数据压缩，去重和SAN备份。备份的速度和容量都还算比较理想，另外可以支持扩展柜来扩充容量，可能是入行久了。经历了太多关于数据的风险，所以对于备份这件事。我永远都不够，根据数据的容量和重要性，可以先采用备份一体机进行数据的有效性备份，之后考虑D2D2T.实现数据的归档保存。我实际应用觉得效果还不错
对于非结构化的数据。我觉得备份其实要更麻烦一些。文件琐碎，繁多。传统的备份无法发挥效果。我实际接触到的只有200G左右的文档数据实际的备份速度非常慢。这个现在好像有些专门的对象存储效果还不错。
我手里有些一体机的介绍和方案。有需要可以私信我。

1.优先进行分库，当前库和历史库

2. 在一个数据库内分表空间，经常变动的放在一个或多个表空间，不变的放在一个或多个表空间
3. 启用数据库压缩功能
   4.使用带压缩功能的存储
   5.数据库全量备份结合增量备份

从高可用的角度来说，应该采用多种方式，比如分库、双活、基于应用或者存储的双活，这个是题外话，传统备份还是有一定的不可替代性，数据量大了确实是个问题. 下面是和备份相关的.

1. 在原有架构上下功夫提升备份速度，比如加大备份恢复任务的并行数（如果是带库，增加磁带机），选用高速存储介质，如lto4更换lto7磁带机。 4G FC环境升级到16GB环境，千兆改万兆等，采用单独的备份网络

2.采用重删技术。 有基于软件和基于硬件的去重。基于软件的一般为备份软件自带，如tsm的目录池，nbu的msdp。 基于硬件典型的有集成到虚拟磁带库里的，或者其他存储集成方案，如emc的boost和nbu的ost集成。 从去重操作端来看，有源端去重和目标端去重。 源端的发送数据少，占用客户端资源多些，目标端去重传输量大些，客户端压力小些，具体需要根据自己的情况。

3. 其他和应用集成的备份技术，简单列举几个

         ---比如和存储快照集成的，IBM的fcm方案。 和存储快照集成，可以到分钟级别
        ---或者nbu的accelerator加速，备份VMware是全备也可以利用cbt，备份时间特别短。
        ---Oracle的proxy copy备份和其他备份软件去重技术结合，去重率可以达到90%以上，备份时间也会大幅度缩短。
        

4. 一体机方面，nbu的appliance一体机还行， 这个.. 利益相关，自己判断，呵呵

目前最主流的PBBA备份专用设备还是DellEMC的DataDomain，市场占有率一直超过70%，同时，目前在基于DataDomain的技术的基础上，开发了IDPA集成备份一体机。在有限的备份窗口内，DataDomain独有的DDBoost技术可以大幅加速备份，有效的减少对因备份导致的计算资源开销。在虚拟化、数据库、NAS、桌面等备份场景下都有很好的方案。

有几种方案仅供参考：
从备份速度提升来说，第一可以采取在数据库io空闲时,利用存储的快照来做备份，速度是秒级的。第二采用LTO7带库，速度是每秒1.1g。从数据改造来说，可以分库分表。其实对你核心数据库10多T，有许多是流水表的，这些数据平时可以不备，重要时间节点做个全备，并且这些数据测试并不需要，这可以减轻你恢复数据测试的压力

其实不妨考虑一下CDP产品，直接对存储做拆分，可以很快拉起任意时间点数据来测试，

需要遵循以下几个原则：
一是梳理清楚哪些数据是真正需要备份的，而不是被动的满足开发要求；
二是进行分库分表，针对重要性或者数据量进行划分，针对数据的变动情况进行划分；
三是业务系统进行微服务化改造，将部分原来需要存储在最终数据库上的数据，分解到上层或者分层的数据库里。
四是开启数据库和存储的压缩功能；
总之，千万不要以为数据备份量大就是完全运维需要解决的问题，要整体看待，笔者就加过将很多无用数据写入数据库的情况。