现有的环境是NBU+虚拟带库,整体架构比较老式。
需求是:想实现对一些近60TB的零散的大量文件进行备份,而且经常需要进行数据库的备份恢复。是否有新的备份体系,可以实现无需通过恢复的方式,就可以对备份的数据进行读取和抽取
你说的这种新的备份体系应该指的是CDM,即数据副本管理,它的特点就是备份的数据为原格式,恢复时将形成的黄金副本的二级副本直接挂载给应用。这种产品通常可以用做备份恢复场景,测试开发快速提供数据场景等。
收起60TB的文件不知道是小量的零碎文件还是大规格的数据文件,如果是海量小文件的问题,只能想办法改善备份慢的问题,能够完美解决海量文件备份效率的方案,成本都不低,入不敷出。
利用块级别备份备份海量文件,虽然可以解决备份效率慢问题,但是恢复的时候无法精确恢复单个文件,因此在备份的时候需要更多规划,包括数据存取,数据结构等。往往这更多规划,难以实施,海量小文件的形成必然是长时间的积累,为了备份恢复去大刀阔斧的改造,很多企业都下不了狠手。
海量小文件的问题,更多的可以从两个方面入手,第一个是优化海量小文件的文件结构,想办法把小文件聚合成大文件,提高备份恢复效率,减少文件扫描的时间成本,常见的做法就是进行打包压缩。第二个就是改变海量小文件的存储方式,海量小文件备份恢复慢,绝大部分是对文件的扫描、备份时因为数量庞大导致open files、close files的次数特别多,如果不是以小文件方式直接备份恢复文件、直接从系统底层直接抽取数据进行备份恢复……在这点上不少企业使用了对象存储,需要注意的是对象存储的备份接口引擎,可能需要定制化。
数据库的场景,可以采用CDM技术进行,CDM备份只要条件满足,可以直接抽取备份副本直接拉起数据库,这点在很多场景比传统恢复方便,但同时你也要接受这种方案的高成本和高环境要求。
收起1、备份:
国际一线品牌中的解决方案中,NBU和Commvault都能实现备份快,但实现原理不同。
NBU是通过在文件系统中使用tracking file来做文件级别的备份,因此无法避免首次备份慢的问题,后续还是看变化情况,如果变化量不大,是OK的,除此之外,还需要定期进行force rescan,否则会出问题。以前7.0时代曾经用过flash backup技术,但需要有专门的快照卷,而且备份大小是卷的大小,后面此技术被前面这种基于tracking file的accelerator技术取代。
Commvault是通过块级别的备份,首次全备份和后续增量备份可以很快,结合合成全备份可以实现永久增量备份。块级备份对生产影响小,不用担心扫描和备份海量文件对生产的影响。Commvault还可以在同一个任务里实现备份和归档,可选择留或者不留存根文件,有存根文件就可以实现用户无感知的访问已归档走的文件。
2、恢复:
NBU基于tracking file的accelerator只能用于备份加速,遇到还原的时候,还得实打实的恢复,相当于首次备份的速度。
Commvault的还原可以从块级别备份中还原单个文件,还原整个卷到源卷、不同卷和异机均可,规避了还原小文件慢的问题,还可以按需挂载成一个路径,支持挂载到原机和异机,比较灵活。