CN105637487A - 用于数据智能存储***的实况还原 - Google Patents
用于数据智能存储***的实况还原 Download PDFInfo
- Publication number
- CN105637487A CN105637487A CN201480044623.7A CN201480044623A CN105637487A CN 105637487 A CN105637487 A CN 105637487A CN 201480044623 A CN201480044623 A CN 201480044623A CN 105637487 A CN105637487 A CN 105637487A
- Authority
- CN
- China
- Prior art keywords
- data
- analysis
- file
- metadata
- reduction
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1469—Backup restoration techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems
- G06F16/164—File meta data generation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
- G06F16/33—Querying
- G06F16/332—Query formulation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1466—Management of the backup or restore process to make the backup process non-disruptive
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
- G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Quality & Reliability (AREA)
- Mathematical Physics (AREA)
- Computational Linguistics (AREA)
- Human Computer Interaction (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
单个***合并主要数据存储、数据保护和智能。通过内联数据分析提供智能,并且关于受保护的数据和先前的分析收集数据智能和分析,并且数据智能和分析被存储在发现点中,而完全不会影响主要存储的性能。与HA处理内联进行实时分析,从而允许多种数据分析,数据分析随后被用作实况还原操作的一部分。可以在对象或块层级对数据内容进行实况还原。数据复原开始于元数据还原,随后是对于正被还原的数据的“热”区段的接近即时的访问,从而允许站点操作在还原正在进行中时继续或恢复。
Description
版权提醒
本专利文献的公开内容的一部分包含受到版权保护的资料。版权所有人不反对任何人按照其在专利商标局专利文件或记录中所出现的那样对专利文献或专利公开内容进行复制再现,但是在其他方面无论如何保留的所有版权权利。版权2013,DataGravity,Inc.。
技术领域
本公开内容涉及计算机存储***,并且更具体来说涉及统一了主要存储、数据保护和数据分析功能的方法和***中的实况数据还原。
背景技术
数据存储解决方案是大的业务,并且对许多企业有大量需求。存储解决方案常常被设计用于特定目的,并且公司常常利用分开的***作为专用于这样的目的的数据筒仓(silo),比如主要存储(块和文件)、备份存储以及用于分析的存储。这三份存储拷贝通常被保持在不同的器件上并且被分开管理。这三个筒仓之间的数据移动可能困难,这是因为在确定主筒仓与备份或分析筒仓之间发生了什么改变方面会涉及到时间。这导致尝试补偿把数据移动到备份和分析筒仓所需的时间长度的复杂备份策略。所涉及的定时涵盖了确定自从上一次捕获数据以来发生了什么改变,以及通常通过某种类型的网络把数据移动到新的筒仓。这一处理通常在主要存储***上是资源密集的,会消耗例如处理器周期、存储器、盘操作和网络带宽之类的关键主要存储资源。为此原因,去到备份和分析的数据移动常常被安排在非工作时间,并且被仔细地管理以免与日常操作发生干扰。除了在把数据移动到备份和分析***时的处理和定时难题之外,在主数据失效或丢失的情况下所需的还原操作也可能是耗时的。此外,在还原操作正在发生时,主数据通常是不可访问的。
除了前面的定时和计算问题之外,现今的分析***(比如使用Hadoop的那些分析***)在安全性和用户账户情境方面是独立于主要存储***的。这就使得针对数据访问的保护复杂化,并且通常会失去关于改变何时发生以及谁作出了改变的情境。许多***还需要多层附加的第三方软件以从数据中提取出任何信息。
备份***在传统上专注在复原点目标(RPO)和复原时间目标(RTO)上。RPO表示数据丢失的可接受风险的最大时间段——举例来说,24小时的RPO意味着在主要存储失效时,多达24小时的数据可能会被丢失并且不可复原。RTO表示在失效之后在操作可以恢复之前对应于复原的最大可接受时间——举例来说,24小时的RTO意味着在主要存储失效时,在主要存储被还原并且可以恢复正常操作之前,从备份的还原将花费多达24小时。
从备份***的复原或还原通常是困难且耗时的处理。从备份复原通常需要识别文件(或文件集合)和时间标记(日期)。如果所述日期或文件是未知的,则已经时间密集的还原处理变得还要复杂得多。在不知道所述文件和日期的情况下,在备份***内搜索数据以识别出所期望的还原通常是试错处理,比如挑选某一日期,从该日期开始还原备份,搜索所还原的数据以识别出所述数据是否包括所期望的项目,并且重复所述处理直到找到所期望的项目为止。
一旦识别出所期望的文件,则还原处理开始。通常直到完成了整个还原处理才准许对于文件的访问。这可能会导致在用户可以开始使用所还原的数据之前许多分钟或者甚至数小时的等待时间。由于在存储备份数据时所使用的存储优化技术,这一时间可能会被大大延长。举例来说,为了最大化备份容量,备份可能被压缩,从而需要密集的(并且常常是整个站点(complete-site)的)还原来复原单个文件。
有一种趋势是把备份和分析***合并到将备份数据用于分析的单个***中。在这方面遇到了另外的问题,这是因为备份***通常并不按照与主要存储相同的格式来保存数据。即使格式不是问题,在移动数据以及断开主要存储与改变认识(changeinsights)之间的联系方面仍然存在问题。此外,对备份数据应用分析还没有克服关于确定改变的时间和来源(authorship)的问题。
现有技术描述
美国专利7,412,577“SHAREDDATAMIRRORINGAPPARATUS,METHOD,ANDSYSTEM”(Boyd等人,2008年8月12日)在摘要中公开了以下内容:“描述了一种可用于通过编写包含写入地址信息的日志来跟踪写入活动的网络组件。所述跟踪组件可以被使用在采用数据镜像的联网***中,以便在数据镜像不可用的时间期间记录被写入到主要存储卷的数据块地址。...在重建数据镜像时,所编写的日志可以被用来构造指向主要存储卷上的其中数据不同于所述镜像的辅助存储卷构件的块地址的列表。”这个解决方案改进了存储网络内的数据镜像。
美国专利7,756,837“METHODSANDAPPARATUSFORSEARCHINGBACKUPDATABASEDONCONTENTANDATTRIBUTES”(Williams等人,2010年7月13日)在摘要中公开了以下内容:公开了允许广泛的备份存储器件的透明桥接的方法和设备,从而使得备份软件将把中间器件识别成那些存储器件之一,并且将把其备份数据流透明地发送到该处以作为现有的标准备份处理的一部分。在接收到来自备份软件的备份数据流时,所述方法和设备提供用于分析数据流中的数据单元,收集关于这些数据单元的管理信息,并且按照易于访问的格式存储所述管理信息以供原始数据的用户和管理员进行后续审阅和查询。”这种解决方案提供了对于备份数据的索引和搜索能力。
美国专利7,937,365“METHODANDSYSTEMFORSEARCHINGSTOREDDATA”(Prahlad等人,2011年5月3日)在摘要中公开了以下内容:此外公开了用于管理与通过网络耦合到多台计算机的数据存储组件相关联的数据的***和方法。此外还公开了用于访问可以通过网络获得的文档的***和方法,其中所述文档被存储在耦合到网络的一个或更多数据存储器件上。”这种解决方案提供了对于跨包括辅助存储的多个储存库的数据的索引、搜索和访问。
美国专利申请公开2009/0083336“SEARCHBASEDDATAMANAGEMENT”(Srinivasan,2009年3月26日)在摘要中公开了以下内容:“本发明包括一种***,所述***包括:包括数据项目的一个或更多存储器件;用于把元数据与每一个数据项目相关联的元数据加标签组件;根据元数据来定义一项或更多项数据管理策略的策略组件;用于生成满足数据管理策略的数据项目列表的搜索引擎;以及用于对由搜索引擎生成的数据项目列表中的每一个数据项目应用数据管理策略的数据管理应用。”这种解决方案对于“数据项目的优先权……、所有者……、群组……、上一次访问时间……、上一次修改时间……、创建时间……、归档时间……、逻辑位置……、和物理位置”创建元数据。对元数据实施搜索,并且对搜索结果应用备份、保留和归档规则。
美国专利8,055,745“METHODSANDAPPARATUSFORACCESSINGDATAFROMAPRIMARYDATASTORAGESYSTEMFORSECONDARYSTORAGE”(Atluri,2011年11月8日)在摘要中公开了以下内容:一种用于为一个或更多联网的主机节点提供辅助数据存储和复原服务的***包括:用于促进数据备份和复原服务的服务器应用;可由服务器应用访问的第一数据存储介质,可由服务器应用访问的第二数据存储介质;用于把由第一数据存储介质分配的写入位置映射到表示第一数据存储介质的逻辑视图的写入位置的至少一个客户端应用;以及实现服务器应用对于第一数据存储介质的直接读取能力以用于后续的基于时间把所读取的数据存储到辅助数据介质中的目的的至少一条机器指令。”这种解决方案在主要与备份存储之间划分(镜像)数据,从而提供连续的备份而不是离散的(备份窗口)备份。跟踪包括特定于每一个数据帧的“源地址、目的地地址、LUN、帧序列号、偏移位置、有效载荷长度以及接收时间”的元数据,其细节被使用在验证和压缩中。
欧洲专利公开EP0410630B1根据摘要公开了一种用于使用一种算法在应用或***管理存储情境中安排数据集合的存储备份的设备和方法,不同于在现有技术的完全、递增或组合备份策略情况下所使用的数据和间隔,在所述算法中涉及的数据更少并且备份间隔(窗口)更小。递增备份策略对于涉及影响每一个数据集合及其存储群组的上一次备份、上一次更新和当前日期的一对可调节参数是敏感的。
美国专利公开2006/0117048根据摘要公开了一种用于在过滤器的元数据文件被还原之后更新过滤器的数据的方法和***。过滤器保持去到元数据的开放句柄,直到过滤器接收到使元数据还原的请求为止。过滤器随后关闭所述开放句柄,并且允许还原元数据。在元数据被还原之后,基于所还原的元数据重建与所述过滤器相关联的数据。
美国专利公开2013/0054523根据摘要公开了从由来源服务器管理的来源存储复制到由目标服务器管理的目标存储的数据对象。在来源服务器处建立将要复制到目标服务器的对象的来源列表。对目标服务器进行查询,以便获得目标服务器处的对象的目标列表。建立复制列表,其表明将要传输到目标服务器的未被包括在目标列表上的来源列表上的对象。对于复制列表中的每一个对象,把对应于尚未处在目标存储处的对象的数据发送到目标服务器,并且把关于所述对象的元数据发送到目标服务器,以使得目标服务器把所述元数据包括在目标服务器复制数据库中的对应于所述对象的条目中。把对应于所述对象的条目添加到来源服务器复制数据库。
美国专利7,376,895根据摘要公开了一种用于生成、存储和取回数据文件的集成多应用数据处理***,每一个数据文件具有数据单元的多维阵列,并且公开了一种程序框架,所述程序框架提供用于至少一个应用程序的共同用户接口以便与一个或更多数据文件进行用户交互。可以包含单个数据对象(单个数据对象包括对象类型代码和对象内容)的每一个数据单元关于由所述***生成的数据文件中的所有单元具有唯一的多维单元地址。所述对象内容可以是独立的,和/或按照其他数据对象的对象内容定义的。
美国专利7,552,358根据摘要公开了一种用于使用元数据映射高效备份和还原的方法,其包括在辅助主机处保持与主要主机的主要数据对象相关联的第一备份聚合,其中第一备份聚合包括存储在辅助主机处的辅助数据对象内的主要数据对象的第一备份版本。所述方法还包括生成第二备份聚合,其中第二备份聚合包括主要数据对象的第二备份版本以及对应于辅助数据对象的备份元数据对象。备份元数据对象包括指向第二备份版本的指针。所述方法还可以包括还原辅助数据对象,其中所述还原包括使用所述指针来访问主要数据对象的第二备份版本以便还原辅助数据对象的至少一部分。
美国专利8,032,707根据摘要公开了用于管理高速缓存元数据的技术,其提供存储介质(例如盘存储)上的地址与数据项目被存储在的高速缓存器件上的相应地址之间的映射。在一些实施例中,高速缓存元数据可以被存储在包括多个分级层级的分级数据结构中。可以仅把所述多个分级层级当中的一个子集加载到存储器,从而减小了高速缓存元数据的存储器“足迹(footprint)”,并且加快了在启动操作期间还原高速缓存元数据的处理。还可以通过使用高速缓存元数据来实施与重启相关联的操作来进一步加快启动。随后,随着使用高速缓存元数据处理针对读取存储介质上的数据项目的请求以便识别出所述数据项目被存储在高速缓存中的地址,可以把所识别出的地址存储在存储器中。
美国专利8,140,573根据摘要公开了可以基于数据库实例和用户定义的最大深度自动生成元数据文件。构成业务对象的数据对象之间的关系可以被显现在树中。最大深度限制将要遍历的树中的层级的数目。元数据文件描述业务对象的结构以及构成业务对象的数据对象集合之间的关系。在元数据文件中定义的结构可以被用来从数据库导出业务对象的实例。所导出的业务对象实例可以被导入到另一个数据库。
发明内容
前面的内容都没有提供具有以下特征的存储解决方案:1)集成的主要存储、数据保护和数据分析,数据分析使用所述分析作为实况还原处理的一部分;2)作为第一步骤还原元数据,从而在整个文件、目录、块或站点层级还原操作完成之前即时允许访问对象;3)基于先前收集的内联(in-line)分析对正被还原的用户数据的区段进行优先权排序;4)使用还原链接数据结构来保持主要储集池中的正被还原的文件、智能储集池中的其来源数据以及包含先前收集的分析的发现点数据之间的关系;5)对于站点层级处的类似还原高效地使用实况块层级还原操作,而完全不需要单独的备份数据流或者附加的服务器和软件来协调多个***之间的操作。因此,需要的是一种克服前面提到的限制并且包括前面所列举的特征的解决方案。
这里所公开的技术把主要数据存储、数据保护和智能合并到单个统一的***中。所述统一***提供主要存储、分析和基于分析的数据保护,而不需要针对每一个方面的单独的解决方案。通过内联数据分析来提供智能,其中附加数据智能和分析在受保护的数据以及先前的分析上收集,并且被存储在发现点中,而完全不会影响主要存储的性能。随着数据被写入,其作为高可用性(HA)处理的一部分被镜像。随着HA处理内联地进行实时分析,从而允许多种数据分析。可以从文件或块内挖掘数据内容。所收集的智能被用来利用扩展元数据为对象加标签,从而允许有价值的搜索选项和快速还原选项全部二者。数据复原开始于元数据还原,随后是对于正被还原的数据的“热”区段的接近即时的访问,从而在还原正在进行的同时允许站点操作继续或恢复。
对于所公开的***,主要存储处理器与智能处理器相结合地工作,从而在分开的盘集合上存储和保护数据,同时在创建数据时收集智能。因此,所公开的存储***管理主要和HA流数据、提取关于数据的信息的能力、数据使用,并且收集围绕数据内容的分析。通过使用单个HA存储***来管理所有的事项,通常是休眠的或者利用率不足的处理器和IO容量可以被投入使用以用于收集数据智能、数据保护以及递送搜索和分析。数据提取可以包括元数据提取、内容提取以及细粒度块层级访问和改变跟踪。对于基于文件的主要存储,分析可以在写入数据时跟踪文件和元数据改变,包括块层级改变。对于基于块的主要存储,分析可以跟踪块层级访问和改变。此外,所述***能够在更高层级应用流情境中理解数据,并且在块层级实施类似于文件层级分析的跟踪和分析。这样就例如对于正被存储到数据库的数据实现了流层级分析。随着数据被写入到智能存储,对于数据智能并行地分析处于存储器中的所述数据的拷贝。不同于受到数据移动速度约束的传统***,这种架构允许对于数据的快速处理。通过使用对于数据的这种初始智能扫描,随后可以对数据进行后处理以便收集更多深度认识。
对于末端用户,分析是接近实时地可用的。经过预处理的数据被存储为针对个体数据对象的递增元数据,并且被存储在可以被查询的单独的数据结构中。不同于传统的数据分析***,智能并未与原始数据来源完全分开。分析元数据被存储在发现点内。每一个发现点包含对与该发现点相关联的被访问和改变的数据的分析,并且可选地包含自从先前的发现点以来已经改变的数据的拷贝。通过保持最常被使用的智能以作为元数据的一部分,所公开的***大大减少了对于末端用户的针对智能的请求的响应时间。所述***还可以访问数据的附加特征:谁访问了或者作出了数据改变,以及数据何时被访问或改变。这些附加特征允许所述智能***提供用于搜索和分析的附加情境。
HA流被用来创建智能数据,从而为顾客数据的数据分析和实时保护全部二者提供了来源。通过所述智能***基于智能数据而不是主要存储数据来创建发现点,从而在发现点创建期间消除了对于主要存储的影响。发现点被存储在与主要数据流的存储分开的存储介质上。发现点创建可以基于时间,但是也可以基于自适应日程安排通过分析法来实施。这一自适应行为通过随着时间活跃地监测访问、改变和改变率而实现。这是在共享或卷层级进行的,并且可以考虑到谁拥有以及谁访问数据。所述自适应日程安排可以作为在总数据上或者在总数据的指定部分上达到百分比改变的阈值的结果而创建发现点,或者基于随着时间的数据改变率的历史分析在检测到数据改变数量中的异常之后创建发现点。
把数据保留在发现点内实现实况数据复原处理。但是从复原的角度来看,传统的RPO被改变。发现点是基于智能数据创建的,这在发现点创建期间消除了对于主要存储的影响。这样就实时地保护数据,从而把RPO减小到零。
此外,所述***还把RTO最小化到接近零。
对于还原数据有两个选项是可用的——对象层级还原或全站点还原。
对象层级还原使用关于发现点内的对象的数据和智能元数据来复原元数据。对象可以是文件、目录、文件共享、卷或者复杂对象内的文件或目录,比如虚拟机盘(VMDK)内的文件***内的文件或者档案内的目录。一旦对于主要存储还原了元数据,所述对象就对于末端用户表现为被还原,其中输入/输出(I/O)访问被准许。对象内的“热”数据(比如正在由末端用户活跃访问或者被识别成基于先前随着时间收集的分析而针对快速复原按优先权排序的用户数据)被优先还原到主要存储,而任何其余的数据则以较低优先权被回填(back-fill),从而确保对象将被完全还原。在还原期间在对象内被访问的数据可能具有微小的访问性能降低,但是所还原的对象的可用性是接近即时的。
站点层级还原是为了例如在主要存储的整体或部分失效之后复原整个站点或者站点的一部分。站点层级还原的即时性不如对象层级还原,但是其被构造成允许站点操作快速地恢复,可能是在几分钟内恢复。传统的RTO是以天数和小时数来测量的。对于站点层级还原,对于正被还原的站点快速地重新创建内部***元数据,此后末端用户可以访问数据。如对象层级还原情况中一样,正在被活跃访问或者通过分析法识别出的“热”数据针对数据还原被给予优先权,而其他数据则以较低优先权被回填,从而保证最终的完全还原并且同时还允许对于所复原的功能的快速访问。站点层级还原通常被实施成块层级操作,其由于所需要的元数据的更大规模而在末端用户操作可以继续之前可能会花费比对象层级还原更长的时间。
对于对象或站点层级还原,在还原正在进行的过程中,可以作出新的数据改变。即使整个还原还没有完成,所有新的改变也被跟踪和保护并且分析被收集。
特征和优点
所公开的***把主要存储、数据分析、数据保护和复原组合到一个***中。
除了传统上在主要存储环境中所找到的那些之外,所公开的***不需要部署附加的数据流、附加的服务器或其他装置或者附加的软件。
所公开的***实时地跟踪数据改变,这去除了实施数据保护所需要的预处理,并且避免了用以检测改变的数据后处理或者针对数据改变查询应用服务器。
所公开的***创建所存储的数据的全文本索引,连同对数据进行分类的自动创建的元数据标签。这一加标签增强了数据发现处理。
所公开的***把对应于被访问和改变的数据的分析元数据以及可选地还有数据改变保留在发现点中。
所公开的***把发现点创建扩展成基于时间、基于百分比并且在分析上是自适应的。所述***保持从上一个发现点以来的内容改变的当前工作版本,从而消除了主要存储失效上的任何丢失风险窗口。
所公开的***去除了备份窗口和备份日程安排。
所公开的***通过主要数据的实时冗余性提供即时的数据保护。
所公开的***创建所存储的数据的特定于内容的智能,从而允许对于所期望的发现点和其中的数据的快速搜索和识别。
基于对所收集的数据智能的搜索,所公开的***允许实时的选择性还原。
所公开的***跟踪随着时间对数据的操作行为的丰富设置(richset),比如用户的访问模式,以便允许跟踪内容到人的映射图。
除了站点上数据保护之外,所公开的***还可以包括站点外归档存储,从而允许快速复原和长期存储全部二者,同时在本地站点上保持接近即时的还原、分析和可搜索性。
所公开的***允许数据智能收集和分析,而对于主要存储性能或可用性没有任何影响。
所公开的***提供允许第三方数据智能包的连接的编程接口。这包括定制定义的应用编程接口(API)以及使用传统的文件和块访问来管理(比如搜索)查询状态等等以及取回分析。
所公开的***允许对于正被还原的数据(比如个体文件、目录或文件***)的接近即时的访问。
在完全的主要或智能***丢失的情况下,所公开的***大大减少了在发起全站点复原之后恢复操作的时间。
附图说明
在附图中,紧密相关的附图和项目具有相同的附图标记但是具有不同的字母下标。处理、状况、状态和数据库针对其对应的功能被命名。
图1是示出了主要节点、智能节点和远程智能节点之间的交互以及所连接的存储储集池的图示。
图2是包含主要节点和智能节点的装置器件的视图。
图3是示出了主要节点的组件的图示。
图4是示出了智能节点的组件的图示。
图5是示出了分析流程处理的图示。
图6A是示出了改变编目的结构的图示;图6B示出了发现点。
图7是示出了可用存储的自适应分配的图示。
图8是示出了从主要节点到智能节点再到远程站点的数据保护流程的图示。
图9是示出了独立部署中的主要节点和智能节点的图示。
图10是示出了共享部署中的主要节点和智能节点的图示。
图11是示出了从智能节点或远程站点到主要节点以及从远程站点到智能节点的数据还原流程的图示。
图12是示出了用于数据还原的处理流程的图示。
图13示出了用于在用户写入(WRITE)正在进行中的同时还原单个对象的文件层级实况还原处理。
图14是用于文件的实况还原的算法。
图15是用于准备文件以供实况还原的算法。
图16是为实况还原准备的文件的一个实例。
图17是用于处置针对仍然处在正被实况还原的过程中的文件的用户I/O的算法。
图18是用于目录层级还原的算法。
图19示出了将要使用块层级实况还原来还原的站点中的各个存储层。
图20是用于块层级实况还原的算法。
图21是使用位图来跟踪状态的块还原的一个实例。
图22示出了元数据和用户数据逻辑分离。
图23是站点层级还原算法。
图24示出了进行过程中的还原实况站点的状况。
具体实施方式
术语
现有技术的术语和定义不一定与这里使用的术语和定义一致。如果存在冲突的话,下面的定义适用。
本申请涉及实况还原技术,并且特别涉及如何实施对象层级实况还原和块层级实况还原。本申请还将涉及先前所收集的随着时间的分析如何能够允许在实况还原期间对“热”区段进行优先权排序。在这里,“热”区段的定义从传统的基于访问的定义被改变到替换地考虑内容、身份、规则等等。
术语
现有技术的术语和定义不一定与这里使用的术语和定义一致。如果存在冲突的话,下面的定义适用。
主要存储:可由多台计算机/工作站访问的联网存储。所述存储可以通过任何联网的器件作为文件或块来访问。除非明确地声明,否则“主要存储”指的是块和文件二者。
智能存储:包含所收集的智能、发现点以及包含在主要存储中的文件和块数据的冗余实时拷贝的辅助存储。
主要节点:包括:用以与智能节点、远程站点和扩展节点通信的访问协议;访问协议层(例如NFS、SMB、iSCSI);实时保护和分析(“PART”)层;文件和块存储层(文件***、块卷);以及去到存储器件(RAID、DISK等等)的连接。主要节点对于***用户表现为主要存储,并且提供用以充当对于智能存储的访问的接口和控制。
智能节点:包括:用以与主要节点、远程站点和扩展节点通信的访问协议;数据智能存储层(智能数据服务和规则处理);文件和块存储层(文件***、块卷);以及去到存储器件(RAID、长期存储)的连接。在优选实施例中,智能节点数据由用户通过主要节点访问,但是在替换实施例中,智能节点可以由用户直接访问。
发现点:从主要数据的镜像(高可用性)拷贝创建的发现点包含对应于自从先前的发现点以来被访问和改变的主要数据的数据分析。发现点可以包含发生了改变的数据,从而提供在用户指定的时间点捕获或者基于改变率或其他分析动态地捕获的主要数据的实际上完全但是物理上稀疏的拷贝。虽然在发现点被创建之后主要数据在所述发现点内没有发生改变,但随着实施更深层级的用户数据分析以及收集更多的分析,可以扩展存储在发现点中的分析元数据。所跟踪的主要数据改变可以在发现点的生命期内被保留或者可以按照安排的或者动态的间隔被去除,比如在深度数据分析完成并且获得所期望的分析元数据之后被去除。去除主要数据允许更加高效的空间利用,而保留主要数据则允许该数据版本的时间点复原。
改变编目:以发现点粒度(granularity)跟踪的与数据对象有关的实时访问和改变信息的有序集合。改变编目跟踪数据对象的各方面被谁、如何、何时以及在何处被访问和/或修改。对于每一个发现点有一个改变编目。
远程站点:与本地站点主要或智能节点通信的一个或更多站点外节点。
储集池:连接到节点的数据存储的集合。
对象:文件、目录、共享、卷、卷内的区段或者嵌入式对象。对象可以是复杂的,包含其他嵌入式对象。举例来说,一个文件可以是包含其他文件的容器,或者一个卷在其之上可以具有文件***,所述文件***又包含文件。所述***能够辨识复杂对象,并且以更加精细的嵌入式对象粒度跟踪改变。
选择性还原:对象层级处的自动(基于策略)或人工(顾客发起)还原。
站点还原:用以使用正被复原的数据的先前受保护的版本重新创建主要或智能储集池内容的人工发起的处理。
容器:可以具有其他嵌入式对象的对象,比如文件、目录、文件***或卷。
扩展节点:具有处理器、存储器(RAM)、网络连接性以及存储器件的装置,并且连接到一个或更多主要或智能节点从而缩放针对所连接的节点的处理能力和/或存储。
操作
在后面的详细描述中参照构成本发明的一部分的附图,并且其中作为说明示出了可以在其中实践本发明的具体实施例。应当理解的是,可以使用其他实施例,并且在不背离由权利要求书限定的本发明的范围的情况下可以作出结构方面的改变。
所公开的高可用性(HA)存储***提供主要存储、分析和实况还原功能。实况还原是被用来优化数据还原的技术。其可以被用来在发生失效的情况下复原用户数据或者复原用户数据的先前版本。所述***提供作为块和/或文件层级存储的主要存储访问,同时避免单个失效点。所述***实时地收集分析同时还在分开的物理介质上实时地保护数据,并且包括用于站点外数据保护的选项。所述***实施深度分析从而允许还原、存储和数据智能,并且保护顾客数据和相关联的分析全部二者。所述***提供用于提取分析元数据的传统的基于文件的和定制API方法。所述***在文件或者在块层级采用实况还原技术,以便在发生失效的情况下进行复原,或者复原用户数据的先前版本。这样就在对象层级提供了接近即时的还原,并且在主要或智能节点完全失效的情况下(例如全站点还原)大大减少了访问前的等待时间。文件或块层级实况还原使用先前收集的分析来对将被还原的数据进行优先权排序,同时在还原期间允许对于数据的用户I/O访问。
参照图1,所述***的主要节点100在网络内连接,以便提供对于所连接的计算器件(未示出)的块和/或文件层级存储访问、实时数据保护以及对于主要数据的实时分析。从主要存储储集池110读取并且向其写入主要数据。取决于所使用的访问协议,数据可以作为文件或块被写入或读取。作为用于主要节点的HA处理的一部分,随着数据被写入,其被自动镜像和跟踪以用于数据保护。对于智能节点120创建数据的镜像高速缓存。智能节点允许数据保护、分析和复原。智能节点把主要数据的实时拷贝、分析以及发现点存储在智能储集池130内。发现点由智能节点在任一点自动或人工创建,并且基于细粒度改变数据允许即时采取动作,而不需要拷贝底层的主要数据或者进行任何后处理以确定自从任何先前的发现点以来发生了什么改变。
在一个优选实施例中,每一个节点能够充当主要节点、智能节点或全部二者。出于可靠性和性能原因,分开的主要节点和智能节点是合乎期望的。在任一个节点失效的情况下,另一个可以接管全部二者的操作。不具有双重能力的实现方式(也就是单独操作主要节点并且单独操作智能节点)是可能的,但是在这样的节点失效时将会发生(对于主要或智能存储的)服务的丢失。在一个优选实施例中,节点中的每一个具有用于存储和执行节点软件的处理器和本地存储器,去到物理存储介质的连接,以及一个或更多网络连接,其至少包括去到其他节点的专用高带宽和低等待时间通信路径。
在一个优选实施例中,主要节点和智能节点被物理地容纳在单个器件内,从而创建单个装置的用户印象。图2示出了这样的一个实例,其中主要节点100和智能节点120被容纳在一起从而表现为单个物理装置。实现方式可以具有任意数目的盘,例如诸如包含多达二十四个硬盘驱动器的四机架单元(4U)外罩,其中分开的物理存储器件连接到所述***。除了底板之外,每一个节点在内部与其他节点完全分开,其中每一个节点具有专用的(非共享的)电源、处理器、存储器、网络连接、操作介质并且可选地具有非易失性存储器。所述分离允许继续操作,例如智能节点可以在主要节点失效的情况下继续操作并且反之亦然,但是共享资源实现方式也是可能的。
主要节点
还参照图3,作为主要节点100活跃操作的节点操作存储协议服务器软件300,例如通用互联网文件***(CIFS)、网络文件***(NFS)、服务器消息块(SMB)或者互联网小型计算机***接口(iSCSI),因此主要节点对于网络连接的计算机器件将表现为主要存储。存储协议服务器软件还与实时保护和分析处理(PART)310通信,PART310拦截每一项数据访问并且对于每一项数据访问采取动作。
PART310在拦截到任何数据访问请求之后实施三个主要任务:针对HA镜像主要数据,收集关于主要数据的内联数据分析,以及存储主要数据。这里所解释的实例针对文件访问角度,但是PART可以类似地处理块层级访问。在对卷实施块访问时,PART可以识别出嵌入式对象并且实施被应用于文件层级访问的相同的分析。所拦截的访问请求包括读取、修改(写入数据或改动属性,比如重命名、移动或改变许可)、创建和删除。PART跟踪请求(和数据)并且将其镜像到智能节点。取决于配置,与智能节点的通信是通过同步或异步处理间通信(IPC)340来进行的。IPC可以包括任何适当的协议或连接,比如远程规程调用(RPC)或者可以特定于硬件的板对板(B2B)高性能、低等待时间通信路径。与数据访问请求包括在一起(比如被包括在写入操作中)的任何数据也作为HA***操作的一部分被镜像到智能节点。这一镜像通过主要存储的实时冗余性建立数据保护。此外,PART对主要数据执行内联分析,从而收集实时分析。PART把所收集的实时分析发送到智能节点,其中所述分析被添加到由智能节点保持的改变编目。除了分析之外,PART还把所述请求引导到实际的文件***,例如第四扩展文件***(EXT4)或Z文件***(ZFS),或者针对对于物理存储器件的文件或块存储访问330的块卷。
存储访问功能330(其是文件***层级或块层级)对存储介质实施访问请求,并且把结果返回到PART以用于返回到发出请求的***。在一个优选实施例中,所述存储介质包括附属于***的盘,但是其他存储介质解决方案也是可能的。
在一个优选实施例中,主要节点还包括在智能节点失效的情况下作为智能节点操作所必要的软件。
在一个优选实施例中,主要节点还操作管理软件。优选地通过浏览器接口来访问(但是可以使用任何用户接口提供方法),管理软件提供***管理员访问以便配置和管理***用户并且访问发现点以用于还原处理。
智能节点
还参照图4,作为智能节点120活跃地操作的节点操作能够与主要节点通信的处理间通信(IPC)通信软件400。所述通信软件包括API,其用以接收来自主要节点的实时分析(改变编目条目)、来自主要节点的数据改变和访问请求(读取、修改、创建、删除)、数据保护和智能控制命令以及数据还原命令。数据保护和智能控制命令包括用于创建发现点、设立用于管理发现点(包括删除)的管理规则以及搜索和还原已被备份的内容的命令。数据还原命令包括用于访问先前备份的数据的命令。
在智能节点处接收到的数据交换请求被应用于该节点的当前数据的拷贝,从而保持主要存储的实时镜像。这样就对于当前数据实施了实时数据保护。
出于数据分析和数据复原目的,智能节点保持改变编目600,改变编目600包含自从上一个发现点650以来从访问和改变的数据所收集的实时分析。还通过以下步骤来创建发现点:把改变编目与对于自从保持在智能储集池中的上一个发现点以来发生了改变的主要数据的镜像拷贝的提及相关联且存储在一起。下面提供关于改变编目和发现点的更加详细的讨论。
智能节点实施对于其自身的物理存储的储集池130的文件或块层级访问430。该智能存储储集池保留主要数据的实时拷贝和发现点。发现点内的所存储的智能数据包括接收自主要节点的内联分析(改变编目)以及由智能节点执行的附加分析410。
主要数据的实时拷贝还允许主要节点与智能节点之间的分布式响应处理。举例来说,主要节点与智能节点之间的负荷平衡可以允许更大的可缩放性。由于二者都具有主要数据的实时拷贝,因此可以在所述节点之间平衡读取请求,或者替换地将读取请求引导到全部两个节点,其中最快响应的节点被用于响应。主要节点可以充当用于这样的分布式处理的控制器,或者可以使用单独的控制器。
不要求主要数据110和智能数据130驻留在相同的装置上,他们可以被分布到全都部署相同技术的多个分立的装置,不同之处在于通过网络传输来实施所述通信方法,而不是使用阵列内的HA机制。
分析
智能是所述***的核心。在***中存在四种类型的智能功能:数据、操作、存储和复原。所有四种类型都使用相同的处理引擎和共同的分析元数据来提供在固定点处的分析并且提供随着时间收集的分析。数据智能452允许智能的用户内容管理。操作智能456分析***的行为以及存储在***上的应用日志,以便提供关于***的应用和安全性的认识。存储智能454允许智能的存储***资源管理,包括自动存储分配和再分配,包括动态地增大和缩小存储储集池。复原智能450允许智能的数据保护和数据还原。所有类型的智能都可以被用于不同类型的分析或者允许与不同类型的分析相结合的操作,不同类型的分析比如是而不限于协作、趋势(trending)、电子发现、审计、评分和相似性。
分析在主要节点处开始,主要节点跟踪数据访问和数据修改、***行为、改变率以及其他实时分析。其把这一实时分析信息提供到智能节点。智能收集确定与数据的时间和所有者关系,以用于关于所述数据的协作和情境信息。所收集的智能被用于后来的搜索和报告,并且在与数据相关联的改变编目中被跟踪。
现在参照图5并且参照图6A,作为由主要节点100实施的内联实时分析500的一部分创建改变编目600,但是改变编目600随后也由实施进一步数据处理的智能节点120进一步扩展,并且创建用于后来的搜索的基础。改变编目数据初始在主要节点处被实时地创建(比如通过PART310),并且例如包括关于特定数据访问的扩展信息,从而允许完全跟踪谁/如何/何时/在何处访问、创建、修改或删除了文件或其他数据对象。传统的文件元数据仅包括所有者、群组、路径、访问权利、文件尺寸以及上一次修改的时间标记。这样就提供了关于文件的一些但非全部信息。举例来说,其没有标识出谁修改了文件,发生了多少项修改,或者关于没有修改文件的文件访问(比如查看或读取文件)的任何信息。由主要节点操作的PART拦截每一项文件访问事件。因此,主要节点具有跟踪关于文件的扩展元数据的能力——包括通过时间标记、用户和访问类型来识别每一项修改和每一项访问,甚至并没有修改文件的那些。
还参照图6A,该扩展元数据被存储作为改变编目条目610,其标识出正被访问的对象、行动者(实施操作的用户)以及正在实施的操作。可能处于改变编目条目中的附加信息包括而不限于对象名称、所有者、访问控制列表以及操作时间。改变编目600包含该扩展元数据信息,并且充当比如后来由智能节点实施的进一步分析的基础。改变编目条目还可以包括与对象相关联的安全性信息,比如针对访问的许可权利。管理员可以配置跟踪的程度或者甚至在文件位置、用户、特定于群组的基础或者其他基础上允许/禁止跟踪,并且主要节点能够把每一项文件访问的所有细节合并到改变编目条目中。增强的元数据的这些改变编目条目由主要节点收集,并且被传送到智能节点以用于存储以及利用进一步的分析进行扩展。
现在还参照图6B,改变编目元数据跟踪也关联到发现点650的递增改变。每当创建新的发现点时,当前改变编目就被关闭并且存储在发现点内。当数据被保留在发现点中时,即使该发现点被迁移离开智能节点,所述***仍可以被配置成把发现点分析元数据的拷贝保留在智能节点处,从而允许更加高效的查询处理。
通过以下步骤来创建发现点650:把改变编目与自从智能储集池中的上一个发现点以来发生了改变的主要数据的镜像拷贝相关联并且存储在一起。在发现点创建之后,创建新的改变编目600,从而允许收集对主要数据的新的实时分析。优选地对于主要存储中的每个卷或文件***保持改变编目和发现点,但是改变编目和发现点也可以跨越多个卷或文件***。发现点允许对主要数据的时间点版本的更深度的分析,并且还可以被用来复原主要数据的先前版本。发现点包含针对自从先前的发现点以来被访问和改变的数据的数据分析。当被创建时,发现点还包含该发现点的创建时的主要数据的实际上完全但是物理上稀疏的拷贝。***使用发现点内可见的数据来实施更深度的数据处理,从而创建更多分析元数据。使用反映在改变编目中的实时分析,对自从先前的发现点以来被访问和改变的数据进行分析。这些新收集的更深度分析也被存储在发现点内。可以在发现点的生命期内保留主要数据或者可以更早将其消除,比如在深度数据分析完成并且获得了所期望的分析元数据之后消除。消除主要数据允许更加高效的空间利用,而保留主要数据则允许复原发现点的创建时间点处的主要数据。从一个发现点开始直到下一个发现点的创建为止,跟踪文件改变、删除、重命名、创建等等以作为自从先前的发现点以来的累积修改,从而只保持递增改变。这样就在每一个发现点处创建了数据的一个版本。当数据被保留在发现点中时,***能够以发现点粒度还原数据。由于与每一个发现点一起存储了改变编目,因此可以通过对于改变编目的分析获得关于发现点之间的改变历史的信息。为了还原特定时间点处的数据对象,使用发现点。对于长期存储,可以按照通过管理软件所配置的那样把发现点移动到例如磁带或站点外存储之类的长期介质。
可以通过删除发现点命令人工删除发现点,或者基于时间或分析自动删除发现点,以便节省存储空间或者用于站点外迁移。对于分析元数据的管理使得发现点的删除复杂化。存储在发现点内的分析元数据包含关于在一段时间内发生了改变的数据的信息。如果所存储的分析被删除,则其可能会丢失。为了防止这种情况,可以调节对应于与一个或更多其他发现点相关联的分析的时间段,并且来自正被删除的发现点的分析元数据的相关部分被提取并且与已经存储在其他发现点内的其他分析进行合并。
现在注意力返回到图5,在智能节点处,自适应并行处理引擎(或规则引擎420)对改变编目600进行操作,以便导出这些更加复杂的分析,包括随着时间跟踪改变和使用。规则引擎应用规则510以便分析关于底层主要数据的内容,从而允许对所存储的数据进行更深度的分析。作为一个实例,第二层级字典可以为已经被索引的文档提供情绪属性(sentimentattribute)。可以应用常规表达法处理,以便查看文档是否包含例如社会保险号码或信用***之类的信息。每一条规则可以具有用以匹配内容的过滤器530,以及将要基于结果采取的动作540。规则可以被嵌套,并且被用来回答特定于用户的问题。另一个实例可以是应用关键字出现的位置,以便针对例如“霉菌”或“水渍”之类的关键字集合来搜索对象,并且在所有的匹配中针对地址或邮政编码信息来搜索对象。规则可以由管理员或***用户配置,从而允许基于不同的可适用策略520进行动态规则创建和组合。可以通过多种方式来组合规则,以便发现更加复杂的信息。还可以基于结果针对动作来配置规则。举例来说,可以基于检测到的访问或内容设定触发通知,并且可以基于内容或访问模式或者其他所跟踪的元数据应用不同的保留策略。其他动作可以包括而不限于数据保留、隔离、数据提取、删除以及数据分发。所应用的规则的结果可以被索引或跟踪以用于将来的分析。
随着所应用的规则510识别出结果,这样的结果可以被索引或跟踪以用于其他分析用途。这一附加的元数据可以被添加到对应于相关的文件或对象的改变编目。还可以随着向对象添加定制标签来跟踪元数据。标签可以被存储作为文件的扩展属性,或者在单独的分析索引中(比如从正常末端用户视图隐藏的目录或卷中的数据)或者用于分析的其他数据存储库中跟踪的元数据。可以对于所跟踪的数据以及通过分析生成的元数据二者应用规则并且从而应用分析。这样就允许分析内容和所收集的智能二者,从而允许时间点和随着时间的分析。规则结果和动作可以充当从一条或更多条规则到一条或更多条其他规则的反馈(或者甚至针对相同的规则的自我反馈),从而允许多阶段分析和工作流程处理。
复原智能450
复原智能是由智能节点120围绕数据保护实施的分析的集合。其目的是保护数据和相关联的分析。当数据到达智能节点时,镜像拷贝被存储在智能储集池中,从而对于主要存储创建冗余性,并且跟踪这些改变以用于发现点创建。主要数据、发现点和智能数据优选地在主轴(spindle)或盘储集池层级被分离在实际的物理介质上,从而使得单个个体物理器件的失效总是可复原的。随着基于在智能节点处跟踪的改变编目创建发现点,其可以在任何时间被创建而不会对主要存储的性能造成任何影响。这样就使得不再需要用于发现点创建的日程安排时间窗口。每一个发现点包括从先前的发现点以来的递增改变,包括数据对象改变以及在这样的改变期间收集的并且与数据相关联的分析。可以应用智能规则以使得发现点创建自动化,从而使得除了人工创建或基于时间的创建之外,还可以通过内容改变来触发发现点创建。这样的改变可以是基于百分比,特定于整个数据储集池的某些可识别子集的百分比改变,基于所检测到的使用模式偏差(比如特定访问的频率增加),或者基于数据内容的实时分析。
在发现点创建时,累积实时改变的改变编目被关闭。改变编目随后被存储在所创建的发现点内,并且对于将与下一个创建的发现点相关联的改变创建新的改变编目。存储在发现点内的分析和数据允许高效的还原,从而允许在多个发现点上搜索特定对象改变,而不需要从每一个发现点还原数据对象。这样的搜索可以是基于所实施的任何分析,比如在扩展元数据中跟踪的数据,以及通过应用规则引擎来实施的基于内容的分析。所述跟踪还允许索引和部分还原——例如可以从发现点还原特定对象或者复杂对象内的嵌入式对象,而无需完全还原来自该发现点的所有数据。
数据智能452
数据智能是分析内容的智能节点处的分析集合。数据智能通过规则引擎操作,并且可以被应用于:非结构化数据,例如:诸如MicrosoftOffice文档的文档属性之类的文件元数据或者此类文档的实际内容;半结构化数据,比如日志文件或者例如邮件(Mail)程序之类的特定应用;结构化数据,比如数据库或者其模式可以由***获知或发现的其他格式;以及递归容器,比如虚拟机、文件***上的文件***、卷上的文件***或者档案。
存储智能454
存储智能是由分析整个***的智能节点实施的分析集合。存储智能通过规则引擎操作以便随着时间跟踪总的存储和***使用,以便预测使用模式并且分析容量需求。还参照图7,可以动态地调节可用的物理存储,比如主要存储110与智能数据存储130之间的物理器件的分配,从而在需要扩展之前最大化***的使用。图7中示出的实例说明了在主要储集池与智能储集池之间分配未被使用的存储的一部分。类似地,当不再被需要时,空间可以从所指派的储集池收回。举例来说,与所示出的实例相反,可以识别出被指派但是未被主要储集池使用的多余存储,并且将其从主要储集池动态地消除到备用储集池,或者直接再分配到智能储集池。这一动态分配和再分配在不会使存储可用性降级的情况下发生。动态再分配可以在数据储集池的各个部分内移动数据,以便确保这样的降级不会发生。在添加扩展时也可以应用相同的动态分配,从而允许针对存储资源的智能最大化在扩展之后继续。可以应用存储智能以便改进资源使用效率,比如识别处理需求、***使用的模式,以及在低使用率时段期间安排灵活的高需求处理。举例来说,一些规则引擎分析可以被批处理以便周期性地运行,并且基于所预测的***使用被动态地安排。
操作智能456
操作智能是通过集成存储在主要存储中的应用日志以及确定日志中的使用模式、错误和/或异常而实现的。操作智能还监测对于数据的访问模式,并且关于例如安全性问题的可能迹象之类的不一致行为向指定的管理员发出告警。
智能搜索
只有在内联分析的情况下,才允许对于即时结果(比如:谁、何时或者谁和何时访问了特定文件)的实时搜索;哪些文件被特定用户访问;访问模式是否与适当的文件访问权利一致;或者哪些文件在特定时间段内被修改(或查看)。如果附加的内联或辅助分析被允许,则智能可以被扩展成包括特定于内容的搜索。
通过用户向***提交用户搜索查询550来实施搜索,但是也把安全性纳入考虑。提供了至少两个层级的访问:超级用户(管理员)和个体用户。超级用户和个体用户被认证(例如利用活跃目录(activedirectory)或本地用户数据库)。个体用户只能够看到其在搜索时被授权的结果。个体用户权利可以由经过授权的管理员配置,或者默认为匹配现有的用户权利。举例来说,出于搜索目的对于分析的访问可以默认地被限制到与用户具有或者曾经具有访问许可的主要数据中的数据对象相关联的分析。这样就保持了与对应于主要数据的许可和安全性相匹配的智能数据的许可和数据安全性,而不需要对于智能数据的人工访问许可配置的人工账户配置。超级用户能够看到所有结果。
数据保护
还参照图8,数据保护在不同节点之间流动。顾客创建访问主要节点100的数据。智能节点120通过把主要数据的镜像拷贝存储在智能储集池130内来保护存储在主要节点100上的顾客数据。主要数据的先前版本可以被保留在发现点内,所述发现点被存储在智能储集池中,从而进一步增强主要数据保护。每一个发现点可以包括顾客数据的时间的崩溃一致(crashconsistent)快照。发现点是基于与主要存储(文件***或卷)相关联的策略520而创建的。策略使用固定数值(即所经过的时间或者数据改变百分比)或者先前收集的分析以作为用于创建发现点的主要触发。如果连接了远程站点,则数据还可以从智能节点流动到远程站点,远程站点被配置成用于远程智能800或者完全灾难复原810。
主要节点和智能节点可以被部署在独立部署或共享部署配置中,并且两种配置都可以另外被配置成与远程站点通信。对于全部两种配置,都为用户呈现单个***管理视图。还参照图9,在独立部署中,主要节点100和智能节点120作为独立分开的装置操作,其中主要节点独立于与智能节点的通信执行针对主要数据的访问请求。还参照图10,在优选的共享部署中,主要节点100和智能节点120被安装,以便仿佛作为单个物理装置由用户访问和管理,其中主要节点关于所有数据访问请求确认与智能节点的通信。对于共享和独立部署二者,在一个节点失效的情况下,另一个节点可以充当主要节点和智能节点全部二者继续操作。在使用共享部署时,从主要节点到智能节点的数据保护是连续的;在主要节点失效(完全节点或主要数据储集池)的情况下没有数据丢失,这是因为HA流数据被实时递送到智能节点。在使用独立部署时,从主要节点到智能节点的数据保护可能与共享配置中一样是实时的,或者替换地是接近连续的。在接近连续的情况下,去到智能节点的HA流数据递送被延迟。这样在主要节点失效(完全节点或主要数据储集池)的情况下引入了一些数据丢失的可能性,但是网络等待时间对于主要IO路径性能具有最小影响。当独立部署采用延迟的数据保护时,改变编目条目被实时地从主要节点传送到智能节点,但是主要数据的镜像被异步递送,从而产生了数据丢失的可能性。通过在不相应接收主要数据的情况下识别出所接收到的改变编目条目,改变编目可以被用来识别在失效的情况下丢失了哪些改变。
部署在远程站点处的节点可以添加附加的数据保护层级,并且与智能节点通信。后面在站点外数据保护下讨论远程站点部署选项,但是他们也可以被部署在站点上作为附加的冗余保护。
数据还原
还参照图11,在还原处理期间,数据在相反的方向上流动。数据还原可以是选择性的(对象层级)或者是全站点的。还原是实况的,从而提供了对于对象层级还原数据的接近即时的访问,并且当与传统的还原***相比大大减少了访问来自全站点还原的数据的等待时间。还原是完全受保护的,这是因为对于所还原的数据的任何改变都被实时地跟踪,即使还原处理仍在进行当中。
通过把主要数据的镜像拷贝存储在智能储集池130中,当前的主要数据总是受到保护。如果主要数据被保留在发现点中,则用户可以还原其数据的先前的版本。用户使用选择性还原,以在文件、目录或文件***粒度使用从智能节点120到主要节点100、在远程智能配置800或灾难复原配置800中从远程站点到主要节点100、或者在远程智能配置800或灾难复原配置810中从远程站点到智能节点120的对象实况还原1100来还原数据。全站点还原利用块实况还原1110从智能节点120到主要节点100还原主要数据,或者在灾难复原配置810中从远程站点还原主要数据和智能数据二者。全站点还原在完全数据储集池失效的情况下是最常需要的。出于还原流的考虑,当前的数据(或者从还原的所选发现点算起是当前的)被还原到主要节点,并且发现点(其包括分析元数据和主要数据)被还原到智能节点。
为了在对象层级实施选择性还原,用户对于数据还原选择来源发现点650。选择在特定发现点是已知的情况下可以是直接的,或者基于在与每一个发现点相关联的分析元数据上进行的搜索的结果。可搜索的标签、内容、分类等等除了其他选项之外还提供对于文件类型、文件应用元数据(例如文档作者)、所有者、分析指派的标签(例如针对包含社会保险号码的文件)、内容搜索关键字等等的搜索访问。一旦选择了发现点,还原处理就开始。数据可以被还原到原始容器中,从而覆写主要存储中的当前版本,或者被还原到不同的容器中,从而创建单独的拷贝。
操作为允许选择性还原的对象实况还原处理是以对象粒度提供快速数据还原的核心机制。在实施这样的还原时,用户体验到对于数据的接近即时的访问。为了实现这一点,控制还原的目的地的节点基于元数据为正被还原的内容创建空的容器。任何被活跃请求的部分都通过向还原节点请求这些特定部分而被即时获得。这样就为末端用户创建了即时可用的数据。以基于先前随着时间收集的分析所指派的优先权来传送完成还原所需要的任何附加数据。这样的实况还原和访问通过拦截所有文件访问请求的PART的操作而实现,从而允许对需要即时还原的热区段进行识别和优先权排序。类似地,即使在后台还原正在进行的同时,对于所还原的文件的访问和修改也被跟踪,这是因为这些访问也被PART拦截。因此,选择性还原允许对于所还原的对象的即时访问并且还允许对于任何改变的实时保护,即使在对象被完全还原之前。
还参照图12,通过选择性对象还原,还原处理在做出还原请求之后几乎即时就对***用户表现为完成。用户搜索1200智能数据,这在内部查询1205元数据以用于针对所期望的发现点的还原分析1210。一旦被识别,用户就可以发起1215还原请求。还原请求(可选地连同有关的分析元数据)被引导1220到PART。PART通过从发现点提取出与还原相关的元数据而开始还原。文件元数据包括针对每一个文件并且特定于任何时间点的文件名、路径、尺寸、所有者、群组和访问权利信息。利用所还原的元数据,PART可以提供例如目录列表之类的文件标识信息,而无需实际还原的数据移动到主要存储。这样就允许向用户确认1225还原完成,并且允许利用所还原的数据的用户输入/输出的操作1230,甚至在实际数据的完全还原之前。可以基于特定文件访问对数据的实际还原进行优先权排序。举例来说,如果尚未还原的特定文件数据被访问,该文件可以针对即时还原被优先权排序。在没有优先还原发生时,整个数据内容的一般数据还原可以继续。通过这种方式,即使完全数据还原需要很长一段时间(比如几分钟或几小时),用户也会体验到并且可以访问来自还原请求的即时结果。
全站点还原被用于裸机(bare-metal)复原,从而成批地还原所选择的卷和/或文件***以及相关联的发现点和分析数据。在任何全站点还原的情况下,相关联的分析元数据也被还原。存在两种类型的全站点还原。全站点还原从远程站点还原主要数据和智能数据二者。仅主要站点还原从智能节点还原主要数据。为了实施全站点还原,用户通过直接选择或者搜索和选择来识别出一个或更多卷和/或文件***以及发现点。一旦选择了文件***和相关联的发现点,还原处理就开始。对于全站点还原,所选择的发现点中的所选择的卷和/或文件***的版本被还原到主要节点和智能节点,并且发现点被还原到智能节点。对于仅主要站点还原,所选择的发现点中的所选择的卷和/或文件***被还原到主要节点。此外,对于仅主要站点还原,可以选择/取消选择要保留的发现点,其中智能节点保留被选择保留的所有发现点并且删除其他发现点。
允许全站点还原的块实况还原处理是以站点粒度提供快速数据还原的核心机制。在发起全站点还原之后,用户在数据可访问之前所经历的等待时间大大减少。作为初始步骤,对于正被还原的卷和/或文件***在块存储层级拷贝元数据。这一拷贝产生了在数据可访问之前的主要延迟时间。元数据标识出正被还原的所有对象,即主要数据和任何发现点二者。一旦元数据被还原,可以对于正被还原的所有数据实体创建虚拟容器。此时,可以使得主要数据可用于用户I/O访问和正常操作。卷内的被活跃访问的文件或区域(区段)即时被获得并且作为块层级还原被还原,从而为被活跃访问的数据创建优先还原。基于先前随着时间收集的分析使用优先权来作为后台处理还原站点数据的其余部分。与选择性还原一样,所有访问和修改都被跟踪,从而即使在后台还原正在进行时也允许实时保护。通过拦截所有数据访问请求的PART实现这样的接近即时的访问和实时保护。基于元数据,PART可以识别出访问请求是否是针对已经被还原的数据,在这种情况下继续正常操作,或者可以识别出是否针对尚未被还原的数据,在这种情况下识别出适当的数据块以用于优先即时还原。
***管理
管理服务允许创建和修改用户权利、节点和物理存储管理、数据智能配置、人工创建和管理发现点、或者安排用于自动发现点管理的选项,并且提供对于还原处理的访问。不同的管理软件实现方式是可能的,但是一种优选的方法是把管理软件320实施成主要节点内的管理服务器。管理服务器通过基于浏览器的接口向经过授权的管理员递送用户管理。
管理服务允许管理发现点。发现点可以被人工创建,基于时间段针对自动创建被安排,或者被配置成基于先前随着时间收集的分析动态地自动创建。归档或者迁移到远程站点也可以被人工触发,或者基于时间段针对自动发生被安排,或者被配置成基于先前随着时间收集的分析动态地自动发生。
管理服务允许对于数据分析配置规则引擎。这样的规则可以被应用于所有新的数据改变,或者还对已经被存储在智能节点中的所有数据运行。可以设定规则优先权,从而在智能节点处内联地应用关键分析以使得重要的分析对于所有数据即时可用,而较不关键的分析则可以被批处理并且以较低优先权周期性地运行。
除了通过传统的编程语言可用的定制API之外,所述***还支持基于文件访问的接口,从而允许通过标准文件***API的结果的查询创建、执行、控制以及提取。查询执行文件可以作为特殊文件被存储在预先标识的位置处。这样的文件可以包括关于以下内容的信息:将要实施的查询、何时实施、实施所使用的资源、在何处放置或存储结果以及应当使用什么格式来呈现结果(例如未经处理的数据、pdf、特定报告格式等等)。当正由所述***执行查询时,进展文件夹可以包含其名称和内容可以被用来监测进展的文件。用户可以编写定制脚本和工具,以便使用这样的标准文件***操作来创建、安排、监测以及提取结果。
站点外数据保护
智能节点对主要数据和分析元数据提供本地保护。可选的远程***可以提供进一步的冗余性,以及对于主要数据和分析元数据的地理远程保护的选项。
在这样的解决方案的这个讨论中,主要位置被视为包括前面所描述的主要节点和智能节点,并且智能节点与远程站点***通信。
与发现点一样,远程保护分析元数据与实际数据相关联并且与之一起传送(二者都用于保护和还原)。远程站点可以被配置成接收和存储智能节点的对象,从而提供地理上分开的冗余性或者作为归档选项。数据改变(数据和分析的增量)被从智能节点发送到远程站点,从而允许主要存储和当前分析的冗余拷贝,具有对于发现点创建配置不同规则的选项,从而允许远程站点处的不同归档选项。出于归档目的,规则可以被配置成使得本地智能节点在指定时间段和频率内保留发现点,并且远程站点包含不同的集合,比如跨越更长的时间段和/或更低的频率。举例来说,智能节点可以被配置成对于过去的三十天每小时保留发现点,而远程站点可以被配置成对于过去的两年每天保留发现点。基于保留在全部两个节点处的元数据,全局分析在整个时间段内跨所述数据是可用的。远程站点规则还可以被配置在不同的层级,比如在***或用户共享或内部文件***层级,从而允许更大的数据集合内的不同程度和持续时间的保护。
这样的站点外数据保护提供两种可能的解决方案:灾难复原(DR)和远程智能。全部两种解决方案都在完全主要位置失效(主要位置上的主要和智能失效二者)的情况下提供对于顾客数据和分析元数据的保护。主要到智能到远程站点数据流把数据保护扩展到附加的层级。
远程智能
如图1中所示,当利用远程智能配置正常地操作时,本地站点智能节点把数据和分析元数据复制到远程站点智能节点140。远程智能节点可以被配置成接收从智能节点复制的发现点数据和分析,比如将在智能节点上过期(被删除)的发现点,或者被配置成接收实况改变数据的拷贝并且在远程智能节点处直接创建发现点和有关的分析。基于由远程智能节点的规则引擎操作的所配置的策略,远程智能节点上的发现点可以过期(被删除),并且分析元数据可以被修剪(pruning)。
去到远程站点的数据复制可以同步或异步进行。在同步情况下,数据被实时地复制,并且远程站点包含主要存储数据的完整并且最新的拷贝。这样的同步方法的优点是在本地站点处的完全失效(主要和智能全部二者)的情况下不会丢失数据。但是由于必须在存储操作被确认完成之前将数据复制到远程站点,因此本地站点性能可能会显著降低。
异步情况避免了对于主要存储造成性能影响的风险。数据复制可以被延迟,在这种情况下,远程站点包含主要存储数据的某一版本,而不是实时最新的。这样就避免了任何性能影响,但是引入了在本地站点完全失效(主要和智能节点二者全部失效)的情况下发生一些数据丢失的风险。
可以对于本地或远程智能节点上的任何发现点实施对象实况还原。从末端用户的角度看来,在本地或远程智能节点之间在复原数据方面没有差别:全部两个智能节点上的所有发现点都可搜索并且可用于在通过由主要节点提供的管理接口的复原中使用。
在完全本地站点***失效的情况下,可以从远程站点还原本地站点,从而允许作为全站点还原处理的一部分的完全操作。在本地站点的还原之前,用户可以使用在远程智能节点处可用的分析元数据实施搜索。取决于策略配置,用户可以对于存储在远程智能节点上的每一个发现点内的数据进行只读访问,或者对于其存储在每一个发现点内的数据进行读取-写入访问。但是在读取-写入的情况下,新被修改的数据可能不受保护。基于所选择的策略和远程智能节点***能力,可以关于新被修改的数据不产生分析、产生有限的分析或者产生完整的分析。在一个实例中,对于新被修改的数据只保持改变编目,并且不可以对新被修改的数据实施查询。在另一个实例中,产生完全分析元数据,但是性能可能低很多。对于在本地站点失效之后利用远程站点的完全操作,灾难复原配置是优选的。
对于实况还原技术的详细讨论
后面的章节更加详细地描述各种实况还原方法和设备。正如前面所提到的那样,取决于实况还原情境处于对象层级(文件、目录或文件***层级)或者站点层级(使用块操作)的情境,所述处理是不同的。
对象层级实况还原
对象层级实况还原处理和设备提供了用以选择性地还原文件、目录或者个体文件***的机制。单个文件实况还原是用于所有此类对象层级实况还原的核心机制。
传统的文件***具有被用来高效并且唯一地标识文件或目录的标识符。在后面的讨论中,我们使用术语“ObjectId(对象ID)”来表示在文件***内唯一地标识文件或目录的文件***标识符。索引节点编号(inodenumber)是使用在便携式操作***接口(POSIX)兼容文件***中的ObjectId的一个实例。通常有不表示有效文件或目录的无效ObjectId。我们还将使用对于ObjectId的缩写“OID”。
单个文件实况还原
图13示出了被用于还原单个文件的文件层级实况还原处理1300。
被命名为“file1.xx”的文件的一个版本1305正被从智能储集池130还原到主要储集池110。所述版本由文件路径和“发现点”1310标识。正如前面所解释的那样,发现点1310包含数据和先前收集的分析的时间点拷贝。在实况还原的处理期间,在一种实现方式中,文件被划分成被称作块1320的等尺寸组块。原子级地逐块还原文件。块的尺寸在数据还原期间不发生改变。在该实现方式中,使用还原位图1325来管理实况还原期间的块的状态。对于来源文件中的每一个块,位图缓冲器中的一个比特跟踪一个块是否被还原。举例来说,具有数值1的比特标记已被还原的块,而具有数值0的比特则标记需要被还原的块。在图13中,已经基于存储在来源发现点中的先前收集的分析利用日程安排还原了块A和B。在这里,块C当前正被用户I/O操作1330修改。块C被还原,随后把数据与用户数据合并,从而得到数据C’,其随后被存储在主要和HA拷贝二者之内。随着文件块被还原,还原位图被更新以反映还原的状态。
在其他实现方式中,块1320可以具有变化的长度。在这样的实现方式中,可以保持已被还原的范围(区域)的列表。可以利用起始和结束偏移量或者通过其他方式来指定所述范围。
在主要储集池110失效的情况下,没有用户数据被丢失,这是因为智能储集池130包含足以复原用户数据的信息。
在智能储集池失效的情况下,主要储集池包含新的用户数据。如果智能数据的远程/灾难复原拷贝可用,则主要储集池内的数据和智能数据的复原拷贝可以被用来完全复原用户数据。
后面的算法(如图14再现)是实施在单个文件还原(继续参照图13)中所涉及的一般步骤的一种方式。在这里,将要还原的文件的文件版本由二元组S_Path和S_DP标识,其中S_Path是发现点S_DP内的文件路径。D_Path标识来源版本将被还原的目的地。
算法FileRestore(INS_Path,INS_DP,IND_Path)
1、准备文件以用于还原
a、调用算法PrepareFileForRestore以便创建空目的地文件D_Path并且标记适当的元数据,从而允许执行实况还原
b、(后面更加详细地描述)
2、在还原完成之前允许对于文件的I/O访问
a、调用算法IoToFileBeingRestored以便允许用户访问正被还原的数据
b、(后面更加详细描述)
3、开始数据的后台还原
a、作为后台处理还原文件数据
b、在文件内以逐块层级实施还原I/O
c、对于所还原的每一个块,还原映射图记录所还原的块
i、在一种实现方式中,还原位图是存储在文件的扩展属性内的位图,其中每一个比特表示一个块
d、后台数据还原使用两条原理对块的还原进行优先权排序
i、正在被实时地活跃还原的块
ii、在子对象和块层级存储在S_DP中的先前收集的分析
1、子对象的一个实例可以是powerpoint演示内的一幅jpeg图像,其被更加频繁地访问并且将以更高的优先权被还原
2、块的一个实例将是对应于存储在虚拟盘文件或iSCSILUN内的NTFS文件***的主文件表,其在引导处理中非常早期被访问并且以更高优先权被还原
4、随着新的数据被写入到正在被活跃还原的文件
a、对新的和所还原的数据进行镜像以便提供HA;从而使得新的数据也利用别处所描述的标准HA技术被实时地保护。
还原位图
还原位图被用来允许在文件正被还原时对其进行随机I/O访问。存在人们可以保持该位图的许多方式。举例来说,位图可以在还原操作的整个持续时间内被保持在NVRAM中。位图还可以被保持在私有扩展属性中。由于NVRAM的尺寸有限,因此第一种方法限制了可以被活跃还原的文件的数目以及正被还原的文件的最大尺寸。扩展属性方法可以被扩展成通过使用分级位图(类似于b树)支持任何尺寸的文件。
位图中的每一个比特跟踪对应于以原子级被还原的区段的还原状态。数值为0的比特标记需要被还原的区段,而数值为1的比特则标记已被还原的区段。初始地创建零位图(所有比特为零),从而表明还没有区段被还原。随着实况还原继续并且个体区段被还原,位图被更新以便反映出对应于每一个区段的还原的状态。这通常将至少具有原生文件***块尺寸,但是也可以是其倍数。为了限制位图尺寸,基于正被还原的文件的尺寸,位图的比特对于不同的文件也可以是动态的。例如对于较小的文件,一个比特可以表示与原生文件***块对准的一个区段,对于更大的文件,其可以是原生文件***块的倍数。
还原多个文件
典型的***应当允许并行地还原许多文件;实际上其应当适应如下可能性:许多用户可能同时请求用于还原的多个文件和多个目录。对于所有的还原,***使用下面所讨论的“RestoreLink(还原链接)文件”方法。***可以采用针对新的RestoreLink文件的创建扫描和/或监测RestoreLink目录的后台处理。当新的还原被添加时,所述后台处理检测到新的文件。存储在来源发现点中的先前收集的分析可以决定将要还原的大量文件的优先权排序和安排。受到还原处理的文件的总数可能远多于能够被保持在存储器中的数目。这样的***将需要一种允许安排大量对象的还原的模式,其具有在将要还原的对象集合无法被保持在存储器(RAM或NVRAM)中时在所述对象之间进行实时切换的能力。
RestoreLink文件
在一个优选实施例中,使用RestoreLink文件方法实现实况还原要求。但是其他方法是可能的。
在这种方法中,每一个主要文件***保持包含RestoreLink文件的RestoreLink目录。RestoreLink目录对于用户被隐藏,并且不可被用户访问。对于将要还原的每一个文件在RestoreLink目录中创建一个RestoreLink文件。所述***采用扫描/监测RestoreLink目录的后台处理。该后台处理负责检测新的RestoreLink文件并且基于先前收集的分析对还原进行优先权排序。
RestoreLink文件方法的主要优点在于其允许找到将要还原的文件而不需要扫描文件***命名空间,否则扫描文件***命名空间的代价将是非常高昂的。包含RestoreLink文件的隐藏目录上的传统文件***目录扫描技术可以被用来在***失效的情况下继续还原处理,或者确定将要还原的下一个文件以及确定所有文件都已被还原。后台处理还可以监测触发对文件的活跃还原的该目录的内容。***还可以利用分析来针对在RestoreLink目录上实施扫描时将要首先还原哪些文件进行优先权排序。
RestoreLink文件如下包含RestoreSource(还原来源)、RestoreSize(还原尺寸)、FileOID和还原位图(RestoreBitmap):
RestoreSource=<DPsource,OIDsource>;其中DPsource标识包含将被用作所还原文件的来源(如由OIDsource进一步标识的)的文件的发现点。因此,RestoreSource唯一地标识对应于还原操作的来源对象。
RestoreSize是记录来源文件尺寸(或者换句话说,将要还原的数据的尺寸)的数字值
FileOID是正被还原的文件的对象标识符(目的地的OID)
还原位图被用来跟踪还原操作的进展。
这些数值可以作为关于文件或数据的属性被存储在RestoreLink文件内。在这个讨论中,我们假设所有数值都作为数据被存储在RestoreLink文件内。
将要还原的每一个文件还包含RestoreLinkOID属性,其包含相应的RestoreLink文件的OID。这是对于用户不可见的私有属性。一旦实况还原完成,该属性就被消除或者无效化。这允许在对正被还原的文件实施I/O时高效访问RestoreLink文件。
使用将要还原的文件的OID对RestoreLink文件进行命名。在优选实施例中,名称被创建成“RL_”前缀和正被还原的文件的OID的文字表示的串联。
下面的算法(还在图15中示出)被用来准备用于还原的文件。其在FileOID参数中返回将被实况还原的所创建的新文件的OID。
算法PrepareFileForRestore(INRestorePath,INRestoreSource=<DPsource,OIDsource>,OUTFileOID)
1、从RestoreSource获得将要还原的尺寸
2、创建将是还原的目的地的新文件RestorePath,并且获得在FileOID中返回的其对象id
3、从RestoreSource还原关于正被还原的文件的元数据(许可、所有权、属性等等)
4、创建RestoreLink文件,其中其对象id为RestoreLinkOid并且名称为“RL_<FileOID>”
5、把RestoreSource、还原尺寸、FileOID和零还原位图保存在新创建的RestoreLink文件中
6、把RestoreLink文件OID保存在关于将要还原的文件的RestoreLinkOid属性中。
图16示出了被准备用于还原的文件的一个实例。“RestoreLink”目录1610包含RestoreLink文件“RL_400”,RestoreLink文件“RL_400”具有指向还原来源文件“file1.xx”的OID200,所述还原来源文件“file1.xx”具有被存储在具有OID25的发现点K1620内的OID35。其还通过OID400指向将要还原的文件,从而标识文件“restored.xx”。文件“restored.xx”通过RestoreLinkOID属性指回具有OID200的还原链接文件“RL_400”。
对于正被还原的文件的I/O
在运行时间,所述***使用高速缓存技术来优化针对关于还原的信息的访问。这可以包括对应于正被还原的文件的OID、相关联的还原位图以及RestoreLink文件信息。***还可以采用NVRAM或传统的日志记录技术,以便允许在以原子级方式实施涉及多个对象(文件)的操作时对于所需要的信息(也就是还原位图)的原子级修改,实况还原数据,并且允许在文件数据正被还原时用户I/O。这些措施保证了文件***数据和元数据的一致性,并且在出错的情况下简化了复原。
我们在这里假设用户I/O中的区段与通过单个比特标识出的还原块优选地对准——换句话说,我们假设I/O被完全包含在所还原的块内。如果不是这样,可以使用多种标准技术。举例来说,人们可以把用户I/O划分成多个操作,其中每一个操作与还原块尺寸包含在一起。
下面的算法(如图7中描绘)被用来对正被还原的文件(其由FileOID标识)实施I/O。自变量如下:
FileOID标识用户对其实施I/O的文件
IO_Region标识I/O操作区段
IO_Type标识读取或写入操作
R_State是被用来标识I/O区段的还原状态的还原位图的一部分。该状态是从相应的RestoreLink文件获得的。
算法IoToFileBeingRestored(INFileOID,INIO_Region,INR_State,INIO_Type:Read/Write)
1、从R_State确定块的还原状态
2、如果该区段尚未被还原,则还原与用户I/O重叠的块
a、从来源文件读取数据并且将其写入到目的地——主要和HA镜像拷贝
b、更新相应的RestoreLink文件中的还原位图,从而标记区段还原完成
c、如果所有块都被还原完成,则还原处理
i、删除RestoreLink文件
ii、通过删除或者无效化RestoreLinkOID而标记文件还原完成
3、作为正常用户I/O继续
a、在READ(读取)的情况下,获得数据并且返回给用户
b、在WRITE(写入)的情况下,更新数据的主要和HA镜像拷贝。
下面的算法被用来对文件(由FileOID标识)实施I/O。
如果文件没有正被实况还原,则***按照结合早前的附图所解释的那样实施文件***I/O。也就是说,在READ(读取)的情况下,***从主要来源读取数据并且将其返回给用户;在WRITE(写入)的情况下,***把数据写入到主要和HA拷贝。但是当实况还原属性有效时,这一处理如下发生改变:
算法File_I/O(INFileOID,INIO_Region,INIO_Type:Read/Write)
1、从FileOID获得RestoreLinkOID属性
2、检查文件FileOID是否正被实况还原
a、如果RestoreLinkOID不存在或者无效,则作为正常IO继续
i、在READ(读取)的情况下,获得数据并且返回给用户
ii、在WRITE(写入)的情况下,更新数据的主要和HA镜像拷贝
3、如果RestoreLinkOID有效,则获得对应于IO区段的还原状态R_State
a、从相应的RestoreLink文件(由RestoreLinkOID标识)加载位图的一部分。由于每一个比特表示曾被还原或者需要被还原的区段,因此***可以快速地确定所需要的比特集合
4、调用IoToFileBeingRestored(FileOID,IO_Region,R_State,IO_Type)。
目录/文件还原
目录和文件***实况还原处理可以使用前面所描述的个体文件还原处理。
文件***层级实况还原可以作为其根目录的还原来对待。
目录可以包含许多文件以及具有更多文件的其他子目录。用以实施目录还原的简单的方法可以是锁定将要还原的目录树,并且随后实施个体文件的实况还原。
虽然对于单个文件的实况还原几乎是即时的,但是锁定目的地目录树方法的主要问题在于:来源目录可能包含许多子目录和文件,从而导致非常长的累积实况还原处理。由于在该处理发生的同时对于目的地目录的访问被阻塞,因此这可能是不合期望的。这种情况的一个效果是用户I/O将会超时,并且依赖于这些I/O的应用将停止正确地操作。我们描述了一种在准备文件以用于还原的整个持续时间内不需要锁定整个目的地目录树的处理。在还原目录树时,目的地不能存在或者必须为空。
典型的文件***具有遍历目录的内容的确定性方式。每一个来源目录(包括其子目录)的内容在操作的持续时间内是固定的,并且可以按照明确定义的顺序被遍历。出于讨论的目的,我们可以与树遍历并行。每一个目录可以作为树的一个节点来对待,并且每一个文件可以作为数据内容来对待。正被还原的目录可以被描述成多分支树。使用传统的树深度优先顺序方法来遍历还原来源目录:首先访问子目录,并且随后实况还原当前目录中的每一个文件。在实施遍历的同时,***保持跟踪其当前正在遍历的路径。使用深度优先方法的主要优点在于,路径信息受到限制并且较少。举例来说,LINUXOS把文件路径限制到4KiB,而与多少子目录出现在该路径上无关。
下面的算法使用以下输入:RestoreSourceDp、RestoreSourceDir和RestorePathDir。
RestoreSourceDp是包含将要还原的数据的发现点(还原数据的来源)
RestoreSourceDir是RestoreSourceDp中的正被还原的目录。与前面对于文件的情况一样,二元组<RestoreSourceDp,RestoreSourceDir>形成将要还原的目录的版本。
RestorePathDir是数据被还原到其中的路径(目的地目录)。
在还原目录时,***保持关于正被还原的每一个目录的、被称作RestoreInProgress的私有(对于用户不可见)属性。该属性记录对应于实况还原<RestoreSourceDp,RestoreSourceDir>的来源信息。该属性的存在表明该目录文件内容实况还原尚未完成。该属性不存在表明所述目录中的所有文件都已被完全还原或者实况还原(元数据已完成并且数据正被还原),或者表明这是不需要还原的目录(当目录被删除并且所创建的目录具有相同的名称时可能发生这种情况)。该属性主要被用来在目录实况还原正在进行中时协调进来的命名空间操作。如果目录被删除并且被重新创建,则其不存在该属性。
下面的算法被用来发起对于正被还原的目录的后台遍历,并且随后发起每一个个体文件的实况还原。该算法(如在图18中描绘的)由***在后台执行。每一个子目录通过其名称而不是通过其OID被访问。
算法DirectoryLiveRestore(INRestoreSourceDp,INRestoreSourceDir,INRestorePathDir)
1、对于RestoreSourceDir中的每一个子目录S
a、在RestorePathDir中以原子级创建子目录S:
i、创建S
ii、从来源<RestoreSourceDp,RestoreSourceDir>还原S的元数据
iii、记录关于S的属性RestoreInProgress
b、调用DirectoryLiveRestore(RestoreSourceDp,对应于RestoreSourceDir中的S的完整路径,对应于RestorePathDir中的S的完整路径)
2、调用DirectoryContentLiveRestore(RestoreSourceDp,RestoreSourceDir,RestorePathDir)。
***允许对正被实况还原的目录的命名空间操作。对于目录的用户访问可能会与正在后台运行的目录实况还原操作产生冲突。应当提到的是,前面描述了针对文件的操作冲突解析。
当***接收到基于路径的操作时,其遍历所述路径上的每一个子目录,并且如果需要的话在原子级对该子目录的内容实施实况还原。
每一个目录内容关于文件***操作的其余部分以原子级被还原。在这个讨论中,“目录内容”意味着目录内的所有文件。子目录没有被即时还原,相反每一个子目录被创建为其所有属性都正被还原的一个对象,并且还利用RestoreInProgress属性被标记,从而表明其内容需要在以后时间被还原。
下面的算法描述了这一处理。所述算法关于针对RestorePathDir的所有其他文件***操作通过原子方式被执行——对于所有其他文件***操作锁定了针对该目录的访问。每一个子目录通过其名称而不是通过其OID被访问。
算法DirectoryContentLiveRestore(INRestoreSourceDp,INRestoreSourceDir,INRestorePathDir)
1、如果RestoreSourceDir具有RestoreInProgress,则
a、实况还原每一个文件:
i、对于RestoreSourceDir中的每一个文件F调用PrepareFileForRestore(对应于RestorePathDir中的F的完整路径,<对应于RestorePathDir中的F的完整路径>,RestoreSourceDp>)
b、对于RestoreSourceDir中的每一个子目录S:
i、如果S在RestorePathDir中不存在,则
ii、创建S
iii、从来源<RestoreSourceDp,RestoreSourceDir>还原S的元数据
iv、记录关于S的属性RestoreInProgress:RestoreInProgress=<RestoreSourceDp,RestoreSourceDir中的S的完整路径)
c、标记目录实况还原完成(消除RestoreInProgress属性)
下面的算法被用来在实施用户I/O时解决命名空间(路径)冲突。
IO_Path标识出被用于操作的文件***命名空间内的对象路径。
fsOperation标识出由用户请求的文件***操作。
算法ResolveNameSpaceOnLiveRestore(INIO_Path,INfsOperation)
1、把IO_Path分解成个体令牌:IO_Path=<S1,S2,...,Sn>。应当提到的是,Sn可以是目录或文件。只有最后一个令牌可以是文件。
2、对于每一个Si,i=1...n
a、如果Si是Sn并且是文件——如前面所描述的那样解决操作,因为该文件从实况还原的角度看来已经被处理
b、如果Si是目录并且具有RestoreInProgress,则执行DirectoryContentLiveRestore(RestoreSourceDp,RestoreSourceDir,Si的完整路径)。
当用户I/O到达时,子路径可能已经被还原,在这种情况下不需要做任何事情。当子路径由先前的用户操作或者由后台目录实况还原还原时可能会发生这种情况。
如果子路径尚未被还原,则这意味着这是对于该子路径的第一用户操作,并且后台实况还原尚未将其还原。在这种情况下,***锁定该子路径并且实施内容实况还原。当后台处理进入该路径时,其将快速地确定不需要做任何事情并且继续进行。
块层级实况还原
正如前面所提到的那样,实况还原还可以在块层级发生。这是对整个站点实施实况还原的优选方式。
***层
下面的定义被用于描述块层级实况还原处理。
站点P——正被还原的主要站点
站点R——被用作站点还原操作的来源的远程(本地位置或远程位置处的智能节点)站点。
每一个站点通常由以下功能层构成:物理存储、文件***以及虚拟盘层。图19示出了所述三个存储层及其关系。
物理存储层(PSL)1910——物理存储介质,HDD、SSD等等。
文件***层(FSL)1920——这是实施文件***的层。FSL主要出于两个原因使用存储,即存储文件***元数据(内部文件***和命名空间信息)和用户数据。在没有用户文件I/O的情况下,FSL对于其操作只需要元数据,并且不访问或修改被用来存储用户数据的存储区域。更新的FSL实现方式趋向于支持所谓的TRIM操作。TRIM操作由FSL使用来向物理存储通知某一区域不再被使用,并且可以由PSL收回。
虚拟盘层(VDL)1930——这是位于物理和文件***层之间的层,并且被用来虚拟化物理存储配置。VDL消耗物理存储,并且向文件***层呈现虚拟盘。这样就允许不具有相同的存储(盘)配置的站点之间的站点还原。VDL还被用来跟踪被呈现到文件***层的每一个虚拟盘处的区域分配。在该实施例中,为了讨论简单起见,VDL被描述成与FSL分开的逻辑层。但是在某种其他实现方式中,其可以被直接实施在PSL或FSL之内。VDL可以负责为元数据(MD)和用户数据(D)结构保持单独的逻辑构造,正如后面所描述的那样。
可以从文件***中提取出的一项信息是存储元数据的区域。但是这样做的代价可能是高昂的。在更好的方法中,文件***可以被实施成使得他将其元数据存储在专用于仅有元数据用途的单独的存储器件(或多个存储器件)上。当与这种方法组合时,利用VDL处置区域分配跟踪,允许快速地识别由文件***层分配/使用的元数据区域。
块实况还原
VDL实施块实况还原操作。其被用来从一个站点到另一个站点还原区域的集合。区域的列表被保持在数据还原区域映射图中。在给定这样的映射图的情况下,VDL在逻辑块层级从远程站点拷贝数据。在后面描述并且在图20中示出了一般的算法。
Site_P是如前面所描述的站点P。
Site_R是如前面所描述的站点R。
RestoreExtentMap是保持将要还原的区域的列表的数据区域映射图。
算法BlockLiveRestore(INRestoreExtentMap,INSite_P,INSite_R)
1、对于RestoreExtentMap中的每一个区域,从远程位置Site_R读取数据并且将其在本地拷贝到Site_P——(数据的主要和HA镜像拷贝都被拷贝)
2、利用关于已被还原的区域的信息更新RestoreExtentMap。
还原区域位图
人们可以使用多种方法来跟踪被还原和未被还原的区域。一种方法是使用位图。位图的使用允许对正被还原的区域进行随机访问。在这种情况下对位图的使用类似于其被用于文件实况还原的方式。还原区域位图中的每一个比特跟踪对应于以原子级被还原的区域的还原状态。举例来说,数值为0的比特标记需要被还原的区域,而数值为1的比特标记已被还原的区域。初始创建零位图(所有比特都被设定到零),从而表明还没有区域被还原。随着实况还原继续并且个体区域被还原,还原区域位图被更新以反映出对应于每一个区域的还原状态。
在写时拷贝(copy-on-write)文件***中,数据从不会被覆写。每一项修改都被写入到新分配的块。对于这些文件***,关于正被还原(已还原对需要被还原)的区域的信息可以通过使用单个还原水印来实施,其中水印之下的区域已被还原,并且水印之上的区域尚未被还原。
如果接收到针对某一区域的I/O,则使用下面的逻辑。***通过创建数据的HA拷贝来保护新还原和新写入的用户数据。
针对正被实况还原的区域的I/O
使用下面的算法来实施针对正被还原的块(区域)的用户I/O
IO_Region——标识I/O操作块
IO_Type——标识读取或写入操作。
算法IoToBlockBeingRestored(INIO_Region,INIO_Type:Read/Write,INRestoreExtentMap,INSite_P,INSite_R)
1、使用RestoreExtentMap确定与用户I/O重叠的还原区域
2、如果区域尚未被还原,则还原所需要的区域
a、从Site_R来源读出数据,并且将其写入到目的地Site_P——数据的主要和HA镜像拷贝
b、更新RestoreExtentMap,从而标记区域还原完成
c、如果所有区域都被还原,则完成还原处理
3、作为正常IO继续
a、在READ(读取)的情况下,获得数据并且返回给用户
b、在WRITE(写入)的情况下,更新数据的主要和HA镜像拷贝
c、。
图21示出了当还原区域映射图被用来跟踪关于各个区域以及进行中的用户I/O(写入)的还原信息时的块还原处理2100的一个实例。
数据区域被从远程储集池130(从***R)还原到主要储集池110(到***P)。远程储集池包含将要还原的用户数据2110。在该实现方式中,远程储集池被划分在各个区域上。因此,***R跟踪关于所使用的区域的信息,并且在还原处理开始之前使得该信息可用于***R。以原子级逐个区域地还原储集池中的数据。在该实现方式中,使用还原区域位图2135来管理实况还原期间的区域的还原状态。对于将要还原的每一个区域,来源储集池(***R)在还原区域位图中保持一个比特,以便跟踪某一区域是否已被还原。数值为1的比特标记已被还原的区域,而数值为0的比特标记需要被还原的区域。
在图21中,主要数据2120中的区域A和B已经基于存储在来源储集池中的先前收集的分析使用日程安排而被还原。在这里,块C当前正被用户I/O操作2130修改。块C被还原,随后将数据与用户数据合并从而得到数据C’,数据C’随后被存储在主要和HA拷贝全部二者之内。随着更多的文件块被还原,还原区域位图被更新,以便反映出进行中的实况还原的状态。
对于FSL发出的TRIM操作的处置
正如后面所描述的那样,一旦文件***元数据被拷贝到还原位置,用户就被允许访问其数据,这可以随后导致修改文件***元数据。这可以在对将要还原的文件***进行修剪期间发生,或者后来在对于正被还原的站点的用户I/O期间发生。这些操作可以导致由文件***使用的元数据和数据区段中的一些被释放。这还可以导致向VDL发出TRIM操作,从而表明某一存储区段不再被FSL使用。当接收到对应于元数据区段的TRIM操作时,***将其如所有元数据块都已被恢复的那样正常处理。当接收到对应于数据区段的TRIM操作时,由于其不需要被还原,因此***找到由该区段表明的、存在于还原区域映射图中的所有区域,并且将其还原标记为完成。应当注意的是,如果在映射图中没有找到某一区域,则相应的区域实况还原已经完成或者还不需要还原;在任何情况下,都不再需要对于还原映射图的进一步动作。
当作为用户元数据修剪或I/O操作的结果接收到对某一数据区段的TRIM操作时,下面的算法被用来保持数据区域还原映射图。使用以下自变量:
如前面所描述的RestoreExtentMap
TrimDataRegion是由FSL标记为不处于使用中的数据区段。
算法ProcessTrim(INRestoreExtentMap,INTrimDataRegion)
1、对于数据,同样处在RestoreExtentMap中的TrimDataRegion中的每一个区域E把E还原状态标记为完成(把相应的比特设定到1)。
站点还原
正如前面简要讨论的那样,块实况还原还可以被应用于整个站点的还原。下面的描述假设文件***层使用由VDL呈现的专用虚拟器件来存储其元数据,并且FSL向下方的存储层发出TRIM操作以便通知其关于未被使用的区域。
图22示出了文件***元数据(MD)2210和用户数据(DATA)2220分离以及区域分配跟踪。在FSL处存在所分配的空间的逻辑区段,其映射到VDL处的所分配的区域,所分配的区域继而映射到所使用的物理存储。用于站点还原的算法如下(并且在图23中示出):
算法SiteRestore(INSite_P,INSite_R)
1、在站点P处配置虚拟盘层,以匹配正由站点R处的VDL呈现的内容的配置。
2、识别在站点R处所分配/使用的元数据区域,并且将其拷贝到站点P的相应的(多个)虚拟器件。一旦这一步骤完成,站点P上的FSL就准备好实施他的不涉及用户数据的操作。
3、从站点R处的VDL获得关于所分配/使用的数据区域的信息。该信息被传送到站点P处的VDL。该信息形成还原区域映射图。
4、实施文件***修剪。在该步骤中,用户识别出不需要被还原的文件***。不需要的发现点也被破坏——举例来说,如果站点P是主要控制器/***,则所有发现点都被破坏。如果站点P是智能控制器/***,则用户选择的发现点被保留,而其余的发现点被破坏。文件、***和发现点的删除是FSL层级的管理操作,其导致FSL元数据被修改,但是由于所有元数据都已被还原,因此仅有站点P元数据被修改。删除的另一个效果是FSL可能声明一些数据块不再处于使用中,从而导致TRIM操作。随着FSL发出TRIM操作,VDL更新其还原区域位图,从而标记出不需要还原的区域。
5、基于还原区域映射图中的信息安排后台块实况还原。
6、允许用户访问文件***。
图24示出了步骤5之后的P(主要)和R(智能)的状态。
元数据被从***R拷贝(仅有所使用的元数据区域被拷贝)到***P。完全还原的块(或者不需要还原的块)被实心填充。被标记成没有被FSL使用的块则用交叉图案填充来标识。将需要被还原的块用垂直条纹填充标识。***P上的VDL把将要还原的块(需要从R拷贝到P的数据)保持在还原区域位图中。
在图23中所示的实例中,用户选择了不还原FS2,并且对应于FS1和FS3的所有发现点因此已被***删除。这就导致一些元数据和数据块被FSL释放,并且被标记成不再处于使用中。因此,FSL发出了针对这些区段的TRIM操作。由于元数据块已被完全还原,因此***正常处理对元数据块的TRIM。已被FSL报告为不再处于使用中的数据块在还原区域映射图中被标记成还原完成,并且将不被还原。随着后台还原的进展,***P上的VDL使用还原区域位图标识将要还原的块,并且随后从远程***R读取该数据并且在本地将其写入。
应当提到的是,***R和***P的物理存储配置不必是相同的。VDL抽象在全部两个***上向FSL呈现虚拟存储配置的物理配置。***P上的可用物理元数据存储必须至少是***R处的所述存储的尺寸。必须至少需要***R上的可用物理数据存储以在修剪完成之后还原数据。
应当理解的是,前面的描述意图是说明性而非限制性的。在审阅前面的描述时,许多其他实施例对于本领域技术人员将是显而易见的。作为仅仅一个实例,算法规定一般步骤或者实施功能或特征的一种具体方式。本领域技术人员将认识到,其他方法也是可能的。还应当理解的是,所描述的算法针对实施所陈述的功能所需的主要逻辑。其并没有描述所有可能的实现方式变型;他们也没有规定对于实际的***所需要的所有可能的辅助功能,比如无效的用户提供的输入或者无效的操作状态。举例来说,可以按照任何便利的方式来处置错误状态。
因此,本发明的范围应当仅参照所附权利要求书连同这种权利要求被赋予的等同物的完全范围来确定。
Claims (63)
1.一种主要存储、高可用性和数据分析***,其包括:
被编程为操作主要节点软件的一个或更多处理器;以及
被编程为操作智能节点软件的一个或更多处理器;
其中,主要节点软件:
拦截数据访问请求,
镜像到智能节点软件,以便提供包括在数据访问请求中的数据的高可用性,
对数据访问请求执行内联数据分析,并且
把数据访问请求引导到主要存储储集池中的物理存储介质上的实际文件***或块卷;并且
其中,智能节点软件:
把镜像数据存储在与主要存储储集池分开的智能存储储集池中的物理存储介质中,
对镜像数据和/或先前实施的内联数据分析实施分析,并且
在智能存储储集池内创建发现点。
2.权利要求1的***,其中,主要节点软件还向一个或更多用户提供用户、web或编程接口,从而允许访问由智能节点软件存储的数据并且允许从所述数据进行还原。
3.权利要求1的***,其中,内联数据分析包括实时识别文件或数据访问和改变,并且在被发送到智能节点软件的改变编目条目中跟踪所述内联数据分析。
4.权利要求3的***,其中,内联数据分析包括针对所有数据创建、访问和修改跟踪谁、何时、如何以及在何处进行了所述创建、访问或修改。
5.权利要求3的***,其中,改变编目条目是一种形式的元数据或数据标签。
6.权利要求3的***,其中,每一个所存储的发现点包含从先前的发现点直到下一个发现点的创建为止的数据分析的递增改变,并且可选地包含从先前的发现点直到下一个发现点的创建为止的数据的递增改变。
7.权利要求6的***,其中,智能节点软件基于以下各项当中的一项或更多项创建新的发现点:从上一次发现点创建以来的时间、跨所有数据和/或分析的百分比改变、跨数据和/或分析的子集的百分比改变、所检测到的与使用模式的偏差、对于数据内容的实时分析、用户输入、以及用户指定的指标。
8.权利要求3的***,其中,智能节点软件还操作自适应并行处理引擎,以便使用先前收集的实时分析导出更加复杂的分析,包括随着时间跟踪***和内容改变和使用,而不会对主要存储性能或可用性造成任何影响。
9.权利要求8的***,其中,智能节点软件还创建镜像数据的全文本索引。
10.权利要求8的***,其中,所述自适应并行处理引擎利用针对数据的分析、***或应用的操作和/或已经收集的分析的一条或更多条规则的集合。
11.权利要求10的***,其中,所述自适应并行处理引擎在时间序列中应用多条规则,从而使得通过应用一条或更多条规则产生的分析导致应用附加的规则。
12.权利要求10的***,其中,至少一条规则的应用触发即时动作、安排动作或者安排重复性动作,所述动作包括以下各项当中的一项或更多项:创建临时或永久规则、通知、保留、隔离、数据提取或者数据的修改。
13.权利要求10的***,其中,所述已经收集的分析包括在改变编目中包括的内容。
14.权利要求10的***,其中,所述规则被配置成收集以下各项当中的一项或更多项:用于分析随着时间的总的存储和***使用的存储智能、用于保护数据和所收集的分析的复原智能、用于分析应用日志以及使用和安全性模式的操作智能、以及用于从非结构化、半结构化、结构化和/或复杂数据中提取分析的数据智能。
15.权利要求14的***,其中,所收集的智能允许结合对应于以下各项当中的一项或更多项的附加分析的操作:协作、趋势、电子发现、审计、评分、以及相似性。
16.权利要求10的***,其中,一条或更多条规则从数据内容中提取附加的分析元数据。
17.权利要求16的***,其中,可以由一个或更多用户搜索分析元数据、标签和内容索引当中的至少一项。
18.权利要求2的***,其中,操作主要节点软件的处理器和操作智能节点软件的处理器可以被部署在独立配置或共享配置中,并且在任一种配置中,主要节点软件向用户呈现单个***管理视图。
19.权利要求6的***,其中,主要节点软件还提供以下各项当中的一项或更多项:应用编程接口、基于文件访问的接口、web接口、以及用于搜索存储在一个或更多发现点中的分析的用户接口。
20.权利要求19的***,其中,被发送到智能节点软件的内联数据分析包括标识针对相关联的数据对象的访问权利的安全性许可,并且可搜索的分析基于对应于个体用户的安全性许可受到限制,并且对于由管理员进行的搜索不受限制。
21.权利要求19的***,其中,主要节点软件还提供:对于存储在所选择的发现点中的数据的处于文件、目录、个体文件***或者块卷粒度的选择性还原,和/或对于存储在所选择的发现点中的整个文件***或块卷的裸机还原,和/或对于所选择发现点的整个集合的裸机还原,其中选择来自对于分析的搜索和/或可用发现点的列表。
22.权利要求21的***,其中,一旦相关联的元数据被还原,主要节点软件就允许用户访问正被还原的数据,而与实际数据的还原的完成无关。
23.权利要求22的***,其中,当数据还原正在发生时,主要节点软件和智能节点软件跟踪、保护并且分析对于所有数据的数据访问、创建和修改,所述所有数据包括正被还原的数据。
24.权利要求22的***,其中,主要节点软件和/或智能节点软件使用***访问请求和所收集的分析元数据数据对数据还原期间的数据还原的顺序进行优先权排序。
25.权利要求14的***,其中,存储智能还允许在主要存储储集池与智能存储储集池之间进行可用物理存储的动态分配和/或再分配。
26.权利要求1的***,其中,操作主要节点软件的所述一个或更多处理器就是操作智能节点软件的所述一个或更多处理器。
27.权利要求1的***,其中,操作主要节点软件的所述一个或更多处理器还被编程为在操作智能节点软件的所述一个或更多处理器上的智能节点软件失效的情况下开始操作智能节点软件。
28.权利要求1的***,其中,操作智能节点软件的所述一个或更多处理器还被编程为在操作主要节点软件的所述一个或更多处理器上的主要节点软件失效的情况下开始操作主要节点软件。
29.一种用于集成的主要数据存储、镜像和分析的方法,其包括以下步骤:
在主要节点处:
通过网络连接从所连接的计算机接收包括请求数据的数据访问请求;
对数据访问请求和任何请求数据实施实时内联分析;
把内联分析、数据访问请求和请求数据转发到智能节点;以及
通过把请求数据转发到主要存储储集池或者从主要存储储集池取回请求数据来对数据访问请求做出响应,而无需首先等待来自智能节点的确认;
在智能节点处:
如果数据访问请求针对请求数据的写入,则把请求数据镜像到智能存储储集池;
把扩展元数据存储在智能储集池中;
如果数据访问请求包括对于请求数据的改变,则把改变数据存储在智能储集池中以作为改变编目中的改变条目,其中所述改变条目包括以下各项当中的一项或更多项:对应于发生改变的请求数据的标识符、发起数据访问请求的用户以及访问请求的时间;
把内联分析存储在智能储集池中;
对数据访问请求、请求数据和/或内联分析实施附加的分析,以便提供扩展元数据;以及
在所确定的时间点在智能储集池中存储发现点,所述发现点包括改变编目的内容、对应于存储在主要存储储集池中的发生改变的数据的标识符以及扩展元数据。
30.一种用于在数据存储***中处置数据的方法,其包括:
接收数据访问请求的拷贝以及涉及数据访问请求的元数据;
对与数据访问请求相关联的元数据执行进一步的分析,以便提供进一步的分析数据;以及
把元数据和进一步的分析合并,以便作为合并的元数据和进一步的分析数据存储在存储器件中。
31.权利要求30的方法,其中,从主要节点接收数据访问请求的拷贝,并且智能节点提供用于存储合并的元数据和进一步的分析数据的存储器件。
32.权利要求1的方法,其中,主要节点和智能节点位于同一处。
33.权利要求31的方法,其中,主要节点和智能节点的位置彼此远离。
34.权利要求31的方法,其中,单个处理节点实施主要节点和智能节点,并且智能节点在所述单个处理节点没有被主要节点的功能占用时执行。
35.权利要求30的方法,其中,所述元数据包括以下各项当中的一项或更多项:
涉及数据访问请求的扩展信息;
谁发起了数据访问请求;
发生了多少项修改;
修改的聚合尺寸;
数据对象名称;
数据对象所有者;
访问控制列表;或者
数据访问请求的时间。
36.权利要求31的方法,其中,智能节点还:
把数据访问请求引导到智能储集池;以及
创建发现点,从而把合并的元数据和进一步的分析数据与数据的智能储集池拷贝相关联。
37.权利要求36的方法,其中,智能节点还:
对发现点实施更深度分析,包括内容提取和/或对于存储在发现点中的信息的分析。
38.权利要求36的方法,其中,智能节点还:
把涉及与发生在两个或更多不同时间的数据访问请求相关联的两个或更多发现点的元数据进行比较。
39.权利要求38的方法,其还包括:
对改变编目、元数据和所提取的内容信息当中的至少一项执行一条或更多条规则,以便实施包括以下各项当中的一项或更多项的附加操作:
应用包括用以匹配内容和相关联的动作的过滤器的规则;
跟踪随着时间的数据或元数据的改变;
对被索引的文档应用情绪属性;
对常规表达法进行处理;
内容变换;
内容分析;或者
基于所检测到的访问或内容来触发动作,其中所述动作还包括以下各项当中的一项或更多项:
数据保留;
隔离;
数据提取;
删除;
数据分发;
告警;或者
其他动作。
40.权利要求39的方法,其中,执行一条或更多条规则的结果提供复杂分析,复杂分析被存储为附加到一个或更多改变编目的附加元数据。
41.权利要求31的方法,其中,智能节点还提供:
使用与发现点相关联的分析元数据对于主要节点的选择性还原。
42.权利要求41的方法,其中,所述选择性还原响应于在数据或元数据中发现预定模式。
43.权利要求31的方法,其中,智能节点还控制把数据、相关联的分析以及数据与相关联的分析之间的关联复制到远程位置。
44.权利要求43的方法,其还包括:
基于以下各项当中的一项或更多项在远程位置处选择性地复制分析元数据:
分析元数据的尺寸;
元数据产生处理的复杂度;
优先权;或者
处理负荷。
45.一种用于在数据智能存储***中还原数据的方法,所述数据智能存储***包括主要存储节点和智能存储节点,每一个这样的节点被编程为操作软件,其中
a、主要节点软件:
i、拦截数据访问请求;
ii、把数据镜像到在数据访问请求中所提到的智能节点,以便提供包括在数据访问请求中的数据的高可用性;
iii、对数据访问请求执行内联分析以便提供分析元数据;并且
iv、把数据访问请求引导到主要存储储集池;
b、智能节点软件:
i、把镜像数据存储到智能存储储集池;
ii、对镜像数据和/或先前执行的内联分析实施分析
iii、在智能储集池内创建发现点;并且
c、在表明需要还原数据时,主要节点和智能节点协作来使用分析元数据实施从智能储集池到主要储集池的实况还原操作。
46.权利要求45的方法,还包括:
a、作为前台处理首先仅还原对象元数据;
b、在与对象相关联的用户数据被完全还原之前,允许用户对于对象的I/O访问;以及
c、作为后台处理还原用户数据。
47.权利要求46的方法,还包括:
基于分析元数据对正被还原的用户数据进行优先权排序。
48.权利要求46的方法,还包括:
使用分析元数据和用户I/O操作对正被还原的用户数据对象的各个区段进行优先权排序。
49.权利要求47的方法,还包括:
a、一次还原多个对象;以及
b、使用分析元数据和用户I/O还原用户数据,以便确定用于还原所述多个对象的优先权。
50.权利要求45的方法,还包括:
a、拦截后续的实况文件请求;以及
b、从发现点强制实况还原,其中发现点还包括来源数据。
51.权利要求47的方法,还包括:
使用还原位图来跟踪还原进展,以便在对象被完全还原之间允许对于对象的随机I/O。
52.权利要求51的方法,其中,还原位图表示支持自动原子级还原的区段。
53.权利要求45的方法,还包括:
a、从智能储集池获得将要还原的文件的尺寸;
b、利用对象标识符FIleOID在主要储集池中的RestorePath中创建新的文件;
d、还原对应于将要还原的用户数据对象的元数据;
e、创建具有对象标识符和RestoreLinkOID的RestoreLink文件;
f、至少把还原尺寸、FileOID和零还原位图保存在RestoreLink文件中;以及
g、把RestoreLinkOID保存在主要储集池中的正被还原的新文件中的相应的属性上。
54.权利要求45的方法,还包括:
对个体文件实施实况还原操作。
55.权利要求54的方法,其中,文件实况还原操作还包括:
a、以原子级还原与文件有关的元数据;
b、允许对于正被还原的文件的用户I/O;
c、作为后台任务继续还原与文件有关的用户数据。
56.权利要求54的方法,其中,文件实况还原操作还包括:
a、基于用户I/O和先前收集的分析对正被还原的文件内的个体块的还原进行优先权排序。
57.权利要求45的方法,其中,智能节点软件还对目录和/或文件***层级实施目录/文件***实况还原操作,以便并行地还原多个文件和/或目录。
58.权利要求57的方法,其中,目录/文件***实况还原操作还包括:
a、创建目录/文件***元数据;
b、作为后台任务允许对于正被实况还原的文件***/目录的用户I/O;以及
c、作为文件实况还原操作还原个体文件。
59.权利要求57的方法,其中,目录/文件***实况还原操作还包括:
a、基于用户I/O和先前收集的分析对目录/文件***内的多个文件的还原进行优先权排序。
60.权利要求45的方法,还包括实施块层级实况还原以便把数据区域从复原站点还原到主要站点。
61.权利要求60的方法,其中,块层级实况还原还包括:
a、以原子级还原对应于站点的元数据,元数据包括对应于文件***和发现点的***元数据;
b、把所分配的区域映射图从复原站点上的虚拟盘层(VDL)传送到主要站点上的VDL;以及
c、在作为后台任务实施用户数据的每一个区域的还原的同时允许对于主要站点的用户I/O。
62.权利要求61的方法,还包括:
a、修剪所得到的元数据;以及
b、作为这样的修剪的结果或者作为在站点正被还原的同时允许对于站点的用户I/O的结果,解决对于VDL的TRIM操作。
63.权利要求60的方法,其中,块层级实况还原还包括:
a、基于用户I/O和先前收集的分析对每一个区域的还原进行优先权排序。
Applications Claiming Priority (9)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201361834806P | 2013-06-13 | 2013-06-13 | |
US61/834806 | 2013-06-13 | ||
US14/017754 | 2013-09-04 | ||
US14/017,754 US8849764B1 (en) | 2013-06-13 | 2013-09-04 | System and method of data intelligent storage |
US14/157,974 US9213706B2 (en) | 2013-06-13 | 2014-01-17 | Live restore for a data intelligent storage system |
US14/157974 | 2014-01-17 | ||
US14/203871 | 2014-03-11 | ||
US14/203,871 US9262281B2 (en) | 2013-06-13 | 2014-03-11 | Consolidating analytics metadata |
PCT/US2014/041486 WO2014200888A2 (en) | 2013-06-13 | 2014-06-09 | Live restore for a data intelligent storage system |
Publications (1)
Publication Number | Publication Date |
---|---|
CN105637487A true CN105637487A (zh) | 2016-06-01 |
Family
ID=52020126
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201480044623.7A Pending CN105637487A (zh) | 2013-06-13 | 2014-06-09 | 用于数据智能存储***的实况还原 |
Country Status (4)
Country | Link |
---|---|
US (1) | US9213706B2 (zh) |
EP (1) | EP3008599B1 (zh) |
CN (1) | CN105637487A (zh) |
WO (1) | WO2014200888A2 (zh) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106020739A (zh) * | 2016-07-12 | 2016-10-12 | 乐视控股(北京)有限公司 | 用于分布式存储的数据存储方法及*** |
CN106407045A (zh) * | 2016-09-29 | 2017-02-15 | 郑州云海信息技术有限公司 | 一种数据灾难恢复方法、***及服务器虚拟化*** |
CN107480010A (zh) * | 2017-08-21 | 2017-12-15 | 郑州云海信息技术有限公司 | 一种恢复元数据的方法及装置 |
CN109408277A (zh) * | 2018-11-02 | 2019-03-01 | 郑州云海信息技术有限公司 | 一种aep内存的数据块链路特性测试方法 |
CN110058958A (zh) * | 2018-01-18 | 2019-07-26 | 伊姆西Ip控股有限责任公司 | 用于管理数据备份的方法、设备和计算机程序产品 |
CN110100240A (zh) * | 2017-01-06 | 2019-08-06 | 甲骨文国际公司 | 用于zfs快照生成和存储的云网关 |
CN110968581A (zh) * | 2018-09-30 | 2020-04-07 | 北京国双科技有限公司 | 数据存储方法及装置 |
CN112379828A (zh) * | 2020-10-27 | 2021-02-19 | 华云数据控股集团有限公司 | 基于动态文件***的容器创建方法及装置 |
CN112567348A (zh) * | 2018-09-06 | 2021-03-26 | 欧姆龙株式会社 | 数据处理装置、数据处理方法和数据处理程序 |
Families Citing this family (109)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8078910B1 (en) * | 2008-12-15 | 2011-12-13 | Open Invention Network, Llc | Method and system for providing coordinated checkpointing to a group of independent computer applications |
US8307177B2 (en) | 2008-09-05 | 2012-11-06 | Commvault Systems, Inc. | Systems and methods for management of virtualization data |
US8819208B2 (en) | 2010-03-05 | 2014-08-26 | Solidfire, Inc. | Data deletion in a distributed data storage system |
US11449394B2 (en) | 2010-06-04 | 2022-09-20 | Commvault Systems, Inc. | Failover systems and methods for performing backup operations, including heterogeneous indexing and load balancing of backup and indexing resources |
US9838269B2 (en) | 2011-12-27 | 2017-12-05 | Netapp, Inc. | Proportional quality of service based on client usage and system metrics |
US9054992B2 (en) | 2011-12-27 | 2015-06-09 | Solidfire, Inc. | Quality of service policy sets |
CN103812675A (zh) * | 2012-11-08 | 2014-05-21 | 中兴通讯股份有限公司 | 一种实现业务交付平台异地容灾切换的方法和*** |
US20140181038A1 (en) | 2012-12-21 | 2014-06-26 | Commvault Systems, Inc. | Systems and methods to categorize unprotected virtual machines |
US9286086B2 (en) | 2012-12-21 | 2016-03-15 | Commvault Systems, Inc. | Archiving virtual machines in a data storage system |
US9703584B2 (en) | 2013-01-08 | 2017-07-11 | Commvault Systems, Inc. | Virtual server agent load balancing |
US20140201162A1 (en) | 2013-01-11 | 2014-07-17 | Commvault Systems, Inc. | Systems and methods to restore selected files from block-level backup for virtual machines |
US9286110B2 (en) | 2013-01-14 | 2016-03-15 | Commvault Systems, Inc. | Seamless virtual machine recall in a data storage system |
US10089192B2 (en) | 2013-06-13 | 2018-10-02 | Hytrust, Inc. | Live restore for a data intelligent storage system |
US8849764B1 (en) | 2013-06-13 | 2014-09-30 | DataGravity, Inc. | System and method of data intelligent storage |
US10102079B2 (en) | 2013-06-13 | 2018-10-16 | Hytrust, Inc. | Triggering discovery points based on change |
US9280423B1 (en) * | 2013-06-27 | 2016-03-08 | Emc Corporation | Mounting block level backup images |
CN104253842B (zh) * | 2013-06-28 | 2018-03-06 | 华为技术有限公司 | 同步终端镜像的方法、装置、终端及服务器 |
US20160048428A1 (en) | 2013-09-04 | 2016-02-18 | DataGravity, Inc. | Thin provisioned clone |
US20150074536A1 (en) | 2013-09-12 | 2015-03-12 | Commvault Systems, Inc. | File manager integration with virtualization in an information management system, including user control and storage management of virtual machines |
US10325032B2 (en) * | 2014-02-19 | 2019-06-18 | Snowflake Inc. | Resource provisioning systems and methods |
US20150244795A1 (en) | 2014-02-21 | 2015-08-27 | Solidfire, Inc. | Data syncing in a distributed system |
US20150278032A1 (en) * | 2014-04-01 | 2015-10-01 | Ca, Inc. | Providing services on system being recovered |
US9563518B2 (en) | 2014-04-02 | 2017-02-07 | Commvault Systems, Inc. | Information management by a media agent in the absence of communications with a storage manager |
US10459892B2 (en) | 2014-04-23 | 2019-10-29 | Qumulo, Inc. | Filesystem hierarchical aggregate metrics |
US20160019317A1 (en) | 2014-07-16 | 2016-01-21 | Commvault Systems, Inc. | Volume or virtual machine level backup and generating placeholders for virtual machine files |
US9710465B2 (en) | 2014-09-22 | 2017-07-18 | Commvault Systems, Inc. | Efficiently restoring execution of a backed up virtual machine based on coordination with virtual-machine-file-relocation operations |
US9436555B2 (en) * | 2014-09-22 | 2016-09-06 | Commvault Systems, Inc. | Efficient live-mount of a backed up virtual machine in a storage management system |
US9417968B2 (en) | 2014-09-22 | 2016-08-16 | Commvault Systems, Inc. | Efficiently restoring execution of a backed up virtual machine based on coordination with virtual-machine-file-relocation operations |
US10776209B2 (en) | 2014-11-10 | 2020-09-15 | Commvault Systems, Inc. | Cross-platform virtual machine backup and replication |
US9983936B2 (en) | 2014-11-20 | 2018-05-29 | Commvault Systems, Inc. | Virtual machine change block tracking |
US10298709B1 (en) * | 2014-12-31 | 2019-05-21 | EMC IP Holding Company LLC | Performance of Hadoop distributed file system operations in a non-native operating system |
US9836480B2 (en) | 2015-01-12 | 2017-12-05 | Qumulo, Inc. | Filesystem capacity and performance metrics and visualizations |
US11132336B2 (en) | 2015-01-12 | 2021-09-28 | Qumulo, Inc. | Filesystem hierarchical capacity quantity and aggregate metrics |
US10997030B2 (en) * | 2015-03-31 | 2021-05-04 | EMC IP Holding Company LLC | Disaster recovery as a service |
US10318491B1 (en) | 2015-03-31 | 2019-06-11 | EMC IP Holding Company LLC | Object metadata query with distributed processing systems |
US11016946B1 (en) * | 2015-03-31 | 2021-05-25 | EMC IP Holding Company LLC | Method and apparatus for processing object metadata |
US10387420B2 (en) * | 2015-08-20 | 2019-08-20 | International Business Machines Corporation | Dynamic modification of data set generation depth |
US10802928B2 (en) | 2015-09-10 | 2020-10-13 | International Business Machines Corporation | Backup and restoration of file system |
US10929246B2 (en) * | 2015-10-07 | 2021-02-23 | International Business Machines Corporation | Backup capability for object store used as primary storage |
US10606705B1 (en) | 2015-11-30 | 2020-03-31 | Veritas Technologies Llc | Prioritizing backup operations using heuristic techniques |
WO2017112737A1 (en) * | 2015-12-22 | 2017-06-29 | DataGravity, Inc. | Triggering discovery points based on change |
US9665446B1 (en) | 2015-12-29 | 2017-05-30 | International Business Machines Corporation | Fully distributed intelligent rebuild |
US10691556B2 (en) * | 2016-01-27 | 2020-06-23 | Quest Software Inc. | Recovering a specified set of documents from a database backup |
US10592350B2 (en) | 2016-03-09 | 2020-03-17 | Commvault Systems, Inc. | Virtual server cloud file system for virtual machine restore to cloud operations |
US10628264B1 (en) * | 2016-03-30 | 2020-04-21 | Veritas Technologies Llc | Context-driven data backup and recovery |
US10545943B2 (en) | 2016-04-05 | 2020-01-28 | International Business Machines Corporation | Change stream analytics for data replication systems |
US20170286513A1 (en) | 2016-04-05 | 2017-10-05 | International Business Machines Corporation | Supplementing change streams |
US10789134B2 (en) * | 2016-04-15 | 2020-09-29 | Netapp, Inc. | NVRAM loss handling |
US10929022B2 (en) | 2016-04-25 | 2021-02-23 | Netapp. Inc. | Space savings reporting for storage system supporting snapshot and clones |
US10621370B2 (en) * | 2016-05-27 | 2020-04-14 | Intel Corporation | Methods and apparatus to provide group-based row-level security for big data platforms |
CN106201818B (zh) * | 2016-06-24 | 2019-01-01 | 青岛海信移动通信技术股份有限公司 | 一种应用程序运行时间的统计方法和装置 |
US10678578B2 (en) * | 2016-06-30 | 2020-06-09 | Microsoft Technology Licensing, Llc | Systems and methods for live migration of a virtual machine based on heat map and access pattern |
US10642763B2 (en) | 2016-09-20 | 2020-05-05 | Netapp, Inc. | Quality of service policy sets |
US10126946B1 (en) * | 2016-09-30 | 2018-11-13 | EMC IP Holding Company LLC | Data protection object store |
US10747630B2 (en) | 2016-09-30 | 2020-08-18 | Commvault Systems, Inc. | Heartbeat monitoring of virtual machines for initiating failover operations in a data storage management system, including operations by a master monitor node |
US10152251B2 (en) | 2016-10-25 | 2018-12-11 | Commvault Systems, Inc. | Targeted backup of virtual machine |
US10162528B2 (en) | 2016-10-25 | 2018-12-25 | Commvault Systems, Inc. | Targeted snapshot based on virtual machine location |
US10257258B2 (en) | 2016-10-31 | 2019-04-09 | International Business Machines Corporation | Transferring data between block and file storage systems |
US10678758B2 (en) | 2016-11-21 | 2020-06-09 | Commvault Systems, Inc. | Cross-platform virtual machine data and memory backup and replication |
US10095729B2 (en) | 2016-12-09 | 2018-10-09 | Qumulo, Inc. | Managing storage quotas in a shared storage system |
US10346355B2 (en) * | 2016-12-23 | 2019-07-09 | Qumulo, Inc. | Filesystem block sampling to identify user consumption of storage resources |
US10198326B2 (en) | 2017-03-09 | 2019-02-05 | Apple Inc. | Intelligent restoration of a computing device |
US10896100B2 (en) * | 2017-03-24 | 2021-01-19 | Commvault Systems, Inc. | Buffered virtual machine replication |
US10387073B2 (en) | 2017-03-29 | 2019-08-20 | Commvault Systems, Inc. | External dynamic virtual machine synchronization |
US10782997B1 (en) * | 2017-10-31 | 2020-09-22 | EMC IP Holding Company, LLC | Storage management system and method |
US10552071B1 (en) * | 2017-10-31 | 2020-02-04 | EMC IP Holding Company LLC | Layered data path architecture for data protection and mobility |
US10877928B2 (en) | 2018-03-07 | 2020-12-29 | Commvault Systems, Inc. | Using utilities injected into cloud-based virtual machines for speeding up virtual machine backup operations |
US10783043B2 (en) | 2018-03-16 | 2020-09-22 | EMC IP Holding Company LLC | Automation and optimization of data recovery after a ransomware attack |
US11360936B2 (en) | 2018-06-08 | 2022-06-14 | Qumulo, Inc. | Managing per object snapshot coverage in filesystems |
US11200124B2 (en) | 2018-12-06 | 2021-12-14 | Commvault Systems, Inc. | Assigning backup resources based on failover of partnered data storage servers in a data storage management system |
US10534758B1 (en) | 2018-12-20 | 2020-01-14 | Qumulo, Inc. | File system cache tiers |
US10614033B1 (en) | 2019-01-30 | 2020-04-07 | Qumulo, Inc. | Client aware pre-fetch policy scoring system |
US10768971B2 (en) | 2019-01-30 | 2020-09-08 | Commvault Systems, Inc. | Cross-hypervisor live mount of backed up virtual machine data |
US11151092B2 (en) | 2019-01-30 | 2021-10-19 | Qumulo, Inc. | Data replication in distributed file systems |
US10996974B2 (en) | 2019-01-30 | 2021-05-04 | Commvault Systems, Inc. | Cross-hypervisor live mount of backed up virtual machine data, including management of cache storage for virtual machine data |
AU2020264946B2 (en) | 2019-04-30 | 2022-11-17 | Clumio, Inc. | Deduplication in a cloud-based data protection service |
US10725977B1 (en) | 2019-10-21 | 2020-07-28 | Qumulo, Inc. | Managing file system state during replication jobs |
US11243851B2 (en) * | 2020-01-15 | 2022-02-08 | EMC IP Holding Company LLC | Intelligent storage and recovery of backup data using multiple storage tiers of a cloud-based storage |
US10860372B1 (en) | 2020-01-24 | 2020-12-08 | Qumulo, Inc. | Managing throughput fairness and quality of service in file systems |
US10795796B1 (en) | 2020-01-24 | 2020-10-06 | Qumulo, Inc. | Predictive performance analysis for file systems |
US11151001B2 (en) | 2020-01-28 | 2021-10-19 | Qumulo, Inc. | Recovery checkpoints for distributed file systems |
US10860414B1 (en) | 2020-01-31 | 2020-12-08 | Qumulo, Inc. | Change notification in distributed file systems |
US11467753B2 (en) | 2020-02-14 | 2022-10-11 | Commvault Systems, Inc. | On-demand restore of virtual machine data |
US11442768B2 (en) | 2020-03-12 | 2022-09-13 | Commvault Systems, Inc. | Cross-hypervisor live recovery of virtual machines |
US11099956B1 (en) | 2020-03-26 | 2021-08-24 | Commvault Systems, Inc. | Snapshot-based disaster recovery orchestration of virtual machine failover and failback operations |
US10936551B1 (en) | 2020-03-30 | 2021-03-02 | Qumulo, Inc. | Aggregating alternate data stream metrics for file systems |
US10936538B1 (en) | 2020-03-30 | 2021-03-02 | Qumulo, Inc. | Fair sampling of alternate data stream metrics for file systems |
US11500669B2 (en) | 2020-05-15 | 2022-11-15 | Commvault Systems, Inc. | Live recovery of virtual machines in a public cloud computing environment |
US11775481B2 (en) | 2020-09-30 | 2023-10-03 | Qumulo, Inc. | User interfaces for managing distributed file systems |
US11656951B2 (en) | 2020-10-28 | 2023-05-23 | Commvault Systems, Inc. | Data loss vulnerability detection |
US11556558B2 (en) | 2021-01-11 | 2023-01-17 | International Business Machines Corporation | Insight expansion in smart data retention systems |
US11157458B1 (en) | 2021-01-28 | 2021-10-26 | Qumulo, Inc. | Replicating files in distributed file systems using object-based data storage |
US11461241B2 (en) | 2021-03-03 | 2022-10-04 | Qumulo, Inc. | Storage tier management for file systems |
US11132126B1 (en) | 2021-03-16 | 2021-09-28 | Qumulo, Inc. | Backup services for distributed file systems in cloud computing environments |
US11567660B2 (en) | 2021-03-16 | 2023-01-31 | Qumulo, Inc. | Managing cloud storage for distributed file systems |
US12026131B2 (en) * | 2021-06-14 | 2024-07-02 | Vast Data Ltd. | Parallel traversal of a filesystem tree |
US11669255B2 (en) | 2021-06-30 | 2023-06-06 | Qumulo, Inc. | Distributed resource caching by reallocation of storage caching using tokens and agents with non-depleted cache allocations |
KR20230056901A (ko) * | 2021-10-21 | 2023-04-28 | 에스케이하이닉스 주식회사 | 메모리 장치에 데이터를 프로그램하는 장치 및 방법 |
US11294604B1 (en) | 2021-10-22 | 2022-04-05 | Qumulo, Inc. | Serverless disk drives based on cloud storage |
US11354273B1 (en) | 2021-11-18 | 2022-06-07 | Qumulo, Inc. | Managing usable storage space in distributed file systems |
US11599508B1 (en) | 2022-01-31 | 2023-03-07 | Qumulo, Inc. | Integrating distributed file systems with object stores |
US11797393B2 (en) | 2022-03-23 | 2023-10-24 | Bank Of America Corporation | Table prioritization for data copy in a multi-environment setup |
US11656955B1 (en) | 2022-03-23 | 2023-05-23 | Bank Of America Corporation | Database table valuation |
US20230315586A1 (en) * | 2022-03-30 | 2023-10-05 | Pure Storage, Inc. | Usage-based Restore Prioritization |
US11722150B1 (en) | 2022-09-28 | 2023-08-08 | Qumulo, Inc. | Error resistant write-ahead log |
US11729269B1 (en) | 2022-10-26 | 2023-08-15 | Qumulo, Inc. | Bandwidth management in distributed file systems |
US11966592B1 (en) | 2022-11-29 | 2024-04-23 | Qumulo, Inc. | In-place erasure code transcoding for distributed file systems |
US11921677B1 (en) | 2023-11-07 | 2024-03-05 | Qumulo, Inc. | Sharing namespaces across file system clusters |
US11934660B1 (en) | 2023-11-07 | 2024-03-19 | Qumulo, Inc. | Tiered data storage with ephemeral and persistent tiers |
Family Cites Families (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5454099A (en) | 1989-07-25 | 1995-09-26 | International Business Machines Corporation | CPU implemented method for backing up modified data sets in non-volatile store for recovery in the event of CPU failure |
US6470420B1 (en) * | 2000-03-31 | 2002-10-22 | Western Digital Ventures, Inc. | Method for designating one of a plurality of addressable storage devices to process a data transfer request |
US7325051B2 (en) * | 2001-11-06 | 2008-01-29 | International Business Machines Corporation | Integrated storage appliance |
CN1591400A (zh) | 2001-11-09 | 2005-03-09 | 无锡永中科技有限公司 | 集成数据处理*** |
US6983303B2 (en) * | 2002-01-31 | 2006-01-03 | Hewlett-Packard Development Company, Lp. | Storage aggregator for enhancing virtualization in data storage networks |
EP1738260B1 (en) | 2004-01-09 | 2010-02-10 | T.W. Storage, Inc. | Method and apparatus for searching backup data based on content and attributes |
US7412577B2 (en) | 2004-02-05 | 2008-08-12 | International Business Machines Corporation | Shared data mirroring apparatus, method, and system |
US7246258B2 (en) | 2004-04-28 | 2007-07-17 | Lenovo (Singapore) Pte. Ltd. | Minimizing resynchronization time after backup system failures in an appliance-based business continuance architecture |
US8055745B2 (en) | 2004-06-01 | 2011-11-08 | Inmage Systems, Inc. | Methods and apparatus for accessing data from a primary data storage system for secondary storage |
US20060117048A1 (en) | 2004-11-30 | 2006-06-01 | Microsoft Corporation | Method and system of synchronizing filter metadata after a restore |
US7672979B1 (en) | 2005-04-22 | 2010-03-02 | Symantec Operating Corporation | Backup and restore techniques using inconsistent state indicators |
US20080228771A1 (en) | 2006-12-22 | 2008-09-18 | Commvault Systems, Inc. | Method and system for searching stored data |
US8161011B2 (en) * | 2007-07-31 | 2012-04-17 | International Business Machines Corporation | Apparatus, system, and method for analyzing a file system |
US20090083336A1 (en) | 2007-09-26 | 2009-03-26 | Microsoft Corporation | Search based data management |
WO2010014851A2 (en) * | 2008-07-30 | 2010-02-04 | Diomede Corporation | Systems and methods for power aware data storage |
US8108364B2 (en) * | 2008-08-06 | 2012-01-31 | International Business Machines Corporation | Representation of system clock changes in time based file systems |
US8032707B2 (en) | 2008-09-15 | 2011-10-04 | Microsoft Corporation | Managing cache data and metadata |
WO2010065271A2 (en) * | 2008-11-25 | 2010-06-10 | Board Of Governors For Higher Education, State Of Rhode Island And Providence Plantations | Systems and methods for providing continuous file protection at block level |
JP5156682B2 (ja) * | 2009-04-23 | 2013-03-06 | 株式会社日立製作所 | ストレージシステムにおけるバックアップ方法 |
US20100293147A1 (en) * | 2009-05-12 | 2010-11-18 | Harvey Snow | System and method for providing automated electronic information backup, storage and recovery |
US8140573B2 (en) | 2009-06-15 | 2012-03-20 | International Business Machines Corporation | Exporting and importing business objects based on metadata |
US8364636B2 (en) * | 2009-09-14 | 2013-01-29 | International Business Machines Corporation | Real time data replication |
US9239843B2 (en) * | 2009-12-15 | 2016-01-19 | Symantec Corporation | Scalable de-duplication for storage systems |
WO2013001146A2 (en) * | 2011-06-30 | 2013-01-03 | Nokia Corporation | Method and apparatus for real-time processing of data items |
US9910904B2 (en) | 2011-08-30 | 2018-03-06 | International Business Machines Corporation | Replication of data objects from a source server to a target server |
US9183529B2 (en) | 2012-08-01 | 2015-11-10 | Oracle International Corporation | Business intelligence performance analysis system |
-
2014
- 2014-01-17 US US14/157,974 patent/US9213706B2/en active Active
- 2014-06-09 CN CN201480044623.7A patent/CN105637487A/zh active Pending
- 2014-06-09 EP EP14736180.2A patent/EP3008599B1/en active Active
- 2014-06-09 WO PCT/US2014/041486 patent/WO2014200888A2/en active Application Filing
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106020739A (zh) * | 2016-07-12 | 2016-10-12 | 乐视控股(北京)有限公司 | 用于分布式存储的数据存储方法及*** |
CN106407045A (zh) * | 2016-09-29 | 2017-02-15 | 郑州云海信息技术有限公司 | 一种数据灾难恢复方法、***及服务器虚拟化*** |
CN106407045B (zh) * | 2016-09-29 | 2019-09-24 | 郑州云海信息技术有限公司 | 一种数据灾难恢复方法、***及服务器虚拟化*** |
CN110100240B (zh) * | 2017-01-06 | 2023-12-12 | 甲骨文国际公司 | 用于zfs快照生成和存储的云网关 |
US11755535B2 (en) | 2017-01-06 | 2023-09-12 | Oracle International Corporation | Consistent file system semantics with cloud object storage |
CN110100240A (zh) * | 2017-01-06 | 2019-08-06 | 甲骨文国际公司 | 用于zfs快照生成和存储的云网关 |
US11714784B2 (en) | 2017-01-06 | 2023-08-01 | Oracle International Corporation | Low-latency direct cloud access with file system hierarchies and semantics |
CN107480010A (zh) * | 2017-08-21 | 2017-12-15 | 郑州云海信息技术有限公司 | 一种恢复元数据的方法及装置 |
CN110058958B (zh) * | 2018-01-18 | 2023-07-25 | 伊姆西Ip控股有限责任公司 | 用于管理数据备份的方法、设备和计算机程序产品 |
CN110058958A (zh) * | 2018-01-18 | 2019-07-26 | 伊姆西Ip控股有限责任公司 | 用于管理数据备份的方法、设备和计算机程序产品 |
CN112567348A (zh) * | 2018-09-06 | 2021-03-26 | 欧姆龙株式会社 | 数据处理装置、数据处理方法和数据处理程序 |
CN112567348B (zh) * | 2018-09-06 | 2024-05-31 | 欧姆龙株式会社 | 数据处理装置、数据处理方法和计算机可读存储介质 |
CN110968581B (zh) * | 2018-09-30 | 2023-07-04 | 北京国双科技有限公司 | 数据存储方法及装置 |
CN110968581A (zh) * | 2018-09-30 | 2020-04-07 | 北京国双科技有限公司 | 数据存储方法及装置 |
CN109408277B (zh) * | 2018-11-02 | 2021-10-29 | 郑州云海信息技术有限公司 | 一种aep内存的数据块链路特性测试方法 |
CN109408277A (zh) * | 2018-11-02 | 2019-03-01 | 郑州云海信息技术有限公司 | 一种aep内存的数据块链路特性测试方法 |
CN112379828A (zh) * | 2020-10-27 | 2021-02-19 | 华云数据控股集团有限公司 | 基于动态文件***的容器创建方法及装置 |
CN112379828B (zh) * | 2020-10-27 | 2024-03-19 | 华云数据控股集团有限公司 | 基于动态文件***的容器创建方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
WO2014200888A3 (en) | 2015-09-11 |
EP3008599A2 (en) | 2016-04-20 |
WO2014200888A2 (en) | 2014-12-18 |
US20140372384A1 (en) | 2014-12-18 |
EP3008599B1 (en) | 2017-04-19 |
US9213706B2 (en) | 2015-12-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105637487A (zh) | 用于数据智能存储***的实况还原 | |
US10089192B2 (en) | Live restore for a data intelligent storage system | |
US9785518B2 (en) | Multi-threaded transaction log for primary and restore/intelligence | |
US10061658B2 (en) | System and method of data intelligent storage | |
US10102079B2 (en) | Triggering discovery points based on change | |
US10860426B2 (en) | Content-independent and database management system-independent synthetic full backup of a database based on snapshot technology | |
US10871904B2 (en) | Secondary storage editor | |
CN104981802B (zh) | 针对对象存储器索引***的内容类别 | |
US8352523B1 (en) | Recovering a file system to any point-in-time in the past with guaranteed structure, content consistency and integrity | |
US8108429B2 (en) | System for moving real-time data events across a plurality of devices in a network for simultaneous data protection, replication, and access services | |
US7386530B2 (en) | System and method for managing content including addressability features | |
CN103415842A (zh) | 用于数据管理虚拟化的***和方法 | |
CN104769555A (zh) | 增强型数据管理虚拟化*** | |
CN110245037A (zh) | 一种基于日志的Hive用户操作行为还原方法 | |
WO2017112737A1 (en) | Triggering discovery points based on change | |
Padhy et al. | Hadoop File Management System | |
WO2016028757A2 (en) | Multi-threaded transaction log for primary and restore/intelligence | |
CA2531714C (en) | A method and system for preserving access to a system in case of a disaster |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20160601 |