[发明专利]一种针对Log-structured存储引擎的数据冷备方法及系统

说明书

本发明公开了一种Log‑structured存储引擎的数据冷备份方法及系统，基于Log‑structured存储引擎具有的append存储特性，构建一套基于文件级重演机制的数据自动同步机制，并以此机制为核心给出一种针对此类型存储引擎的数据冷备解决方案；以期以较小的资源开销，实现Log‑structured存储引擎数据的持续备份，并确保备份数据在任何时间节点上都具备可用性。

技术领域

本发明涉及数据备份技术领域，特别是涉及一种针对Log-structured存储引擎的数据冷备份方法及系统。

背景技术

近些年来，随着互联网应用的蓬勃发展，产生了海量的诸如视频、音频、图片等多媒体数据，为存储这些海量数据，涌现出一大批分布式的NOSQL存储产品，其中有相当一部分是基于Log-structured模式的存储引擎实现的，鉴于其出色的读/写性能，此类NOSQL存储产品为众多互联网企业所部署、应用，并且不少企业使用它们存储了PB乃至EB级的数据。出于数据安全考虑，通常需要对数据进行冷备份，即复制一个服务数据的副本，并将副本置于非服务环境下(即备份副本不对外服务)，当服务环境的数据出现损毁时，可从冷备副本恢复数据。但是，由于此类NOSQL产品所存储的数据体量通常很大，且数据量在持续快速增长，那么数据冷备份的工作也变得越发困难，所述数据冷备份是指在关闭数据库并且数据库不能更新的状况下进行的数据库完整备份，到目前为止仍未有NOSQL产品在数据冷备份上给出较好的解决方案。

实际上Log-structured模式的存储引擎，其数据的变更(含写入和更新)都是以向固定大小的数据文件append信息的方式进行的(类似记录日志的模式)，且对于已经生成的数据文件只做文件删除并不做文件修改；据此特性，对于Log-structured存储引擎的数据备份实际上可转化为对数据文件的备份。而业界对于数据文件的备份，大体上分为全量备份和增量备份两个方向；然而，对PB乃至EB级的数据进行冷备份，无论是采用全量备份还是增量备份的技术，实际实施的过程中都会面临诸多困难。

在全量备份方向上，其最大的问题就是耗时极长，以一个100TB的数据样本为例，以当下流行的硬件进行全量备份大约需要10天的时间；这也就是说，如果发生了服务数据的损毁，从冷备副本恢复的数据很可能就是10天前的老数据，而近10天的数据将不复存在，这几乎是难以接受的。此外，全量备份的过程中，服务环境的网络带宽资源会被严重消耗，而全量备份的过程又必须持续进行，那么此过程对于服务环境压力是可想而知的。因此，全量备份的方法，既不能保证数据的时效性，同时还会对服务环境造成重大的负面影响，乃至导致服务环境不可用。

增量备份方面，每次只备份与上次备份的差异部分，这种方式可以大幅降低备份的数据量，从而大幅缩减备份时长。但是这种备份方式仍然存在一些问题。首先，必须确保初始备份的全量数据以及后续历次备份的增量数据被完整地保持；其次，在进行数据恢复时，必须反复、有序地基于增量副本进行恢复工作，期间若出现恢复增量副本顺序上的错误，则极可能造成数据丢失，乃至出现恢复出的数据不可用的问题；再次，由于恢复过程涉及的增量副本众多，那么恢复的时间势必很长；最后，增量备份的时效性问题同样存在，提高增量备份的频率虽然可以增加备份数据的时效性，但是这势必造成增量副本和备份资源的增加，到头来会给恢复工作带来更多的困难。

在海量文件数据冷备份问题上，专利《一种数据备份方法》(申请号：CN201510918534.7)相关研究，此专利以文件级粒度进行数据备份，与文件同步软件rsync有相近之处，当然发明者对于备份源和备份目标的对比做了优化工作；然而，上述专利提出的方法并未对文件同步的顺序作出控制，而Log-structured存储引擎来对于备份文件的顺序要求是严格的，任何数据文件顺序上的错误或者是备份文件的遗漏都会导致存储引擎无法顺利启动，从而导致存储数据的根本损毁；此外，根据Log-structured存储引擎的通用垃圾清理机制，其在垃圾清理过程中，势必会产生大量新的数据文件，同时销毁大量的失效文件；此时，采用类似rsync的备份方式将更加无法确保数据文件的实时可用性。