CN117992280A - 一种基于对象存储的恢复历史数据的方法及*** - Google Patents
一种基于对象存储的恢复历史数据的方法及*** Download PDFInfo
- Publication number
- CN117992280A CN117992280A CN202410106647.6A CN202410106647A CN117992280A CN 117992280 A CN117992280 A CN 117992280A CN 202410106647 A CN202410106647 A CN 202410106647A CN 117992280 A CN117992280 A CN 117992280A
- Authority
- CN
- China
- Prior art keywords
- file
- backup
- record
- files
- path
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 31
- 238000011084 recovery Methods 0.000 claims abstract description 50
- 230000001360 synchronised effect Effects 0.000 claims abstract description 19
- 238000006243 chemical reaction Methods 0.000 claims description 16
- 230000004048 modification Effects 0.000 claims description 14
- 238000012986 modification Methods 0.000 claims description 14
- 238000012545 processing Methods 0.000 claims description 10
- 238000013507 mapping Methods 0.000 claims description 5
- 230000008569 process Effects 0.000 description 9
- 238000005516 engineering process Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 4
- 238000011161 development Methods 0.000 description 3
- 238000010586 diagram Methods 0.000 description 2
- 230000008859 change Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 239000000344 soap Substances 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种基于对象存储的恢复历史数据的方法及***,所述方法包括如下步骤:步骤S1,在上传文件前记录上传文件的时间点,扫描源备端文件比对确定需上传的文件并将其上传至对象存储,对不支持版本控制的对象存储,给每个上传的文件添加一个副本,同时于文件同步记录中对每个上传的文件添加备份记录;步骤S2,在文件恢复阶段,选择恢复时间点,根据恢复时间点、源端路径、备端路径于所述文件同步记录中查找出相应的备份记录,根据备份记录中的版本信息及源备端路径得到所要恢复文件的真实存储路径,从而获取对应文件。
Description
技术领域
本发明涉及计算机容灾备份技术领域,特别是涉及一种基于对象存储的恢复历史数据的方法及***。
背景技术
随着网络技术的发展目前已进入了数据共享时代,海量的文件进入人们的世界。对象存储是一种比较常见的存储方式。对象存储是一种基于对象的存储方式,其具备智能、自我管理能力,通过web服务协议(如:REST、SOAP)实现对象的读写和存储资源的访问。对象存储是面向对象/文件的、海量的互联网存储,存放的是已经被封装的文件,因此在对象存储***里不能够打开文件,但可以像ftp一样上传和下载文件。另外对象存储没有像文件***那样有一个很多层级的文件结构,只有一个桶的概念,即桶里面存了很多个对象,每个对象都有自己的唯一key,也就是说根据桶名和唯一key就能够确定一个对象。对象存储的优势在于优秀的扩展性、基于策略的自动化管理特性、支持多用户管理技术。
虽然对象存储的出现很好的解决了海量文件的存储和共享问题,但是随着技术的发展越来越多的问题也相继出现。人们的需求也越来越多越来越复杂,海量文件中的部分定时修改,而这些已经修改的文件也需要定时备份。一个文件往往有多个版本并且每个版本的文件都是有价值的,这就需要相关存储具备版本控制的功能。但是随着网络技术的发展网络安全问题也随之而来,一旦源端***崩溃或者硬件损坏就会导致数据的丢失,排除故障后就需要将备份的文件恢复到源端且很多时候需要恢复到某个时间点。
目前部分对象存储虽有版本控制的功能,但却无法记录时间点与备份文件版本的关系,需要主观地记录备份时间点和文件版本的关系,但海量文件多次同步需要保存的记录更是海量,一般的数据库技术无法支持亿级记录的存储与访问,因此现有技术中,对于频繁修改的基于对象存储的文件,当本地机器出故障后或者文件丢失后存在无法将某个文件夹下的文件恢复到某个时间点的问题。
发明内容
为克服上述现有技术存在的不足,本发明之目的在于提供一种基于对象存储的恢复历史数据的方法及***,以实现对基于对象存储的文件,在本地机器出故障后或者文件丢失后可将文件恢复到选择的时间点的目的。
为达上述目的,本发明提出一种基于对象存储的恢复历史数据的方法,包括如下步骤:
步骤S1,记录本次上传文件的时间点,扫描源备端文件比对确定需上传的文件并将其上传至对象存储,对不支持版本控制的对象存储,给每个上传的文件添加一个副本,同时于文件同步记录中对每个上传的文件添加备份记录;
步骤S2,在文件恢复阶段,选择恢复时间点,根据恢复时间点、源路径、备端路径于所述文件同步记录中查找出相应的备份记录,根据备份记录中的版本信息及源备端路径得到所要恢复文件的真实存储路径,从而获取对应文件。
优选地,步骤S1进一步包括:
步骤S100,在批量上传文件之前记录本次上传文件的时间点,以用于恢复文件时选择对应的恢复时间点;
步骤S101,扫描源端和备端文件进行对比,确定需上传的文件,并将需上传的文件加入待上传文件列表;
步骤S102,循环遍历待上传文件列表,将所述待上传文件列表中的文件一一上传至对象存储,并于所述文件同步记录中添加或修改所上传文件的备份记录,对不支持版本控制的对象存储,根据当前上传文件的唯一key利用预设转换规则映射一个新唯一key,并拷贝该当前上传文件至该新唯一key。
优选地,于步骤S101中,通过扫描源端和备端文件进行对比,将备端缺失的文件以及源端已经修改过与源端有异的文件加入所述待上传文件列表。
优选地,于步骤S101中,通过扫描源端和备端文件进行对比,对于源端被删除掉的文件,更新该文件于所述文件同步记录中的备份记录。
优选地,于步骤S101中,对于源端已经删除的文件,根据备端路径和/或源端路径以及文件名更新所述文件同步记录中该文件对应的备份记录,将其latestFlag改为0,以及deleteTime改为本次执行的时间。
优选地,于步骤S102中,对于第一次同步的文件,于所述文件同步记录添加该文件对应的备份记录,对于已经添加过备份记录的文件则对旧记录进行对应的修改。
优选地,于步骤S102中,根据源端路径、备端路径、源端文件名、上传后文件名查询所述文件同步记录中是否有相关记录,若无相关记录则直接***记录,若有相关记录并且记录中的备份时间点的个数小于预设值,则将该文件的本次版本信息和备份时间点叠加在文件版本号和备份时间点后,并修改备份记录中maxTime为本次执行时间;若有相关记录且记录中的备份时间点个数大于等于100个,则将查到的备份记录的maxTime改为本次执行时间点减1,latestFlag改为0,并***一条新记录.
优选地,步骤S2进一步包括:
步骤S200,根据备份时间表选择恢复时间点,根据所要恢复的时间点、源端路径ID、备端路径ID分页查询分页查询备份记录,根据查询结果从备份记录中取出相关版本信息,并将对应的文件加入待传输文件列表;
步骤S201,遍历所述待传输文件列表,根据各待传输文件的版本信息及源备端路径得到所要恢复文件的真实存储路径,从而获取对应文件。
优选地,于步骤S201中,根据所述待传输文件列表中待恢复文件版本信息的文件修改时间戳以及待恢复文件的源备端路径进行根据预设转换规则映射得到待恢复文件的真实存储路径。
为达到上述目的,本发明还提供一种基于对象存储的恢复历史数据的***,包括:
上传文件处理模块,用于记录本次上传文件的时间点,扫描源备端文件比对确定需上传的文件并将其上传至对象存储,对不支持版本控制的对象存储,给每个上传的文件添加一个副本,同时于文件同步记录中对每个上传的文件添加备份记录;
文件恢复处理模块,用于在文件恢复阶段,选择恢复时间点,根据恢复时间点、源路径、备端路径于所述文件同步记录中查找出相应的备份记录,根据备份记录中的版本信息及源备端路径得到所要恢复文件的真实存储路径,从而获取对应文件。
与现有技术相比,本发明一种基于对象存储的恢复历史数据的方法及***通过在文件上传阶段上传文件前记录上传文件的时间点,确定要上传的文件并将其上传至对象存储,同时于文件同步记录中对每个上传的文件添加用于记录文件版本信息、源端文件与备端文件的对比属性以及备份时间点的备份记录,文件恢复阶段,则根据时间点、源路径、备端路径于文件同步记录中查找出所要恢复文件的版本信息,根据版本信息及源路径得到所要恢复文件的真实存储路径,从而获取对应文件恢复历史数据,实现了对基于对象存储的文件,在本地机器出故障后或者文件丢失后可将文件恢复到任意选择时间点的目的。
附图说明
图1为本发明一种基于对象存储的恢复历史数据的方法的步骤流程图;
图2为本发明一种基于对象存储的恢复历史数据的***的***架构图;
图3为本发明实施例中文件上传的流程图;
图4为本发明实施例中恢复历史数据的流程图。
具体实施方式
以下通过特定的具体实例并结合附图说明本发明的实施方式,本领域技术人员可由本说明书所揭示的内容轻易地了解本发明的其它优点与功效。本发明亦可通过其它不同的具体实例加以施行或应用,本说明书中的各项细节亦可基于不同观点与应用,在不背离本发明的精神下进行各种修饰与变更。
图1为本发明一种基于对象存储的恢复历史数据的方法的步骤流程图。如图1所示,本发明一种基于对象存储的恢复历史数据的方法,包括如下步骤:
步骤S1,记录上传文件的时间点,通过扫描源备端文件确定需上传的文件并将其上传至对象存储,对不支持版本控制的对象存储,给每个上传的文件添加一个副本,同时于文件同步记录中对每个上传的文件添加备份记录,所述备份记录用于记录上传文件的版本、同步时间点等信息,所述文件同步记录存放于elasticsearch数据库中。
具体地,步骤S1进一步包括:
步骤S100,在批量上传文件之前记录本次上传文件的时间点,以用于恢复文件时选择对应的恢复时间点。在本发明中,上传文件选择批量上传的方式以上传至对象存储,当需要批量上传源端文件时,在上传之前记录本次上传文件的时间点,这里记录时间点的意义是以便后续可将文件恢复到这一时刻该文件的内容。在本发明具体实施例中,该时间点既存放于一个存放所有执行时间点的备份时间表中,也存放于备份记录的backupTimes中用于记录该文件在哪一次被上传过。
步骤S101,扫描源端和备端文件进行对比,确定需上传的文件,并将需上传的文件加入待上传文件列表。在本发明具体实施例中, 加入所述待上传文件列表的需上传文件的属性主要包括文件路径(即待上传文件源端路径)、文件名、大小、时间戳等用于比较的属性,当然,有的情况若需要对比源端与备端的md5值,还需要包括需上传文件的md5值,在本发明中,所述待上传文件列表处于源端。
在本发明具体实施例中,对源端和备端的文件扫描后分别加入一个文件列表,然后将源端和备端文件列表进行对比,例如通过属性对比,如文件名、大小、MD5值等,以确定源端哪些文件需要上传至对象存储,以及确定源端有哪些文件被删除,经过对比,备端缺失的文件以及源端已经修改过与备端有异的文件需要上传至对象存储,将需要上传的文件加入待上传文件列表。
对于源端被删除掉的文件则需要更改文件同步记录中对应的备份记录,表示该文件在此时间点上传前已经删除,恢复文件夹到该时间点时将不恢复该文件,因此,对于源端已经删除的文件则需要根据备端路径和/或以及文件名去更新文件同步记录中该文件对应的备份记录,将其latestFlag改为0,以及deleteTime改为本次执行的时间(因为备份记录中的deleteTime主要用于恢复文件阶段,在恢复文件时如果deleteTime大于所选择的备份时间点时该记录是有效的,在恢复文件阶段,查询记录时其中一个重要条件查询deleteTime)。
步骤S102,循环遍历待上传文件列表,将所述上传文件列表中的文件一一上传至对象存储,并于文件同步记录中添加或修改所上传文件的备份记录,以记载版本信息以及源端文件与备端文件的对比属性,对不支持版本控制的对象存储,根据当前上传文件的唯一key映射为一个新唯一key,并拷贝文件至该新唯一key。在本发明中,对于不支持版本控制的对象存储,由于同唯一key的文件上传至对象存储会覆盖掉之前的文件,这样若需要恢复历史版本的文件就需将其保存在根据预设规则转换过后的唯一新路径下。
具体地说,上传的文件主要包括备端缺失的文件和源端修改过的文件,需遍历所述待上传文件列表,将其中的文件上传至对象存储,每个上传的文件会返回自己在对象存储的唯一key,该唯一key可以是一个路径,例如某一上传文件上传至dtotest:/abc/bcd/a.txt这个备端路径,其中dtotest是桶名,后面的路径/abc/bcd/a.txt则为该上传文件的唯一key。由于对于同一个文件来说,其唯一key值都是相同的,对于不支持版本控制的对象存储,同唯一key的文件上传至对象存储会覆盖掉之前的文件,此情况下仅仅根据该唯一key值无法得到中间版本的文件。
对于支持版本控制的对象存储,由于每上传一个文件会返回一个唯一字符串作为版本号,例如一个文件上传五次就可得到五个版本号,这样若需下载某个版本的文件时,则根据唯一key和对应版本号就可以得到对应文件;而对于不支持版本控制的对象存储,每次上传文件不会获得版本号,那么根据唯一key就只能获得最新版本的文件,不能得到所需版本的文件,因此,在本发明中,对于不支持版本控制的对象存储,则将该唯一key根据预设转换规则映射成唯一的新路径,即本次上传文件的新唯一key,在本发明具体实施例中,唯一key可以作为一个路径,该预设转换规则为:先将该唯一key转换成另外一条路径,并与文件名和时间戳结合组成新的路径,从而得到本次上传文件的新唯一key,例如:新唯一key =“backup/” + “旧唯一key以#&#代替文件名中的点形成的字符串” +” /” + “文件修改时间戳-文件名”,比如,当某个文件上传对象存储的唯一key为dtotest:/abc/a.txt,则可将其转换为dtotest:/backup/abc/a#&#txt/时间戳-a.txt作为该文件的新唯一key,并拷贝该文件至该新唯一key,同时将该新唯一key下的文件名更改为“时间戳-文件名”。这里需说明的是,转换规则可以自由定义,只要不同版本的文件可以得到不同的新唯一key即可,本发明不以此为限。
在本发明中,在将当前上传文件存储于对象存储并拷贝至新唯一key后,还需于文件同步记录中添加当前上传文件的备份记录,以记载当前上传文件的版本信息、源端文件与备端文件的对比属性以及备份时间点,一条备份记录可以包含一个文件几次上传的信息,每次更新主要是叠加文件的版本信息和备份时间点。
具体地,所述文件同步记录存放于elasticsearch数据库中,elasticsearch是一个基于Lucene且提供持久存储、统计等多项功能的现代搜索引擎,具有高扩展、高实时的特性,它能很方便的使PB级数据具有搜索、分析和探索的能力,充分利用Elasticsearch的水平伸缩性,能使数据在生产环境变得更有价值,本发明选择elasticsearch则主要是因为elasticsearch在处理海量文件搜索时有很大的优势,所述文件同步记录中备份记录的主要作用是记载版本信息、源端文件与备端文件的对比属性,以及备份时间点,一条备份记录可以包含一个文件几次上传的信息,每次更新主要是叠加文件的版本信息和备份时间点。
具体地,所述文件同步记录中的备份记录的字段包括但不限于:recordId、srcPathId、destPathId、fileName、afterName、versionIds、backupTimes、minTime、maxTime、deleteTime、latestFlag,其中recordId用于唯一标志一条记录,主要用于分页查询相关记录,fileName 表示文件上传前源端的文件名,srcPathId表示源端路径id,destPathId表示备端路径id,afterName表示文件上传至备端后的名字,versionIds表示多个以逗号隔开的文件版本号,而每个版本号主要由文件的属性信息组成,其中至少有文件的修改时间戳,还可以有源端与备端用于对比的属性信息,在本发明具体实施例中,例如,如果对象存储支持版本控制,versionId = 对象存储返回的版本号+需要的属性(该属性一般包括文件修改时间戳+文件大小+备端文件md5),如果对象存储不支持版本控制,则versionId为文件修改时间戳+文件大小+备端文件md5,backupTimes由多个备份时间点组成,记录该文件在何时上传过,minTime表示backupTimes中最小的时间点,maxTime表示backupTimes中最大的时间点,deleteTime表示该文件被删除的时间点,latestFlag表示该文件的最新记录。
在本发明中,为了节省空间每条记录可表示多次的上传信息,当一条记录存放次数等于100(即backupTimes个数小于100)时,latestFlag标志会归0,则重新***一条关于该原路径、备端路径、文件的记录。为了节省内存消耗,在查询过程中采用分页查询的方法。
具体地说,在添加备份记录时,首先将当前上传备份的文件的源端路径与备端路径(备端路径即该文件的唯一key,而不是新唯一key)通过分级目录表转换为ID,在本发明具体实施例中,对于源端路径与备端路径采取分级目录的方式,每一级目录都独立生成ID,生成的ID为36进制的字符,每级目录之间以”-”号隔开,子目录的ID包含父级目录的ID,例如对于D:\abc\2\gh这个路径,首先分割一级,二级,三级,四级目录分别是D:、abc、2、gh,然后分别到各级的分级目录表中去查找对应的路径对应的ID,所述分级目录表记载了各级目录与其对应的id,比如第一级分级目录表如下:
ID | path |
1 | D: |
2 | E: |
假如D:对应的是1,abc对应的是8,2对应的是D,gh对应的是F,那么D:\abc\2\gh这个路径对应的路径ID就是1-8-D-F(每级目录id是36进制即1到9加上A到Z),根据源端路径ID、备端路径ID、源端文件名、上传后文件名(源端文件名与上传后的文件名有可能不同,因为有时客户会有特殊的需求,上传后文件名会有修改,例如字母变成大写)查询elasticsearch的文件同步记录中是否有相关记录,若无相关记录则直接***记录,若有相关记录并且记录中的备份时间点backupTimes小于100个,则将该文件的本次版本信息和备份时间点叠加在文件版本号versionIds和备份时间点backupTimes后面,并修改maxTime为本次执行时间;若有相关记录且记录中的备份时间点个数大于等于100个,则将查到的记录maxTime改为本次执行时间点减1,lateFlag改为0,并***一条新记录。
步骤S2,在文件恢复阶段,选择恢复时间点,根据恢复时间点、源端路径、备端路径于文件同步记录中查找出相应的备份记录,根据备份记录中的版本信息及源备端路径得到所要恢复文件的真实存储路径,从而获取对应文件。
具体地,步骤S2进一步包括:
步骤S200,根据备份时间表选择恢复时间点,根据所要恢复的时间点、源端路径ID、备端路径ID分页查询备份记录,根据查询结果将对应文件的属性信息加入待传输文件列表。
在本发明具体实施例中,当进行文件恢复时,根据备份时间表选择一个回复时间点,获取用户输入的源端路径及备端路径查询备份记录,优选地,为了节省内存消耗,可利用参数recordId分页查询备份记录,例如针对海量文件每次查询1000条记录,直到查询完符合条件的记录,每次查询完一页的备份记录需遍历这些记录从记录中根据备份时间点取出相关版本信息,将需传输的文件(即该文件的属性信息)加入待传输文件列表。
本发明中,查询备份记录的参数主要有源端路径和备端路径以及恢复时间点,由于文件同步记录中记录的是源端路径ID及备端路径ID,因此,首先根据源端路径和备端路径确定源端路径ID和备端路径ID,例如D: \2\gh这个路径,首先分割下一级,二级,三级目录分别是D:、2、gh,然后分别到各级目录表中去查找对应的路径对应的id。假如D:对应的是1,2对应的是8,gh对应的是D,那么对应的路径id就是1-8-D(每级目录id是36进制即1到9加上A到Z),根据所要恢复的时间点、源端路径ID、备端路径ID、分页参数recordId于所述文件同步记录中查询备份记录,根据查询结果从备份记录中取出相关版本信息,并将对应的文件的属性信息加入待传输文件列表。需说明的是,由于子目录的路径id包含父级目录的路径id,根据该特征可以查找出文件夹及子目录中所有文件的备份记录,例如D:\abc\vb\fg与D:\abc\vb\fg\dd两个路径,他们对应的id分别为1-1-2-3和1-1-2-3-4,当需要查询D:\abc\vb\fg目录及其子目录下所有文件的记录,只需条件输入srcPathId like 1-1-2-3*即可。
步骤S201,遍历待传输文件列表下载文件。
在此过程中,根据备份记录中的源端和备端路径以及版本信息,根据转换规则得到该文件的真实存储路径,具体地,根据预设转换规则和文件的修改时间戳将待下载文件的源路径转换成文件的真实存储路径,需说明的是,下载过程中的源路径则是上传过程中的备端路径,即记录在备份记录中的唯一key,对备份记录中的备端路径根据预设规则转换为另一条路径,然后与文件名和时间戳(根据文件同步记录的versionIds)结合得到待下载文件的真实存储路径,并从真实存储路径下载文件至本地。
图2为本发明一种基于对象存储的恢复历史数据的***的***架构图。如图2所示,本发明一种基于对象存储的恢复历史数据的***,包括:
上传文件处理模块20,用于记录上传文件的时间点,通过扫描源备端文件确定需上传的文件并将其上传至对象存储,对不支持版本控制的对象存储,给每个上传的文件添加一个副本,同时于文件同步记录中对每个上传的文件添加备份记录,所述备份记录用于记录上传文件的版本、同步时间点等信息,所述文件同步记录存放于elasticsearch数据库中。
具体地,上传文件处理模块20进一步包括:
时间点记录单元201,用于在批量上传文件之前记录本次上传文件的时间点,以用于恢复文件时选择对应的恢复时间点。在本发明中,上传文件选择批量上传的方式上传至对象存储,当需要批量上传源端文件时,在上传之前记录本次上传文件的时间点,这里记录时间点的意义是以便后续将文件恢复到这一刻时该文件的内容。在本发明具体实施例中,该时间点可以既存放于一个存放所有执行时间点的备份时间点表中,也存放于备份记录的backupTimes中用于记录该文件在哪一次被上传过。
扫描对比单元202,用于扫描源端和备端文件进行对比,确定需上传的文件,并将需上传的文件加入待上传文件列表。在本发明具体实施例中, 加入所述待上传文件列表的该需上传文件的属性主要包括文件路径(即待上传文件源端路径)、文件名、大小、时间戳等用于比较的属性,当然,有的情况若需要对比源端与备端的md5值,还需要包括需上传文件的md5值,所述待上传文件列表处于源端。
在本发明具体实施例中,对源端和备端的文件扫描后分别加入一个文件列表,然后将源端和备端文件列表进行对比以确定源端哪些文件需要上传至对象存储,以及确定源端有哪些文件被删除,具体地说,经过对比,备端缺失的文件以及源端已经修改过与源端有异的文件需要上传至对象存储,将需要上传的文件加入待上传文件列表。
对于源端被删除掉的文件则需要更改对应的备份记录,表示该文件在此时间点上传前已经删除,恢复文件夹到该时间点时将不恢复该文件,因此,对于源端已经删除的文件则需要根据备端路径和/或以及文件名去更新文件同步记录中该文件对应的备份记录,将其latestFlag改为0,以及deleteTime改为本次执行的时间(因为备份记录中的deleteTime主要用于恢复文件阶段,在恢复文件时如果deleteTime大于所选择的备份时间点时该记录是有效的,在恢复文件阶段,查询记录时其中一个重要条件查询deleteTime)。
遍历上传单元203,用于循环遍历待上传文件列表,将所述上传文件列表中的文件一一上传至对象存储,并于文件同步记录中添加或修改所上传文件的备份记录,以记载版本信息以及源端文件与备端文件的对比属性,对不支持版本控制的对象存储,根据当前上传文件的唯一key映射为一个新唯一key,并拷贝文件至该新唯一key。在本发明中,对于不支持版本控制的对象存储,由于同唯一key的文件上传至对象存储会覆盖掉之前的文件,这样若需要恢复历史版本的文件就需将其保存在根据预设规则转换过后的唯一新路径下。
具体地说,上传的文件主要包括备端缺失的文件和源端修改过的文件,需遍历所述待上传文件列表,将其中的文件上传至用于对象存储的服务器进行对象存储,每个上传的文件会返回自己在对象存储的唯一key,该唯一key可以是一个路径,例如某一上传文件上传至dtotest:/abc/bcd/a.txt这个备端路径,其中dtotest是桶名,后面的路径/abc/bcd/a.txt则为该上传文件的唯一key。由于对于同一个文件来说,其唯一key值都是相同的,同唯一key的文件上传至对象存储会覆盖掉之前的文件,此情况下仅仅根据该唯一key值无法得到中间版本的文件。
对于支持版本控制的对象存储,由于每上传一个文件会返回一个唯一字符串作为版本号,例如一个文件上传五次就可得到五个版本号,这样若需下载某个版本的文件时,则根据唯一key和对应版本号就可以得到对应文件;而对于不支持版本控制的对象存储,每次上传文件不会获得版本号,那么根据唯一key就只能获得最新版本的文件,不能得到所需版本的文件,因此,在本发明中,对于不支持版本控制的对象存储,则将该唯一key根据预设转换规则映射成唯一的新路径,即本次上传文件的新唯一key,在本发明具体实施例中,唯一key可以作为一个路径,该预设转换规则为:先将该唯一key转换成另外一条路径,并与文件名和时间戳结合组成新的路径,从而得到本次上传文件的新唯一key,例如:新唯一key =“backup/” + “旧唯一key以#&#代替文件名中的点形成的字符串” +” /” + “文件修改时间戳-文件名”,比如,当某个文件上传对象存储的唯一key为dtotest:/abc/a.txt,则可将其转换为dtotest:/backup/abc/a#&#txt/时间戳-a.txt作为该文件的新唯一key,并拷贝该文件至该新唯一key,同时将该新唯一key下的文件名更改为“时间戳-文件名”。这里需说明的是,转换规则可以自由定义,只要不同版本的文件可以得到不同的新唯一key即可,本发明不以此为限。
备份记录更新单元204,用于于文件同步记录中添加当前上传文件的备份记录,以记载当前上传文件的版本信息、源端文件与备端文件的对比属性以及备份时间点,一条备份记录可以包含一个文件几次上传的信息,每次更新主要是叠加文件的版本信息和备份时间点。
所述文件同步记录存放于elasticsearch数据库中,elasticsearch是一个基于Lucene且提供持久存储、统计等多项功能的现代搜索引擎,具有高扩展、高实时的特性,它能很方便的使PB级数据具有搜索、分析和探索的能力,充分利用Elasticsearch的水平伸缩性,能使数据在生产环境变得更有价值,本发明选择elasticsearch则主要是因为elasticsearch在处理海量文件搜索时有很大的优势,所述文件同步记录中备份记录的主要作用是记载版本信息、源端文件与备端文件的对比属性,以及备份时间点,一条备份记录可以包含一个文件几次上传的信息,每次更新主要是叠加文件的版本信息和备份时间点。
具体地,所述文件同步记录中的备份记录的字段包括但不限于:recordId、srcPathId、destPathId、fileName、afterName、versionIds、backupTimes、minTime、maxTime、deleteTime、latestFlag,其中recordId用于唯一标志一条记录,主要用于分页查询相关记录,fileName 表示文件上传前源端的文件名,srcPathId表示源路径id,destPathId表示备端路径id,afterName表示文件上传至备端后的名字,versionIds表示多个以逗号隔开的文件版本号,而每个版本号主要由文件的属性信息组成,其中至少有文件的修改时间戳,还可以有源端与备端用于对比的属性信息,在本发明具体实施例中,例如,如果对象存储支持版本控制,versionId = 对象存储返回的版本号+需要的属性(该属性一般包括文件修改时间戳+文件大小+备端文件md5),如果对象存储不支持版本控制,则versionId为文件修改时间戳+文件大小+备端文件md5,backupTimes由多个备份时间点组成,记录该文件在何时上传过,minTime表示backupTimes中最小的时间点,maxTime表示backupTimes中最大的时间点,deleteTime表示该文件被删除的时间点,latestFlag表示该文件的最新记录。
在本发明中,为了节省空间每条记录可表示多次的上传信息,当一条记录存放次数等于100(即backupTimes个数小于100)时,latestFlag标志会归0,则重新***一条关于该原路径、备端路径、文件的记录。为了节省内存消耗,在查询过程中采用分页查询的方法。
具体地说,在添加备份记录时,首先将当前上传备份的文件的源端路径与备端路径(备端路径即该文件的唯一key,而不是新唯一key)通过分级目录表转换为ID,在本发明具体实施例中,对于源端路径与备端路径采取分级目录的方式,每一级目录都独立生成ID,生成的ID为36进制的字符,每级目录之间以”-”号隔开,子目录的ID包含父级目录的ID,例如对于D:\abc\2\gh这个路径,首先分割一级,二级,三级,四级目录分别是D:、abc、2、gh,然后分别到各级的分级目录表中去查找对应的路径对应的ID,所述分级目录表记载了各级目录与其对应的id,比如第一级分级目录表如下:
ID | path |
1 | D: |
2 | E: |
假如D:对应的是1,abc对应的是8,2对应的是D,gh对应的是F,那么D:\abc\2\gh这个路径对应的路径ID就是1-8-D-F(每级目录id是36进制即1到9加上A到Z),根据源端路径ID、备端路径ID、源端文件名、上传后文件名(源端文件名与上传后的文件名有可能不同,因为有时客户会有特殊的需求,上传后文件名会有修改,例如字母变成大写)查询elasticsearch的文件同步记录中是否有相关记录,若无相关记录则直接***记录,若有相关记录并且记录中的备份时间点backupTimes小于100个,则将该文件的本次版本信息和备份时间点叠加在文件版本号versionIds和备份时间点backupTimes后面,并修改maxTime为本次执行时间;若有相关记录且记录中的备份时间点个数大于等于100个,则将查到的记录maxTime改为本次执行时间点减1,lateFlag改为0,并***一条新记录。
文件恢复处理模块21,用于在文件恢复阶段,选择恢复时间点,根据恢复时间点、源端路径、备端路径于文件同步记录中查找出相应的备份记录,根据备份记录中的版本信息及源备端路径得到所要恢复文件的真实存储路径,从而获取对应文件。
具体地,文件恢复处理模块21进一步包括:
备份记录查询单元210,用于根据备份时间表选择恢复时间点,根据所要恢复的时间点、源端路径ID、备端路径ID分页查询备份记录,根据查询结果将对应文件的属性信息加入待传输文件列表。
在本发明具体实施例中,当进行文件恢复时,根据备份时间表选择一个回复时间点,获取用户输入的源端路径及备端路径查询备份记录,优选地,为了节省内存消耗,备份记录查询单元210采取分页查询备份记录,例如针对海量文件每次查询1000条记录,直到查询完符合条件的记录。每次查询完一页的备份记录需遍历这些记录从记录中根据备份时间点取出相关版本信息,将需传输的文件加入待传输文件列表。本发明中,查询备份记录的参数主要有源端路径和备端路径以及恢复时间点。由于子目录的路径id包含父级目录的路径id,根据该特征可以查找出文件夹及子目录中所有文件的备份记录,由于文件同步记录中记录的是源端路径ID及备端路径ID,因此,首先根据源端路径和备端路径确定源端路径ID和备端路径ID,例如D: \2\gh这个路径,首先分割下一级,二级,三级目录分别是D:、2、gh,然后分别到各级目录表中去查找对应的路径对应的id。假如D:对应的是1,2对应的是8,gh对应的是D,那么对应的路径id就是1-8-D(每级目录id是36进制即1到9加上A到Z),根据所要恢复的时间点、源端路径ID、备端路径ID、分页参数recordId于所述文件同步记录中查询备份记录,根据查询结果从备份记录中取出相关版本信息,并将对应的文件的属性信息加入待传输文件列表。需说明的是,由于子目录的路径id包含父级目录的路径id,根据该特征可以查找出文件夹及子目录中所有文件的备份记录,例如D:\abc\vb\fg与D:\abc\vb\fg\dd两个路径,他们对应的id分别为1-1-2-3和1-1-2-3-4,当需要查询D:\abc\vb\fg目录及其子目录下所有文件的记录,只需条件输入srcPathId like 1-1-2-3*即可。
遍历恢复单元211,用于遍历待传输文件列表,对每个所要恢复的文件,根据版本信息及源备端路径得到所要恢复文件的真实存储路径,从而获取对应文件。
在此过程中,根据备份记录中的源端和备端路径以及版本信息,根据转换规则得到该文件的真实存储路径,具体地,根据预设转换规则和文件的修改时间戳将待下载文件的源路径转换成文件的真实存储路径,需说明的是,下载过程中的源路径则是上传过程中的备端路径,即记录在备份记录中的唯一key,对备份记录中的备端路径根据预设规则转换为另一条路径,然后与文件名和时间戳(根据文件同步记录的versionIds)结合得到待下载文件的真实存储路径,并从真实存储路径下载文件至本地。
实施例
如图3所示,在本实施例中,文件上传流程如下:
第一步,在扫描并传输文件之前首先保存本次执行的时间点。恢复到某一个时间点是指将该文件夹下的文件恢复到这次上传到对象存储的版本。该时间点既存放于存放所有执行时间点的表中,也存放于备份记录的backupTimes中用于记录该文件在哪一次被上传过。
第二步,扫描并比较源端与备端文件列表。该过程主要是确定哪些文件需要上传至对象存储,以及确定源端有哪些文件被删除,其中备端缺失的文件和源端修改过的文件加入待上传文件列表,源端已经删除的文件需要根据源端路径与备端路径以及文件名去elasticsearch中修改对应的最新记录,并将lateFlag改为0,以及deleteTime改为本次执行的时间,需说明的是,在恢复文件时如果deleteTime大于所选择的备份时间点时该记录是有效的。
第三步,循环遍历待上传文件列表
上传文件:上传的文件主要包括备端缺失的文件和源端修改过的文件。每个文件上传至对象存储后,都需要保存一个备份用于将来恢复特定时间点之前的文件,即,将该文件在对象存储的唯一key根据特定规则映射成唯一的新路径(比如:新唯一key =“backup/” + “旧唯一key以#&#代替文件名中的点形成的字符串” +” /” + “文件修改时间戳-文件名”),拷贝该文件至新的唯一key。
添加备份记录:首先,根据源端路径与备端路径(备端路径为文件在对象存储的唯一key) 于分级目录表查找出源端路径与备端路径的id,也就是说,源端路径与备端路径采取分级目录的方式。每一级目录都独立生成id,生成的id是36进制的字符,每级目录之间以”-”号隔开,子目录的id包含父级目录的id;其次,根据源端路径id、备端路径id、文件名、上传后的文件名查找elasticsearch数据库中是否有相关记录,如果无相关记录则直接***记录,如果有相关记录并且记录中的备份时间点小于100个则将本次的版本信息和备份时间点叠加在versionIds和backupTimes后面,并修改maxTime为本次执行时间;如果有相关记录且记录中的备份时间点个数大于等于100个则将查到的记录maxTime改为本次执行时间点减1,lateFlag改为0,并***一条新记录。
在本实施例中,假设,对于源端文件a,b,第一次执行a、b同步,执行前源端a、b,执行后备端a、b,唯一key变换后路径下也有对应的文件。(例如a的唯一key:dtotest:/abc/f/a,变换后新唯一key:dtotest:/backup/abc/f/a/时间戳-a,文件每次修改后时间戳必不一样),第一次执行a、b同步后,备份记录表记录如下表1所示(本实施例中假设用于记录过多时分页查询的recordId没有使用,用于一个文件多次同步的latestFlag也未使用,并假设文件名和同步后文件名称一样):
表1
假设第二次执行改a文件、增c文件、删b文件。执行前源端有a、c文件,执行后备端a、b、c文件,此时,备份记录表如下表2:
表2
假设第三次执行改c文件,执行前源端有a、c文件,执行后备端有a、b、c文件,备份记录表如下表3:
表3
假设,第四次执行增d文件,执行前源端有a、c、d文件,执行后有备端a、b、c、d文件,备份记录表如下表4:
表4
以上备份时间点btime1<btime2<btime3<btime4
如图4所示,在本实施例中,恢复历史数据流程如下:
第一步,选择恢复时间点,获取输入的源端路径、备端路径,根据源端路径、备端路径、恢复时间点、参数recordId(程序中的,第一次设置为0)分页查找出相关记录。首先根据源端路径、备端路径从分级目录表得到源端路径和备端路径的id,再以以下条件查出相关备份记录:(1)srcPathId like 源路径id*。(2)destPathId like 备端路径id*。(3)deleteTime 大于备份时间点或者deleteTime等于0。(4)恢复时间点大于minTime并且小于maxTime或者maxTime小于恢复时间点并且lateFlag等于1。(4)recordId大于参数recordId(第一次recordId为0,之后recordId为上一次查找到的记录中最大的recordId),遍历每次查询出的备份记录,从备份记录中找出本次需要恢复的文件的版本信息,versionIds是将versionId以逗号拼接,backupTimes是将backupTime以逗号拼接两者所包含的versionId和backupTime个数相同且backupTime中的时间戳时按照由小到大的顺序排列。从backupTimes中找出小于等于恢复时间点且小于恢复时间点的backupTime。该backupTime所在的位置就是versionIds中要恢复的文件的versionId位置(versionId中包含了文件的修改时间戳),将需要下载的文件的属性信息加入待下载文件列表。
第二步,遍历待下载文件列表下载文件,根据备份记录中的源端和备端路径以及version版本信息,根据前述的预设转换规则则可以找到该文件真正的下载地址,即该文件的新唯一key(例如:新唯一key = “backup/” + “旧唯一key以#&#代替文件名中的点形成的字符串” +” /” + “文件修改时间戳-文件名”),并根据文件的新唯一key下载相关文件。
在本实施例中,选择恢复时间点为btime1可以搜索出ab两个文件的记录,可以找出a备份时间点为:btime1版本:a-version1.b备份时间点为btime1版本b-version1.
选择恢复时间点为btime2可以搜索出ac两个文件的记录。可以找出a备份时间点为:btime2版本:a-version2.c备份时间点为btime2版本c-version1.
选择恢复时间点为btime3可以搜索出ac两个文件的记录。可以找出a备份时间点为:btime2版本:a-version2.c备份时间点为btime3版本c-version2.
选择恢复时间点为btime4可以搜索出acd三个文件记录。可以找出a备份时间点为:btime2版本:a-version2.c备份时间点为btime3版本c-version2.d备份时间点为btime4版本d-version1。
最后,根据版本信息versionId中的时间戳以及源端和备端路径id,根据预设转换规则得到转换后的路径,即待恢复文件的真实存储路径,并从转换后的真实存储路径下载对应的文件至本地。
上述实施例仅例示性说明本发明的原理及其功效,而非用于限制本发明。任何本领域技术人员均可在不违背本发明的精神及范畴下,对上述实施例进行修饰与改变。因此,本发明的权利保护范围,应如权利要求书所列。
Claims (10)
1.一种基于对象存储的恢复历史数据的方法,包括如下步骤:
步骤S1,记录本次上传文件的时间点,扫描源备端文件并对比确定需上传的文件并将其上传至对象存储,对不支持版本控制的对象存储,给每个上传的文件添加一个副本,同时于文件同步记录中对每个上传的文件添加备份记录;
步骤S2,在文件恢复阶段,选择恢复时间点,根据恢复时间点、源端路径、备端路径于所述文件同步记录中查找出相应的备份记录,根据备份记录中的版本信息及源备端路径得到所要恢复文件的真实存储路径,从而获取对应文件。
2.如权利要求1所述的一种基于对象存储的恢复历史数据的方法,其特征在于,步骤S1进一步包括:
步骤S100,在批量上传文件之前记录本次上传文件的时间点,以用于恢复文件时选择对应的恢复时间点;
步骤S101,扫描源端和备端文件进行对比,确定需上传的文件,并将需上传的文件加入待上传文件列表;
步骤S102,循环遍历待上传文件列表,将所述待上传文件列表中的文件一一上传至对象存储,并于所述文件同步记录中更新所上传文件的备份记录,对不支持版本控制的对象存储,根据当前上传文件的唯一key利用预设转换规则映射一个新唯一key,并拷贝该当前上传文件至该新唯一key。
3.如权利要求2所述的一种基于对象存储的恢复历史数据的方法,其特征在于:于步骤S101中,通过扫描源端和备端文件进行对比,将备端缺失的文件以及源端已经修改过的文件加入所述待上传文件列表。
4.如权利要求3所述的一种基于对象存储的恢复历史数据的方法,其特征在于:于步骤S101中,通过扫描源端和备端文件进行对比,对于源端被删除掉的文件,将该文件于所述文件同步记录中的备份记录进行逻辑删除。
5.如权利要求4所述的一种基于对象存储的恢复历史数据的方法,其特征在于:于步骤S101中,对于源端已经删除的文件,根据备端路径和/或源端路径以及文件名更新所述文件同步记录中该文件对应的备份记录,并将其latestFlag改为0,以及deleteTime改为本次执行的时间。
6.如权利要求5所述的一种基于对象存储的恢复历史数据的方法,其特征在于:于步骤S102中,对于第一次同步的文件,于所述文件同步记录添加该文件对应的备份记录,对于已经添加过备份记录的文件则对旧记录进行对应的修改。
7.如权利要求6所述的一种基于对象存储的恢复历史数据的方法,其特征在于:于步骤S102中,根据源端路径、备端路径、源端文件名、上传后文件名查询所述文件同步记录中是否有相关记录,若无相关记录则直接***记录,若有相关记录并且记录中的备份时间点的个数小于预设值,则将该文件的本次版本信息和备份时间点叠加在文件版本号和备份时间点后,并修改备份记录中maxTime为本次执行时间;若有相关记录且记录中的备份时间点个数大于等于100个,则将查到的备份记录的maxTime改为本次执行时间点减1,latestFlag改为0,并***一条新记录.面。
8.如权利要求2所述的一种基于对象存储的恢复历史数据的方法,其特征在于, 步骤S2进一步包括:
步骤S200,根据备份时间表选择恢复时间点,根据所要恢复的时间点、源端路径ID、备端路径ID分页查询分页查询备份记录,根据查询结果从备份记录中取出相关版本信息,并将对应的文件加入待传输文件列表;
步骤S201,遍历所述待传输文件列表,根据各待传输文件的版本信息及源备端路径得到所要恢复文件的真实存储路径,从而获取对应文件。
9.如权利要求8所述的一种基于对象存储的恢复历史数据的方法,其特征在于:于步骤S201中,根据所述待传输文件列表中待恢复文件版本信息的文件修改时间戳以及待恢复文件的源备端路径进行根据预设转换规则映射得到待恢复文件的真实存储路径。
10.一种基于对象存储的恢复历史数据的***,包括:
上传文件处理模块,记录本次上传文件的时间点,扫描源备端文件并比对确定需上传的文件并将其上传至对象存储,对不支持版本控制的对象存储,给每个上传的文件添加一个副本,同时于文件同步记录中对每个上传的文件添加备份记录;
文件恢复处理模块,用于在文件恢复阶段,选择恢复时间点,根据恢复时间点、源端路径、备端路径于所述文件同步记录中查找出相应的备份记录,根据备份记录中的版本信息及源备端路径得到所要恢复文件的真实存储路径,从而获取对应文件。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202410106647.6A CN117992280A (zh) | 2024-01-25 | 2024-01-25 | 一种基于对象存储的恢复历史数据的方法及*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202410106647.6A CN117992280A (zh) | 2024-01-25 | 2024-01-25 | 一种基于对象存储的恢复历史数据的方法及*** |
Publications (1)
Publication Number | Publication Date |
---|---|
CN117992280A true CN117992280A (zh) | 2024-05-07 |
Family
ID=90892705
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202410106647.6A Pending CN117992280A (zh) | 2024-01-25 | 2024-01-25 | 一种基于对象存储的恢复历史数据的方法及*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN117992280A (zh) |
-
2024
- 2024-01-25 CN CN202410106647.6A patent/CN117992280A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2139693C (en) | Summary catalogs | |
US20220147488A1 (en) | System And Method For Synchronizing File Systems With Large Namespaces | |
US8255430B2 (en) | Shared namespace for storage clusters | |
US7343412B1 (en) | Method for maintaining and managing dynamic web pages stored in a system cache and referenced objects cached in other data stores | |
US20050182785A1 (en) | Smart database | |
CN106874383A (zh) | 一种分布式文件***元数据的解耦合分布方法 | |
US8868491B2 (en) | Method and system for using global equivalency sets to identify data during peer-to-peer synchronization | |
CN109376121B (zh) | 一种基于ElasticSearch全文检索的文件索引***及方法 | |
WO1997024678A1 (en) | Application independent e-mail synchronization | |
CN101356527A (zh) | 通过节点编号的文件***转储/恢复 | |
US20110167093A1 (en) | Address list system and implementation method thereof | |
US20040098539A1 (en) | Method for efficient caching and enumerating objects in distributed storage systems | |
JP2012531688A (ja) | メタデータに従ってファイルシステムのファイルにアクセスする方法、およびその方法を実装する装置 | |
JP4136267B2 (ja) | 文書管理方法およびその方法を実施するためのプログラムを記憶した記憶媒体および文書管理装置 | |
US6055534A (en) | File management system and file management method | |
CN114595286A (zh) | 一种数据同步方法、装置、电子设备及存储介质 | |
JP2001344139A (ja) | データベース管理装置 | |
CN117992280A (zh) | 一种基于对象存储的恢复历史数据的方法及*** | |
JP3769775B2 (ja) | 分散リンク情報維持方法 | |
JP3971699B2 (ja) | 地積測量図管理装置 | |
JP4106601B2 (ja) | ディレクトリ情報への更新情報生成システム、更新情報生成プログラム | |
CN117131023B (zh) | 数据表处理方法、装置、计算机设备和可读存储介质 | |
JPH11212985A (ja) | 情報ライブラリ装置 | |
CN117931095B (zh) | 地图数据存储方法、装置、电子设备和存储介质 | |
CN111079199B (zh) | 基于区块链技术的企业信用数据截图防篡改方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |