US20070094312A1 - Method for managing real-time data history of a file system - Google Patents
Method for managing real-time data history of a file system Download PDFInfo
- Publication number
- US20070094312A1 US20070094312A1 US11/638,253 US63825306A US2007094312A1 US 20070094312 A1 US20070094312 A1 US 20070094312A1 US 63825306 A US63825306 A US 63825306A US 2007094312 A1 US2007094312 A1 US 2007094312A1
- Authority
- US
- United States
- Prior art keywords
- data
- version
- file
- dms
- directory
- 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.)
- Abandoned
Links
Images
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
- G06F16/11—File system administration, e.g. details of archiving or snapshots
- G06F16/122—File system administration, e.g. details of archiving or snapshots using management policies
- G06F16/125—File system administration, e.g. details of archiving or snapshots using management policies characterised by the use of retention policies
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
- G06F11/3495—Performance evaluation by tracing or monitoring for systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/86—Event-based monitoring
Definitions
- the present invention relates generally to enterprise data management.
- IT information technology
- FIG. 1 illustrates a representative enterprise 100 in which a data management system (DMS) is implemented to provide enterprise data protection.
- DMS data management system
- a commercial version of this architecture is available from Asempra Technologies, Inc., of Sunnyvale, Calif.
- an enterprise 100 comprises a primary data tier 102 and a secondary data tier 104 distributed over IP-based wide area networks 106 and 108 .
- Wide area network 106 interconnects two primary data centers 110 and 112
- wide area network 108 interconnects a regional or satellite office 114 to the rest of the enterprise.
- the primary data tier 102 comprises application servers 116 running various applications such as databases, email servers, file servers, and the like, together with associated primary storage 118 (e.g., direct attached storage (DAS), network attached storage (NAS), storage area network (SAN)).
- the secondary data tier 104 typically comprises one or more data management server nodes, and secondary storage 120 , which may be DAS, NAS, and SAN.
- the secondary storage may be serial ATA interconnection through SCSI, Fibre Channel (FC or the like), or iSCSI.
- the data management server nodes create a logical layer that offers object virtualization and protected data storage.
- the secondary data tier is interconnected to the primary data tier, preferably through one or more host drivers to provide real-time data services.
- Data management policies 126 are implemented across the secondary storage in a well-known manner.
- a similar architecture is provided in data center 112 . In this example, the regional office 114 does not have its own secondary storage, but relies instead on the facilities in the primary data centers.
- the DMS system associates a “host driver” 128 with one or more of the application(s) running in the application servers 116 to transparently and efficiently capture the real-time, continuous history of all (or substantially all) transactions and changes to data associated with such application(s) across the enterprise network.
- This facilitates real-time, so-called “application aware” protection, with substantially no data loss, to provide continuous data protection and other data services including, without limitation, data distribution, data replication, data copy, data access, and the like.
- a given host driver 128 intercepts data events between an application and its primary data storage, and it may also receive data and application events directly from the application and database.
- the host driver 128 may be embedded in the host application server 116 where the application resides; alternatively, the host driver is embedded in the network on the application data path. By intercepting data through the application, fine grain (but opaque) data is captured to facilitate the data service(s).
- each of the primary data centers includes a set of one or more data management servers 130 a-n that cooperate with the host drivers 128 to facilitate the data services.
- the DMS servers provide a distributed object storage that can be built above raw storage devices, a traditional file system, a special purpose file system, a clustered file system, a database, or the like.
- the data center 110 supports a first core region 130
- the data center 112 supports a second core region 132 .
- each DMS node executes an object runtime environment.
- This object runtime environment includes an object manager that manages the lifecycle of all the DMS objects during runtime.
- the object manager creates DMS objects, and the object manager saves them in the shared storage.
- the objects continually undergo modification as the system protects data in the enterprise's primary storage.
- the system automatically creates a trail of objects called versions; typically, the versions do not actually exist on primary storage, outside of the data management system.
- the DMS manages the creation, storage, display, recovery to primary storage, deletion (automatic via policy, or manual) and the like, of these versions.
- the host drivers protect data into the continuous object data store. Using this architecture, data in primary storage can be recovered to any point-in-time.
- a data management method for storing a real-time history of a file system, or a component thereof, such as a directory or a file.
- the real-time history is stored as an object-oriented logical representation comprising at least a set of version metadata objects, and a set of one or more links that associate given objects of the set of version metadata objects.
- the logical representation is restructured dynamically. The logical representation is useful to provide any point-in-time reconstruction of the file system component on an as-needed basis.
- the object-oriented logical representation is advantageous as it provides an efficient way to index a real-time history of changing data in a file system.
- This representation preferably is constructed over a database, such as a relational database, a raw file system, or any other set of one or more storage devices.
- FIG. 1 is an illustrative enterprise network in which the present invention may be deployed
- FIG. 2 is an illustration of a general data management system (DMS) of the present invention
- FIG. 3 is an illustration of a representative DMS network according to one embodiment of the present invention.
- FIG. 4 illustrates an object data structure for tracking data history according to a preferred embodiment
- FIG. 5 illustrates a representative DMS object instance hierarchy according to a preferred embodiment
- FIG. 6 illustrates a sample instance of a directory object
- FIG. 7 illustrates a sample instance of a file object
- FIG. 8 illustrates a sample file system history according to the present invention
- FIG. 9 illustrates another sample file system history
- FIG. 10 is a flow diagram illustrating a process for creating a file or a directory in the DMS file system history structure
- FIG. 11 illustrates the sample file history of FIG. 9 after a new file object has been created in the DMS
- FIG. 12 is a flow diagram illustrating a process for modifying a file or a directory in the DMS file system history structure
- FIG. 13 illustrates how modifying a directory object alters the DMS object store of FIG. 11 ;
- FIG. 14 illustrates how modifying a file object alters the DMS object store of FIG. 11 ;
- FIG. 15 is a flow diagram illustrating a process for deleting a file or a directory in the DMS file system history structure
- FIG. 16 illustrates how deleting a file object alters the DMS object store of FIG. 14 ;
- FIG. 17 is a flow diagram illustrating a process for renaming or relocating a file or a directory in the DMS file system history structure
- FIG. 18 illustrates representative DMS data structure changes (with respect to FIG. 16 ) that occur when a file is renamed and the parent does not track a child name;
- FIG. 19 illustrates representative DMS data structure changes (with respect to FIG. 16 ) when the file is renamed and the parent does track child name;
- FIG. 20 illustrates representative DMS data structure changes (with respect to FIG. 19 ) when a file is relocated and versioned by object instance;
- FIG. 21 illustrates representative DMS data structure changes (once again with respect to FIG. 19 ) when the file is relocated and versioned by object path;
- FIG. 22 illustrates several variants of the relocation technique of FIG. 21 ;
- FIG. 23 illustrates a sample baseline file system object store prior to a directory relocation
- FIG. 24 illustrates a directory relocation based on a versioned by object instance model using FIG. 23 as the initial baseline
- FIG. 25 illustrates a directory relocation based on versioned by object path model using FIG. 23 as the initial baseline
- FIG. 26 illustrates a directory relocation based on a combination of versioned by object path and versioned by object instance, once again using FIG. 23 as the initial baseline.
- FIG. 2 illustrates a preferred hierarchical structure of a data management system 200 in which the present invention may be implemented.
- the data management system 200 comprises one or more regions 202 a - n, with each region 202 comprising one or more clusters 204 a - n.
- a given cluster 204 includes one or more nodes 206 a - n and a shared storage 208 shared by the nodes 206 within the cluster 204 .
- a given node 206 is a data management server as described above with respect to FIG. 1 .
- Within a DMS cluster 204 preferably all the nodes 206 perform parallel access to the data in the shared storage 208 .
- the nodes 206 are hot swappable to enable new nodes to be added and existing nodes to be removed without causing cluster downtime.
- a cluster is a tightly-coupled, share everything grouping of nodes.
- the DMS is a loosely-coupled share nothing grouping of DMS clusters.
- all DMS clusters have shared knowledge of the entire network, and all clusters preferably share partial or summary information about the data that they possess. Network connections (e.g., sessions) to one DMS node in a DMS cluster may be re-directed to another DMS node in another cluster when data is not present in the first DMS cluster but may be present in the second DMS cluster.
- new DMS clusters may be added to the DMS cloud without interfering with the operation of the existing DMS clusters.
- a DMS cluster fails, its data may be accessed in another cluster transparently, and its data service responsibility may be passed on to another DMS cluster.
- FIG. 3 illustrates the data management system (DMS) as a network (in effect, a wide area network “cloud”) of peer-to-peer DMS service nodes.
- the DMS cloud 300 typically comprises one or more DMS regions, with each region comprising one or more DMS “clusters.”
- DMS regions typically there are two different types of DMS regions, in this example an “edge” region 306 and a “core” region 308 . This nomenclature is not to be taken to limit the invention, of course.
- An edge region 306 typically is a smaller office or data center where the amount of data hosted is limited and/or where a single node DMS cluster is sufficient to provide necessary data services.
- core regions 308 are medium or large size data centers where one or more multi-node clusters are required or desired to provide the necessary data services.
- the DMS preferably also includes a management gateway 310 for controlling the system.
- the DMS can be visualized as a set of data sources 312 .
- a data source is a representation of a related group of fine grain data.
- a data source may be a directory of files and subdirectory, or it may be a database, or a combination of both.
- a data source 312 inside a DMS cluster captures a range of history and continuous changes of, for example, an external data source in a host server.
- a data source may reside in one cluster, and it may replicate to other clusters or regions based on subscription rules. If a data source exists in the storage of a DMS cluster, preferably it can be accessed through any one of the DMS nodes in that cluster. If a data source does not exist in a DMS cluster, then the requesting session may be redirected to another DMS cluster that has the data; alternatively, the current DMS cluster may perform an on-demand caching to bring in the data.
- the DMS provides real time data services, such as continuous data protection, data replication, data distribution, any-point-in-time recovery, and any-point-in-time snapshot.
- the DMS host driver resides in an application host or the network, monitoring and capturing application events and data changes in real time, and then processing and forwarding actual data changes, events, and metadata to a DMS node.
- the host driver preferably performs delta reduction (e.g., to extract byte level changes), identifies metadata changes such as access control, detects application checkpoint events, and then forwards this information as a stream to a DMS node in a DMS cluster.
- a DMS cluster is a group of DMS nodes that share a storage module. These nodes work as a cooperative unit. Preferably, they obey a set of access rules such as acquiring lock of different classes, and they honor the access locks of the others so as to perform parallel access to the storage module. These nodes also watch for the health of one another and when one node fails, the other nodes preferably repair any partially modified or corrupted data that may be caused by the failure, and take over the tasks of the failed node.
- the DMS nodes are the entities that provides real-time data services.
- the nodes take incoming data streams, preferably translate the streams into an object-oriented data structure (or another structure that provides similar data associations and indices), and save the data in a storage module that is referred to herein as an object store.
- the object store is designed with the purpose of managing real-time continuous history.
- the DMS node navigates its object store, reconstructs a desired point-in-time data object, and forms outbound data streams that are then delivered to target nodes or host machines.
- the DMS node To provide continuous replication, once replicating a point-in-time data object, the DMS node also forwards, to a remote DMS or a remote host server, a continuous redo log of the objects (in the form of a real-time event journal).
- a goal of the DMS is to store fine grain and real-time data history.
- the DMS object store is designed to track fine grain data changes without using excessive storage.
- the DMS preferably also indexes by time and events all fine grain objects, application checkpoints, and metadata globally across DMS clusters.
- the events may include any object events such as email arrival, transaction activity, a file open, a file modification, a file close, a directory change, an application checkpoint, a system upgrade, a virus detection (such as from an external network service), a business event tag, or the like.
- object events such as email arrival, transaction activity, a file open, a file modification, a file close, a directory change, an application checkpoint, a system upgrade, a virus detection (such as from an external network service), a business event tag, or the like.
- the DMS nodes create distributed object storage to provide the necessary real-time data management services.
- the objects created by the DMS nodes are sometimes referred to herein as active objects.
- the active objects at any moment in time may be dormant in the storage or instantiated by the DMS nodes to handle requests and to perform activities. The details of active objects are discussed in the following sections.
- the distributed object store can be built above raw storage devices, a traditional file system, a special purpose file system, a clustered file system, a database, and so on.
- DMS chooses to build the distributed object store over a special purpose file system for storage and access efficiency.
- the files in the special purpose file system and the active objects in the DMS preferably are all addressed by a (e.g., 128 bit) global unique identifier (GUID).
- GUID global unique identifier
- a GUID can be de-referenced to a physical address in a storage device.
- an object ( 1 ) in a device (A) can refer to another object ( 2 ) in device (B), e.g., by referring to the GUID of object ( 2 ).
- each DMS node executes an object runtime environment.
- This object runtime environment includes an object manager that manages the lifecycle of all the DMS objects during runtime.
- the object manager creates DMS objects, namely the active objects, and the object manager saves them in the shared storage.
- the object manager loads an existing active object from the storage, and then routes object requests directly to the instantiated active object.
- the object manager may perform authentication and/or authorization before allowing any access to an active object.
- An active object upon request, may update its internal information, execute an object specific program, and terminate itself from the runtime environment.
- Both the object manager and the active objects are responsible for acquiring shared lock as necessary so that all the nodes can have parallel access to the same objects.
- the object manager is also responsible for permanently removing active objects from the shared storage when requested. In a non object-oriented embodiment, an object manager may not be required. Also, while the use of an object manner is preferred, it is also possible to implement the present invention by storing the object information in a different manner while still achieving similar results, and the processes and object functions that change the information may be modified accordingly.
- an instance of an active object has a set of properties, with each property having a label and value pair.
- an active object may have one property labeled as “name” with an associated value being “The design of a PC,” and another property labeled “content” which associated value is a binary blob.
- a property has a value type definition, for example, the value of the “name” property is a string, and the value of the “content” property is an opaque binary chunk of data.
- the DMS active object for the file may have a list of representative properties such as shown below:
- ObjGUID ⁇ a 128 bit unique identifier for this object>
- ParentObject ⁇ a GUID of a directory object>
- Keywords ⁇ a string>
- the DMS active objects store metadata from the protected server as well as metadata generated by the DMS itself.
- all the properties are metadata, including the binary content from the external world, while binary content is just a specific property type (random access binary blob type).
- a property on an active object preferably also has specific attributes such as -modifiable, modifiable-internal, read-able, versionable, single-value vs multi-value, inheritable, index, mandatory, replicate-able, and the like.
- Some object properties such as ObjectClass, ObjGUID, Creator, ExternalCreationDateTime, and DMSCreationDateTime do not change once the object is created, while the other properties can be modified.
- Property Type Description Integer a number String a Text string GUID Preferably a 128 bit global unique ID across all DMS nodes. This property store the GUID of another object that allows objects to be linked. Constant a set of related unique numbers that represent some specific information Random access binary blob Binary data for random access Sequential access binary blob Sequential records Boolean True/false ComplexType Combination of one or more of the above
- Inheritable False when object receives a request for the property, and if the property is not set, the object can request for the value from its parent in the object hierarchy. For example, a file object may request for a value from its directory object. By default, all properties are not inheritable. Index False If True, the DMS automatically generates a specific index for the property to accelerate search. Indeed, the entire object structure may be considered an indexing structure; however, by having a specific property index, the system allows for a focused and efficient search on that property. Once indexed, the object can be searched using the index of the property. The indexed properties are name, fingerprint, and the like. By default, a property is specifically indexed. If a property is not indexed, preferably it is still searchable by an algorithm iterating through all the objects. Replicate-able True If Replicate-able is True, then when the associated property is replicated when the object is replicated.
- an object data structure for tracking data history is as shown in FIG. 4 .
- pages are simply logical and variable size chunk of data entities. Each page is labeled with a GUID.
- An anchor page 401 contains the ⁇ property, value> of those metadata that are not version-able and do not change over time, while the metadata page ( 402 , 403 and 404 ) of each version contains only the versioned properties.
- the pages refer to one another by GUID (which is an address or a link to another group of information).
- an object may have an access control list (ACL) that specifies who has what level of access right to the data.
- ACL access control list
- the ACL is stored in a separate page 405 or 406 , such that multiple objects that have the same ACL can refer to the same ACL page.
- Multiple ACL pages can also be grouped into a sorted structure and stored in a physical storage unit. Access control lists can also be stored within the version metadata pages or as separate active objects.
- the object anchor and version pages can also be grouped and re-organized for storage efficiency to fit in one or multiple physical storage units.
- these different pages can be structured in a non object-oriented way, such as by using relational database tables. As long as the information can be linked and indexed, the present invention can be realized by such different implementations.
- each one of the pages can be stored in a separate file, or in raw storage blocks.
- each file is also named by GUID.
- GUID There are page GUID to file GUID mappings, and file GUID to physical address mappings so that the physical data of an object can be retrieved.
- An object can be reference by the GUID of its anchor page, or the GUID of its version metadata page. When referred by the GUID of its version metadata page, a point-in-time object is presented.
- an active object has a basic set of behaviors and some specific set of behaviors that are schema dependent and may be created specifically for the class definition.
- the following are examples of interfaces that initiate specific object activities.
- a basic set of behaviors that may be initiated by the interface for life cycle management, getting and setting attributes:
- the above object interfaces are a representative subset of the actual basic object behaviors of the DMS. There are merely illustrative of the functional behavior of the active objects. If desired, an object class may define its own set of specific behaviors.
- FIGS. 6-7 illustrate sample instances of a respective directory object and a file object.
- the directory object (FOO) has three versions. In the first version, the directory object only has the version 1 of a subdirectory object—DOO. The subdirectory object changed its name to WOO, thus a version 2 of the subdirectory object is created; as a result, a version 2 of FOO is created to link to the version 2 of the subdirectory. On version 3 of FOO, a new file under the directory FOO is created.
- the links, shown as dotted arrows, on the directory object FOO are stored as a “CHILDREN” property, and this property is of multi-value GUID type. These links allow the active object to build up object relationships or an object hierarchy; in this case, which is merely representative, it is parent-child relationship.
- This is a logical view of the directory data structure.
- the directory version pages may be combined into a table or a journal, and the table or journal may be stored in a special purpose file or a raw device block.
- the above diagram intentionally does not show the entire subdirectory and file objects (for example, the anchor pages are not shown).
- FIG. 7 is an example of a DMS file object, which is an active object that tracks history, as opposed to a file in a traditional file system.
- the DMS uses this object structure for storing the history of a file from an external host server.
- the DMS overlays the object structure of its object store over a special purpose file system for storage usage efficiency.
- the object store is a logical structure and the file system is the physical structure.
- the DMS file object preferably there is a property called “CONTENT,” and this property is of the type random access binary blob.
- CONTENT a property called “CONTENT”
- the binary value of this property type may be stored inside or outside of the metadata page.
- the binary data of version 1 is in a binary page 716 that has its own GUID.
- the changes (deltas) that are made to the file for version 2 may be stored as a sequence of forward deltas in a delta page 717 .
- the changes (deltas) of version 3 may also be appended to the same delta page or another new delta page.
- Both the binary and delta pages may be stored in one special purpose file, be broken up and stored in multiple special purpose files, be stored in a database, or be stored in raw storage devices.
- the purpose of storing a baseline and a set of deltas is for storage efficiency, and this binary data format can be used with other embodiments (such as where the logical representation is not in object-oriented form).
- Active object binary data management is designed for managing history of random access binary blob property type.
- the property type of random access binary blob may be stored inside a metadata page, or it may be stored outside a metadata page in both binary and delta pages. Regardless of how the random access binary data are stored, the DMS manages this data the same way, preferably through a sparse index.
- an initial full binary content is first captured into a binary page, and then the random changes to the binary contents are stored as a sequence of forward deltas (or delta strings) in delta pages.
- Delta strings preferably are of specific syntax.
- a delta string can represent an insertion, a deletion, or a replacement to an existing binary blob.
- a byte level index is maintained as part of the random access binary blob property.
- the sparse index for version 1 of a file may specify that the entire binary content of the file is in a specific binary page.
- the sparse index for version 2 of the same file may specify that certain byte ranges of the binary content of version 2 are in some specific locations of the binary page, while other byte ranges are in some specific locations of the delta pages.
- a binary page of sequentially appended records structure can be used in the DMS.
- Records management is designed for managing property type of sequential access binary blob.
- There are three different types of record management namely—formatted records, unformatted records, and file object associated records. Formatted records are a sequence of well defined records, each record is of specific structure of fields, and each field has well defined data type and length.
- a record schema (record structure definition) is defined for formatted record property type. This type of record can be used to track SQL requests of a database history, or email activities of an email server history.
- a formatted record can also be used to track real-time events associated with any data object.
- Unformatted records are a sequence of binary record chunks, in this case, the record chunks may be appended continuously to a binary data page with or without a header that specifies the length of the record. Alternatively, records can be appended to a binary data page without a header, in which case, the boundary of each record chunk is tracked separately. The boundary of unformatted records can be tracked using formatted record management structure.
- This type of record can be used to track sequential binary journal of a database or sequential journal file of any application. The characteristic of this type of binary journal is that records are always appended to the end and never override previous records.
- File object associated records are sequences of meta-information containing binary data updates to an associated file object. A file object associated record is used to track the location and length of each modification to a file object. Besides tracking the file modifications, a file object associated record can also be used to track checkpoints that occur with respect to the file.
- an active object instance can be created from the schema.
- the active object instance has the defined metadata and behavior.
- an object schema may be defined based on another object schema so that metadata and behaviors can be inherited, or so that coded functions can be reused.
- a generic object is clsObject, which defines basic metadata such as name, creation date and time, creator, modification data and time, and so on. It also defines the basic object behavior.
- other object schemas are defined based on clsObject (i.e., they inherit from clsObject).
- the object inheritance feature is an advantage of the object-oriented embodiment, however, it is not a limitation of the invention.
- DMS preferably defines a set of data management specific object schemas as shown in FIG. 5 . These object schemas are used to create the “active” objects that have specific metadata and behaviors as defined in the schema.
- the DMS object definition set forth below is a preferred (but non-limiting) way of organizing the control, data, and functional structure for the DMS to provide real-time data management services.
- the schema clsDMSSystem is a class for creating a DMS cloud active object 520 that represents the logical network of the entire DMS system (with multiple DMS clusters over multiple regions).
- a DMS cloud active object 520 that represents the logical network of the entire DMS system (with multiple DMS clusters over multiple regions).
- there is only one instance of clsDMSSystem in a DMS network as it is the root object instance of the entire DMS network.
- this object is used for tracking DMS regions 512 (each as an instance of a clsRegion schema as described below) and DMS functional groups that own data across regions 516 (each as an instance of a clsGroup schema as described below).
- the instance typically has a randomly assigned unique identifier.
- the instance preferably is created automatically by the DMS network when a first cluster is configured, i.e.
- This object instance is populated to all the storage clusters in the entire DMS network. Preferably, there is only one master copy of this object, which is the original copy, the one that was created first. When the properties of the instance change, the properties are populated to all replicas.
- the schema clsRegion is a class for creating DMS region active objects 512 that represents and tracks a DMS cluster network, data network, and server network. Preferably, there is one instance of clsRegion in each physical location.
- An active object instance of clsRegion is used for tracking all the DMS clusters 530 (each as an instance of a clsCluster schema as described below), repositories 514 (each as an instance of a clsRepository schema as described below), and host servers 528 (each as an instance of a clsHost schema as described below) in the region.
- each region may have multiple storage clusters
- the local instance of the clsRegion object is replicated to all the local storage clusters.
- the GUID of each instance of clsRegion are randomly assigned when created.
- policies are encoded as properties in clsDMSSystem, clsRegion, clsRepository, clsGroup, and clsXXDataSource.
- the schema clsRepository is a class for creating a DMS data container 514 for storing protected data sources.
- a repository instance may have sub-repository instances 514 and/or protected data sources 518 .
- a root repository object that is directly under a region represents a segment of a data network.
- a repository may be a child of a region or a child of another repository. The child of a region is the root of a DMS data object hierarchy.
- the repository object provides regional data grouping and policy enforcement. The policies in a repository are executed against all the data sources within the scope of the repository. Alternatively, a separate policy object may be defined and used for storing policies explicitly in the data hierarchy. If policy object instances are used, they can be attached to any one of the data container object instances.
- the schema clsXXDataSource is a class for creating data source instances 518 .
- An active object instance of a clsXXDataSource is a root container for a protected data source where a data source from a host is streamed.
- An instance of clsFSDataSource contains a file, a directory, or a volume of a file system and its history, while an instance of a clsDatabaseDataSource contains one or more databases and their history from a database server.
- An instance of a clsCompoundDataSource is a container for multiple data source instances. Unlike a repository that only provides logical containership, a compound data source instance preferably provides activity sequencing and indexing, as well as consistency marking to the real-time activities of its related group of data sources so that group consistency can be maintained.
- the class clsFile is a schema for creating object instances for the DMS to store the information of a file 520 from a host server and also to track the history of that file in the host.
- An instance of a clsFile is similar to a file in a file system, except that an instance captures, indexes and manages file history. In DMS, this object is used for data protection, with each instance of clsFile used to represent an external file in an external host.
- the class clsDirectory is a schema for creating object instances for the DMS to store the information of a directory 522 from a host server and also to track the history of that directory in the host.
- An instance of a directory simply represents a container of files and other sub-directories.
- the class clsDatabase is a schema for creating object instances for the DMS to store the information of a database 524 within a database server, and also for tracking and indexing the history and checkpoints of that database in the server. This object is used to provide database protection services.
- An instance of a clsDatabase represents a continuous consistent image of a database, across a range of time, from an external host server.
- the class clsJournalGroup is a schema for creating object instances 526 for the DMS to journal the redo and undo log journal) activities of a database.
- the database journal activities may be a sequence of updates to a group of related journal log files, or application level transaction records.
- the class clsRecordFile is a schema for creating object instances 527 for the DMS to track sequential journal entries within a journal group.
- An active object instance of the clsHost is created whenever a host driver from a new host server first connects to the DMS network. This object allows the DMS to track the data services provided to the information on the host 528 . This object also associates the protected data sources in the DMS to the data source on its host server.
- An instance of clsHost preferably contains information such as the platform of the host, the operating system, the host configuration, data sources that are protected from the host, DMS data sources that are replicated to the host, and the like.
- the protected or replicated data source properties preferably include the host path, the size of the sources in the host, the activities and statistical information about those data sources, and the GUID of the clsXXDataSource instance.
- An active object instance of the clsDMSCluster schema represents a DMS cluster 530 with one or more DMS nodes and the DMS storage. This instance provides statistics and status information of its specific cluster. Typically, there is only instance per storage cluster, thus the processes (e.g., the object runtime environment) of all the nodes use this instance as shared memory to keep information such as node availability, master election, and the like. Information about a DMS cluster (as instances of a clsDMSCluster), a DMS node (as instances of clsDMSNode), and DMS storage (as instances of clsDMSStorage) may be stored together with the other active objects or may be in a specific volume used exclusively by the cluster manager.
- An active object instance of the clsDMSNode schema represents a DMS node 532 within a DMS cluster. This instance provides statistics and status information about the DMS node it represents.
- the object runtime environment of a node is responsible for locating a cluster and joining that cluster. Once joined in a cluster, the runtime environment creates the clsDMSNode instance.
- An active object instance of the clsDMSStorage schema represents the storage volumes 534 of a DMS cluster. This instance allows the DMS storage to be configured, and it also provides statistics and status information of the storage volumes.
- An active object instance of the clsGroup schema is a data container that also represents a logical group 516 in an organization. This allows user to map data sources from one or multiple repositories in one or more regions to a functional group of an organization. Its purpose is to enable an administrator or other permitted entity to assign data management policy across multiple regions.
- policies are stored as properties in a given data container although, in an alternate embodiment, a separate policy object (e.g., clsPolicyProfile) may be used.
- An active instance of the clsPolicyProfile schema may contain a set of data management policies.
- a policy profile object can be assigned (as a default data management policy) to any data container, such as the universe (an instance of clsDMSSystem), regions, repositories, groups, or protected data sources, or to any data object, such as files, directories, and databases. When assigned to a container, all sub-containers or the data objects within that root container are governed by the set of policy rules.
- a region (or a repository) object allow an administrator to set policies for data in the same region, while a functional group object allows an administrator to set policies for data in multiple regions.
- a policy is a combination of a set of properties, e.g., a rule, an override rule, one or more qualifying events, one or more qualifying property values, and/or a schedule.
- a rule may be a Boolean expression with an action, and a rule may be nested.
- an active object instance of a clsPolicyOverride can be introduced that may also contain a subset of data management policies.
- the policies in the override object takes precedent over the default policy on an assigned policy profile objects.
- the DMS object definition discussed above is merely one way of organizing the control, data and functional structure for the DMS to provide real-time data management services.
- clsRegion may be broken down in to multiple hierarchies to represent local lines of business and departments
- clsDMSCluster may include and nodes and storage so as to eliminate clsDMSNode and clsDMSStorage definitions
- clsJournalGroup may be part of clsDatabase definition, and so on.
- the effect of this object-oriented hierarchy can be realized in different non object-oriented structures, such as a relational database. All of these variants are within the scope of the present invention.
- FIG. 5 illustrates a relationship among DMS active objects. This diagram does not show any object history (object versions). Policy profile and policy override objects are also not shown in this figure to avoid complexity.
- an active object instance is represented by I ⁇ object schema> (note that a schema is the same as a class; it is the definition of an object).
- the “I” stands for instance, and object schema is the definition of that object class.
- there is only one instance of the DMS system object 510 i.e. one DMS network.
- one or more regions 512 , and zero or more functional groups 516 can be created under the DMS network.
- the region and group active objects are used for storing configuration information about the region and the functional group.
- Functional groups may have sub-groups (i.e. group within group).
- Data repositories 514 can be created under a region 512 .
- repository may have sub-repositories 514 , as has been described.
- Protected data sources 518 reside within a repository 514 .
- Data may be streamed into a data source from a protected host server, or streamed into a data source from another DMS data source through remote distribution service provided by the DMS.
- a data source may be configured to replicate to a remote repository.
- the real-time history of data files 520 , directories 522 , databases 524 , database journals 526 , email databases, email messages, and the like are captured and indexed. The present invention focuses on file system data history, as will be seen.
- the groups 516 , repositories 514 , protected data sources 518 , and the data objects within the data sources are known as the data network 502 .
- policy can be assigned to all the objects in the data network and all the objects above the hierarchy of the data network.
- policies are enforced in hierarchical order and with specific override rules.
- a DMS host driver Whenever a DMS host driver is installed into a host server, the host driver reports to the DMS, and this operation results in an instance of host object 528 being created in the DMS.
- a host object 528 contains information such as the host OS and platform about the host server.
- IT administrators can identify host data to be protected, and then configure for the host data to be protected.
- An IT administrator can also configure for DMS protected data to be replicated to a host server.
- the host active object refers to the data source(s) that are protected from its host server or data sources that are replicating to its host (as illustrated by the link between 518 and 528 ).
- the host objects in the DMS form an external host server network 506 .
- a region may have one or more DMS clusters, with all DMS clusters preferably tracked by the DMS via DMS cluster active objects 530 .
- Each cluster has a representation active object that refers to the node active objects 532 and storage active objects 534 .
- the cluster object also contains cluster statistic and status information.
- a node object 532 contains configuration information, statistics and status about the node.
- the storage object contains storage volume information, and storage group information. Volume information includes all the raw storage volumes that are provisioned to the DMS. It also includes the DMS partitioning of the raw storage volumes, and the assignment of the partitions to storage groups.
- a protected data source has its own storage space that is called a storage group.
- a storage group is an aggregated DMS storage partitions carved out from the volume groups.
- the cluster, storage, and node objects form a DMS server network 504 .
- clsFSDataSource File System Data Source class
- clsDirectory Directory class
- clsFile File class
- the DMS active objects store metadata from the protected host server as well as metadata generated by the DMS itself.
- all the properties are metadata including the binary content from the external world.
- binary content is a “content” property with random access binary blob type.
- the properties of this object class typically include the configuration of the protected data source.
- the following table illustrates representative property examples of this object class: Properties of clsFSDataSource Descriptions ID GUID Name Name of the data source Parent GUID of its parent container (a repository object) DateTimeCreated Timestamp when this data source container is created Owner The user ID of the creator ACL Key or GUID to the access control list of this object DataSourceType File system RuntimeStates Protecting, replicating, disconnected from host, and the like Status Active, archived Master GUID of the original protected data source (if this is a replica) Replicas GUID of the replicas that need input from this object Host GUID of the associated host object where the data source resides HostPath The path name in the host that is protected by this object ProtectedDateTime Timestamp when protection begun ArchivedDateTime Timestamp when this data source became idle Children The root directories or files in this container EventTags List of entries with event and timestamp. The events are in data source level, may be set
- the above table is a subset of properties used in the DMS; one may add more or remove some of the above properties. For example, policy may be added, and one may not need RuntimeStates.
- the properties of this object are not versioned so that the history of the object is not tracked.
- one can version some of the properties such as HostPath, ProtectedDateTime, ArchivedDateTime, and Children, such that these configuration changes are recorded in time.
- properties are versioned, it is desirable to track the version begin and end timestamp.
- the ClsDirectory schema is defined for tracking the history of a directory (folder) in a file system. This schema is used for protecting a directory, and it is capable of recovering a directory to any point-in-time in the past.
- the properties of this object class preferably include the following: Properties of clsDirectory Descriptions Non-versioned Properties: ID GUID of this object instance, also GUID of this anchor page DataSourceParent GUID of its protection data source container DateTimeCreated Timestamp when this object is created (from the protected host) Creator The user ID of the creator DateTimeTerminated Timestamp when this object is deleted (from the protected host) EventTags List of entries with event and timestamp. The event tags may be set by users for tracking purposes.
- FirstVersionID GUID of the first version LatestVersionID GUID of the latest version VersionCount Total number of versions Versioned Properties ID
- the version GUID of this object, also GUID of this page AnchorID
- PreviousVersionID The version GUID of the previous version
- NextVersionID The version GUID of the next version Parent GUID of parent object which can either be the data source container or another directory Name Name of the directory DateTimeModified Timestamp when the version is created (or when the modification occurs)
- ModifiedBy ID of a user who modified the directory DateTimeEnded Timestamp when this version is ended i.e., a new modification results in another version being created and old version ended
- ACL Key or GUID to the access control list of this object ChildrenCount Number of children Children
- a list of its children which can be sub-directories or files. Each entry is a reference to the version ID of a child.
- properties are merely illustrative of what a directory active object contains.
- the above table shows the logical information of a directory object.
- a new child is added, an existing child is deleted, the directory is moved, the directory is renamed, or the name of its child has changed (if child name is also captured in this object), a new logical version of the directory is created.
- a new version is created, preferably a previous version is terminated.
- DateTimeModified of a new version must be after or same as the DateTimeEnd of the previous version.
- ModifiedBy indicates the user who made the modification to create the new version.
- an Event tag may be added; preferably, it is a sequence list of entries each having a timestamp.
- This logical layout may map directly into a physical store (e.g., overlaying a file system or a database), but this is not required.
- DMS stores multiple logical versions of a directory in one physical store unit.
- DMS may also combine multiple versions into one directory journal.
- one physical storage unit of a directory object may contain the initial directory baseline information and all the changes to a directory within a period of time.
- a directory journal entry may be “version ID, DateTimeModified, add new child, child GUID, . . . ” and so on.
- a logical version of a directory can be constructed on demand (i.e., upon request) by applying the necessary activities to a baseline directory image.
- the present invention is not limited to any physical layout of the object in the physical store.
- FIG. 6 shows a sample instance of a directory object.
- a representative directory object FOO
- the anchor 610 represents the entire directory object, and the anchor has a reference (FirstVersionID) to a first version page 612 , and a reference (LastVersionID) to a last version page 614 . All three versions ( 612 , 613 and 614 ) have reverse reference (Parent) to their object anchor. All three versions are linked together with their PreviousVersionID and NextVersionID. With these references, one can traverse a directory object and locate the directory information at any point-in-time in the past.
- all versions also reference to an ACL page ( 615 and 616 ) so that the access control at a point-in-time can also be located.
- each of the version pages ( 612 , 613 , and 614 ) there are DateTimeModified and DateTimeEnded properties.
- the DateTimeModified of version 2 should be before or equal to the DateTimeEnded of version 1 ; this property allows one to find out what version existed at what time frame.
- the version pages also preferably contain the ModifiedBy property, which allows one to find out who did what to the directory object when. User events and any system events that are meaningful to the directory can be tagged at the anchor page.
- the DateTimeTerminated property in the anchor page is set to the deletion time.
- the this data structure and the associated metadata allows one to track a directory history from what information has changed at what time, by whom, through what event, as well as what meaningful events to this object occurred during its lifecycle.
- the directory object only has the version 1 of a subdirectory object, namely, DOO 617 .
- the subdirectory object changed its name to WOO; thus, a version 2 of the subdirectory object was created and is represented by reference number 618 .
- the directory active object tracks its children's name; thus, version 2 of FOO 613 was created to link to the version 2 of the subdirectory WOO 618 .
- a new file of the name GOO under the directory FOO was created. This is illustrated by reference numeral 619 .
- the links shown as dotted arrows, are references of the CHILDREN property of the directory object.
- these links allow active objects to build up object relationships or object hierarchy (e.g., a parent-child relationship).
- object relationships or object hierarchy e.g., a parent-child relationship
- the result is a logical view of the directory data structure.
- the directory version pages may be combined into a table or a journal, and the table or journal may be stored in a physical storage unit.
- the above diagram does not show the complete subdirectory and file objects (for example, the anchor pages of the file and subdirectory objects are not shown).
- the ClsFile schema is defined for tracking the history of a file from a file system. This schema is used for protecting a file, and it allows for the recovery of the protected file to any point-in-time in the past.
- the properties of this object class preferably include the following: Properties of clsFile Descriptions Non-versioned Properties: ID GUID of this object instance, also the GUID of this anchor page DataSourceParent GUID of its protection data source container DateTimeCreated Timestamp when this object is created (from the protected host) Creator The user ID of the creator DateTimeTerminated Timestamp when this object is deleted (from the protected host) AccessLog List of entries with timestamp, user id, and access mode. EventTags List of entries with event and timestamp. The event tags may be set by users for tracking purposes.
- FirstVersionID GUID of the first version LatestVersionID GUID of the latest version VersionCount Total number of versions Versioned Properties ID
- the version GUID of this object also GUID of this page
- AnchorID The GUID of the anchor page (the ID of this object)
- PreviousVersionID The version GUID of the previous version
- NextVersionID The version GUID of the next version Parent GUID of parent object which can either be the data source container or a directory Name Name of this file at this version DateTimeModified Timestamp when the version is created (or when the modification occurs)
- ModifiedBy ID of a user who modified the file DateTimeEnded Timestamp when this version is ended i.e., a new modification results in another version being created and an old version ended
- Fingerprint A hash key of the entire content e.g.
- the non-versioned properties preferably include a timestamp when the object is created, creator information, identification of access journal for forensic purposes, and event tags for tracking user events across time line.
- the versioned properties preferably include name, modification information, status, ACL, and content.
- a new logical version is created when the name of the document changes, the content of the document changes, the ACL changes, document metadata or attributes change, or when the document is moved.
- FIG. 7 is an example of a DMS file object that stores data history of a file from an external host server according to the present invention.
- the file object has an anchor page 710 for its non-versioned metadata.
- This example shows a file object with three versions ( 711 , 712 , and 713 ).
- the FirstVersionID and LatestVersionID properties from the anchor refer to the first and third version of the file.
- the AnchorID property on each version contains the GUID of its anchor page.
- the versions are connected into a double link list with the PreviousVersionID and NextVersionID properties on each version property set.
- each version has an ACL property that refers to the access control list.
- Each version page also has a pair of timestamps, DateTimeModified and DateTimeEnded, to indicate when the version becomes existent and when the version is ended and a new version born.
- the DateTimeEnded property on the last version page and the DateTimeTerminate property in the anchor page are set to the deletion date.
- the File version is created when a file is modified and ended when the file is closed.
- each version has an associated property called “CONTENT,” and this property is of the type random access binary blob.
- CONTENT the binary value of this property type may be stored inside or outside of the metadata page.
- the binary data of version 1 is in the binary page 716 , which has its own GUID.
- the changes (deltas) that are made to the file for version 2 are stored as a sequence of forward deltas in the delta page 717 .
- the changes (deltas) of version 3 are appended to the same delta page 717 or another new delta page.
- a file object may have one or multiple binary pages.
- the binary pages contain the baseline data.
- a file object also may have one or multiple delta pages for all its changes.
- the sparse index refers to the data in both the baseline and the deltas to make up the content for the version.
- the binary and delta pages may be stored in one physical storage unit; alternatively, the pages may be broken up and stored in multiple physical storage units.
- the above-described example is simply one way in which DMS structures the binary data.
- each version may have its own binary pages so that no delta has to be kept.
- Yet another alternative is to store reverse deltas or multiple baselines at different versions with a combination of reverse and forward deltas.
- This file object structure and the associated metadata allows DMS to track a file history, e.g., what information has changed at what time, by whom, through what event, and what meaningful events to this object occurred during the object's lifecycle.
- a file history e.g., what information has changed at what time, by whom, through what event, and what meaningful events to this object occurred during the object's lifecycle.
- the metadata of the version pages may be combined into a table or a journal, and preferably the table or journal may be stored in a physical storage unit.
- this structure can be stored over a raw storage device, or by overlaying a file system or a database.
- the file object may also optimize storage usage through a sparse index, as more particularly described in Ser. No. 10/943,541, filed Sep. 17, 2004, which application is incorporated herein by reference.
- FIG. 8 shows a sample file system history captured by the DMS according to the present invention. For simplicity, only the version metadata pages are shown; the anchor pages and the ACL pages are omitted.
- each version preferably has a DateTimeModified and DateTimeEnded. The DateTimeEnded of the latest version is NULL (i.e., not ended yet).
- T 1 it is assumed that the entire file system is uploaded to the DMS for protection from a host server at T 1 .
- This is represented by FSDS 801 (DataSource 1 ).
- T 1 there is a version 1 of the directories 811 and 821 , and of the files 841 and 851 . While this representation refers to a time T 1 , this time may be a time range or period, as upload of the entire file system typically takes a given amount of time.
- the directory by the name “do2” changed its name to “dox” (as now indicated by object 822 ). Because in this example a directory also tracks the name of its children, this change causes parent “do1” (which has reference to this object) to also generate a new version 812 .
- this structure forms a three dimensional (3-D) object store. Navigating this object store enables DMS to identify the history and state of the DataSource 1 at any point-in-time, as will be described in more detail below.
- physical structure of the object versions can be organized in any fashion to optimize for the storage usage at the DMS.
- an alternate non object-oriented embodiment may be implemented with techniques that link and index the object versions, object relationships and data changes by applying a schema over a relational database, together with a set of processes (described below) that update the database according to the invention.
- the present invention is directed to the end-to-end process (e.g., from host driver to active objects in one cluster, or from active objects in one cluster to active objects in another cluster) that changes the DMS logical object store structure when a file system history is captured.
- the present invention describes the processes involved in the storing of real-time history of a file system, and the use of the real-time history for any point-in-time recovery for guaranteed consistency.
- the DMS file system history structure changes are triggered by one or more events from file system, users, or applications.
- DMS file system data source object ( 801 ) in a DMS cluster receives file system activities and other events, typically from a host driver that resides in a server or from another file system data source object that resides in another DMS cluster. If a data source receives a data stream directly from a host driver, it is providing a data protection service, and the data source/storage group in the DMS storage is a master data source. If a data source object receives a data stream from another data source object, the service is called data distribution, and the data source/storage group in the DMS storage is a replica. As described in Ser. No.
- a file system data protection or data distribution stream contains real-time event journal of a file system.
- the file system event journal is a stream of file system events, metadata, and associated data. Metadata may include, for example, information such as who did what when.
- the events include OPEN, CLOSE, CREATE, DELETE, MOVE, RENAME, MODIFY (data, attributes or metadata such as ACL), DELTA APPLY, FLUSH, and CHECKPOINT.
- CREATE event results in new file system active object (version 1) being created.
- Host drivers for data protection or active objects in a source cluster (for data distribution) may accumulate changed data depending on the data type; host drivers send (either instantaneously or periodically) MODIFY and DELTA APPLY along with the data and metadata to the target DMS active objects.
- DELTA APPLY is used to send delta changes after delta reduction. For some data types, such as database log activities, the host driver does not perform delta reduction and does not accumulate changes; rather, the host driver instead forwards changes with MODIFY events as soon as the events are received.
- FLUSH, CLOSE, and CHECKPOINT each trigger all accumulated changes to be sent to the target DMS active objects through MODIFY and DELTA APPLY events.
- CLOSE and CHECKPOINT events result in an old version being terminated, and a new object version created.
- MOVE and RENAME re-locate or modify the name property of an active object version, and DELETE ends the life of an active object by setting a timestamp on DateTimeTerminated and ends the last version.
- FIG. 9 is the historical starting point of the sample file system.
- the history comprises first and second versions 911 and 912 of the directory Dir- 1 , first and second versions 921 and 922 of the directory Dir- 2 , first and second versions 941 and 942 of File- 1 , and a first version 951 of File- 2 .
- Binary and delta pages 952 , 943 and 944 ) are also referenced.
- the creation of a file or a directory in the DMS file system history structure is initiated by a CREATE event captured by a DMS host driver operating to provide data protection, or by a similar event distributed from one data source to another data source.
- This function is illustrated in the process flow of FIG. 10 .
- This method is implemented in software (a set of one or more program instructions) executable in one or more processors.
- the same event would be forwarded from the master DMS data source to another replicated DMS data source, which would cause an equivalent data structure change in the replica.
- the following paragraph describes the data protection scenario.
- This process begins with the DMS host driver capturing a file or directory CREATE event at step 1071 .
- the host driver then issues an Object Create command to the associated DMS file system data source to create an active object with the following parameters—object class, parent path, object name, creation timestamp, owner, ACL, and other attributes.
- An object manager at the DMS handles the request for the DMS file system data source object by opening the parent active object and creating a new version thereof. This is step 1075 , and this operation has been described and illustrated above.
- the DateTimeEnded of the parent's previous version is set to T
- the DateTimeModified of its new version is set to T as well.
- the object manager also creates a new file or directory object with a first version and sets all the properties as necessary.
- the DateTimeCreated property in the anchor of the new object is set to T, as is the DateTimeModified property in the first version.
- the state of the first version of this new object is temporarily set to SUSPECT, as it has not closed yet.
- the object is created, it is linked to its parent, preferably by adding its GUID to the CHILDREN property of its parent's latest version. This also occurs in step 1077 . Thereafter, the parent object is closed and the new child handle remain open; this handle is passed over to the host driver, which can issue more updates to the new child. This is step 1079 .
- the transaction is rolled back at step 1081 and the host driver is notified; the host driver then performs a resynchronization on that object at step 1084 .
- a master DMS data source object is forwarding events and a data stream to a target DMS replicated data source object.
- the process described in the flowchart of FIG. 10 applies in this data distribution scenario as well; in that scenario, the host driver is replaced by a master DMS data source object in a first cluster, and the file system data source (FSDS) object is replaced by a target DMS replicated data source object in a second cluster. Otherwise, the operations are similar.
- FSDS file system data source
- FIG. 11 illustrates how a new file by the name “fo3” is created and added to the DMS file system data source shown in FIG. 9 .
- the anchor page of the objects are not shown.
- An anchor page stores the permanent properties of an object, which properties do not changed over time.
- the creation of “fo3” results in new version of “do1” 1150 being created.
- the DateTimeEnded is set to T, and the DateTimeModified of object 1150 is also set to T.
- the anchor page (not shown in the diagram), version page 1151 (version 1), as well as binary page 1152 for the new file object, are also created.
- the DateTimeCreated property in the anchor page (not shown) is set to T, as is the DateTimeModified property for the version page 1151 .
- the State property of page 1151 is set to SUSPECT temporarily (see the discussion below concerning closing a file for additional details).
- the GUID of page 1151 is added to the Children property in object 1150 , which links the parent-child relationship.
- the sparse index of the Content property refers to the content in binary page 1152 . If the new object added is a directory object, there is no binary page.
- Event CREATE Create (object A, in directory B, with metadata X, at time T)
- object A may be a file or a directory.
- Metadata includes creator, ACL, and so on.
- Open parent directory object B which has n version. Create new version (n + 1) for object B, copy all the properties from version n.
- Set DateTimeModified (object B, version n + 1) T
- the above algorithm is merely representative of the steps that may be used to transform the logical representation of FIG. 9 to that shown in FIG. 11 in response to CREATE events.
- the algorithm for maintaining such different structures may vary accordingly.
- the logical representation can overlay a relational database, or the logical representation may overlay a file system or even raw storage blocks (in effect such that there are only virtual version pages).
- the version pages are, in effect, virtual
- the version pages may be constructed as needed, and information necessary for constructing the version pages may be stored as a journal or in any other form, such as in a file or raw storage blocks.
- a file or a directory modification in the DMS object store preferably is represented by the creation of a new object version.
- the modification of a file system object preferably is broken into three phases, and each phase involves a set of events.
- the three phases of active object modification cycle are (1) instantiating an active object, (2) modifying the object properties, and (3) freezing the version.
- FIG. 12 illustrates a process flow that is implemented (e.g., in software) to modify a file or a directory in a master data source operating in data protection scenario. Similar object store changes occur when the same events are forwarded from a master data source to a replicated data source in the data distribution scenario.
- phase 1 is instantiation of the target active object, which can either be a CREATE (as in FIG. 11 ) or an OPEN process, as represented by block 1201 .
- instantiating an active object can be initiated by a CREATE event or an OPEN (write mode) event.
- a CREATE event is received, a new object with the first version is created in the object store.
- the object handle remains open for further update until the target DMS active object is explicitly closed, e.g., in response to events to freeze the object version.
- FIG. 11 described the process for creating a file or directory.
- a DMS host driver When a DMS host driver captures a file system OPEN event to update a file or a directory at step 1202 , it issues an Object Open request to the associated file system data source active object. This is step 1203 .
- the DMS active object When the DMS active object is opened, its handle is returned to the host driver at step 1205 .
- the flow sub-diagram (in block 1201 ) describes the object open process in response to OPEN event.
- the host driver sends to DMS the timestamp when a file system object is created or opened; the timestamp is used for stamping on the DateTimeEnded property of the previous version of the target DMS object, and on the DateTimeModified property of the new version created.
- Phase 2 is the actual modification of the target object, which occurs either in block 1225 or in block 1209 .
- the events that modify object properties preferably include MODIFY (metadata) and WRITE (binary data). There may be many more modification events depending on the application and system to which the DMS is applied.
- the test at step 1208 determines which event has occurred.
- a MODIFY event changes file system object metadata (such as access control list (ACL), object title, company name, document statistics and other user defined properties) that is associated with a file system object.
- ACL access control list
- the flow sub-diagram at block 1225 describes the process to modify object metadata.
- step 1226 the host driver issues an object MODIFY event to the target active object (via the opened object handle) at the DMS, which target object then changes the object property in the latest object version at step 1227 .
- the WRITE event is for file object only; it represents binary content updates.
- host driver captures the WRITE event (steps 1207 1208 )
- it enters the processing block 1209 in the file modification process.
- Host driver first decides if it should buffer the changes. This is step 1210 .
- the host driver would not buffer the log entries; however, when dealing with a regular document changes are buffered. If changes are buffered, then the host driver decides if it is time to forward the changes to the DMS target active file object. This is step 1211 . If no data should be forwarded at the meantime, the host driver continues to watch for events at step 1207 .
- the host driver decides if delta reduction should be applied on the changes to extract the actual changed byte range. This is step 1212 . Again, for database log entries, delta reduction is not necessary because log entries are appended onto the file. If no delta reduction is necessary, the changed data is packaged with a WRITE event and forwarded to the DMS target active object. This is step 1213 . Otherwise, the host driver retrieves the last binary content signatures and, for one or more byte ranges that actually changed (deltas), the host driver calculates and forwards those deltas to the DMS target object. This is done using a host driver-generated (namely, APPLYDELTA) event and occurs at step 1214 .
- a host driver-generated namely, APPLYDELTA
- the target DMS file object receives both WRITE and APPLYDELTA events, applies second stage delta reduction as necessary to extract the exact bytes changed, saves the deltas or binary data in the binary or delta pages, and then creates or updates the sparse index in the working (last) object version. This is step 1215 . If the file has not been closed, the host driver continues to capture more modification events for the file at step 1207 ; otherwise, the closing process continues, which is step 1222 . If any failure occurs, the host driver abandons all the events associated with the target file and performs resynchronization of the entire object at step 1230 . In the preferred embodiment, the host driver uses a FLUSH event as one of the events to decide if buffered data should be forwarded to the DMS without causing the DMS target object to generate new version.
- the possible events that cause a DMS target file or directory active object to freeze the latest object version (and thus to prevent any more changes into that version) are CLOSE, CHECKPOINT, and FORCE-CLOSE.
- the flow diagram in block 1221 illustrates the processing of handling of these events to freeze a DMS active file or directory object version.
- a CLOSE is a file system event. When this event is detected by the host driver, the associated file is consistent.
- a CHECKPOINT may be generated by an application with or without user initiative, or it may be generated by the host driver.
- a CHECKPOINT event is generated when the associated application or the host driver have taken some appropriate action to ensure that the version to be frozen is consistent in its application point of view.
- a database manager periodically flushes its memory and generates an internal CHECKPOINT, during which a set of database files are consistent.
- the CHECKPOINT event from a database manager can be detected by the host driver, which indicates that the group of files belonging to the particular database is consistent and a DMS version of each of the files should be frozen.
- an application or the host driver may generate a CHECKPOINT to all the system state files (or even the entire file system) to create a snapshot of all the files all at once (an exact time). This CHECKPOINT forces all the related files to freeze their latest version all at once.
- the host driver checks if there is any buffered data for that object. This is step 1220 . If so, the host driver first forces the data to be forwarded to the target DMS object. After that, the host driver forwards the event to the DMS target object. This is step 1222 . Both CLOSE and CHECKPOINT events generate a consistent DMS object version with the State property of the frozen version set to “Consistent.” This is step 1223 .
- FORCE-CLOSE another event that freezes a file or a directory object.
- This event may be generated by an application or the host driver itself (step 1207 ), or it can be generated by the DMS (step 1225 ) when an error is encountered. The error could be that the host driver connection to the DMS has failed.
- the FORCE-CLOSE event generated by an application or host driver goes through the same process as the CLOSE and CHECKPOINT events (steps 1220 , 1209 , 1222 , and 1223 ).
- FORCE-CLOSE freeze the latest version, as it is in Suspect state (i.e., the consistency is unknown). This is step 1223 . Any DMS object that ends with Suspect state is eventually resynchronized with its corresponding file system object in the host, which is step 1230 .
- the DMS data source object automatically creates a new object version when it handles a CREATE or OPEN event.
- step 1223 involves freeing an unmodified object version.
- An alternate embodiment forces the DMS data source object to create a new object version when it receives the first modification event.
- an alternative embodiment may choose to freeze file system objects more frequently (by using events such as FLUSH or possibly the WRITE events with TIMEOUT in step 1221 ).
- Another embodiment includes other application and host driver generated events, such as AUTO-SAVE.
- the process may be somewhat different than as illustrated in FIG. 12 . For example, if a relational database is used to store the logical representation, the object-oriented behavior (with object methods/functions) would not be required.
- a master DMS data source object is forwarding events and a data stream to a target DMS replicated data source object.
- the process described in FIG. 12 applies in this data distribution scenario as well.
- the host driver is replaced by a master DMS data source object in a first cluster
- the DMS file system data source object (FSDS) and DMS objects are replaced by a target DMS replicated objects in a second cluster.
- FSDS DMS file system data source object
- FIG. 13 illustrates how modifying a directory object alters the DMS object store of FIG. 11 .
- FIG. 14 illustrates how modifying a file object alters the DMS object store of FIG. 13 .
- FIG. 13 illustrates the modification of an ACL on version 3 of the Dir- 1 directory object, which was object 1150 in FIG. 11 .
- object 1350 the anchor page of all objects is not shown.
- a new version (object 1350 ) of “do1” is created with its ACL property changed; other properties, such as the children links, remain unchanged.
- version 4 (object 1350 ) and version 3 (object 1150 ) refer to the same version of their children.
- T 2 would be stamped on the DateTimeEnded property of version 3 (object 1150 ), and on the DateTimeModified property of version 4 (object 1350 ) of the directory “do1.”
- object 901 the parent of “do1, in this case object 901 , is modified to refer to the new version.
- FIG. 14 illustrates the modification of a file object (labeled 1151 in FIG. 11 ), on FIG. 13 whose content is modified. Note that FIG. 13 is derived from FIG. 11 as a result of a change to “do1.”
- This file object modification generates a new version of File- 3 , which is represented as object 1460 .
- the deltas of the modification are saved in a delta page (object 1461 ) or in the binary page (object 1152 ) associated with the prior version.
- the sparse index in version 2 object 1460 refers to the byte ranges in both the binary and delta pages for the version 2 content.
- T 3 is stamped on the DateTimeEnded property of version 1 (object 1151 ) and on the DateTimeModified property of version 2 (object 1460 ). Because the content change to “fo3” does not affect directory “do1,” no new version is created. Version 4 of “do1” continues after T 3 , however, thus note that the child link to “fo3” (object 1150 ) is changed to refer to version 2 (object 1460 ) of “fo3” instead of version 1 (object 1151 ). This reflects the fact that, at the current point-in-time, the information of “do1” is in its V4 and that from there, the current point-in-time “fo3” can be located.
- Set property (object A, version m + 1) value
- Write (object A, content (offset, length, data)) (step 1215)
- FIG. 15 illustrates a process for deleting a file or a directory in the DMS file system history structure. This process is initiated by a DELETE event captured by a DMS host driver operating in the data protection scenario. In the data distribution scenario, the same event is forwarded from the master DMS data source to another replicated DMS data source, which causes equivalent data structure changes in the replica.
- the following section describes the data protection scenario.
- FIG. 15 begins with the DMS host driver capturing a DELETE event for a file or a directory. This is step 1501 .
- the event is forwarded to the file system data source active object, together with the target object name and timestamp T.
- step 1503 The file system data source object then begins a transaction for the modification of properties in both the target object and its parent.
- the object manager opens the parent of the target DMS object and creates a new object version for the parent.
- the DateTimeEnded property of the previous version of the parent object is set to T, while the DateTimeModified property of the new version is also set to T. This is step 1505 .
- step 1507 the target object is instantiated, and both the DateTimeTerminated anchor property and DateTimeEnded property at the latest version page are set to T.
- step 1507 The next step is to remove from the latest parent version page the child reference to the target object. This also occurs in step 1507 .
- step 1509 the transaction is committed at step 1509 . Any failure results in rolling back the transaction (step 1511 ) and complete resynchronization of the target object between the host and the DMS (step 1515 ). Step 1513 illustrates that the process has succeeded.
- a master DMS data source object forwards events and the data stream to a target DMS replicated data source object.
- the process described FIG. 15 applies in this scenario as well.
- the host driver is replaced by a master DMS data source object in a first cluster
- the file system data source (FSDS) object is replaced by a target DMS replicated data source object in a second cluster.
- FSDS file system data source
- FIG. 16 illustrates the deletion of a file object “fo1” 942 from the file system data source in FIG. 14 .
- “do1” object 1350
- DELETE event to remove “fo1”
- This new version has its reference to “fo1” removed so that it is no longer linked to the deleted child.
- the DateTimeEnded property of object 1350 is set to time T 4 and the DateTimeModified property of object 1650 is also set to T 4 .
- the DateTimeTerminated property in the anchor page (not shown) is set to T 4 to indicate that the object does not exist beyond T 4 .
- the latest version of “fo1,” which is version 2 (object 942 ) is ended by its DateTimeEnded property set to T 4 .
- the object “fo1” does not get removed physically from the DMS object store when it is deleted. Instead, its history terminates at T 4 .
- the DMS object store keeps growing its history until a user explicitly prunes the history, either manually or via retention policy, during which older versions of the active objects get dropped off at the tail end.
- FIG. 16 shows the deletion of a file
- the DMS file system history changes are similar when a directory object is deleted.
- a version is added to the parent directory of the target directory with the link between the parent and the target removed, and the target directory is terminated (in the same manner as if a target file object is terminated as illustrated).
- all the directory children should be terminated at once.
- the process traverses down the children of the directory object, sets the DateTimeTerminated property (at each anchor page of each child) to the time when the target directory is deleted, and sets the DateTimeEnded property at the latest version page (of all the children) to the same termination timestamp.
- Event DELETE Delete (object A, at time T) (steps 1505, 1507)
- object A may be a file or a directory.
- Open parent directory object B which has n version. Create new version (n + 1) for object B, copy all the properties from version n.
- Set DateTimeModified (object B, version n + 1) T
- DateTimeEnded (object B, version n + 1) NULL
- Set DateTimeEnded (object B, version n) T.
- Open parent of object B change the child reference of the latest version to refer to version n + 1 of B.
- Set DateTimeEnded (object A, m) T
- renaming a file system object refers to changing the name of the object without moving it away from its directory. While relocating a file system object refers to moving an object from one directory to another different directory, the name of the object may also change during relocation. Relocation is a superset of renaming; one can relocate from within the same directory for changing an object's name path. In either case, the destination name either of the rename or relocate operation may already exist and be used by another object, in which case the original destination object is deleted and the target object to be renamed or relocated takes over the destination name.
- a MOVE event is used for both renaming a file system object (file or directory) as well as relocating (moving) a file system object from one directory to another.
- a RENAME event may be used for both renaming and relocating of a file system object.
- MOVE event is used for relocating file system objects while a RENAME event is used for re-labeling (renaming) file system objects.
- both MOVE and RENAME events are treated the same, in other words, both events initiate renaming and relocating of file system objects.
- FIG. 17 is a flow diagram illustrating a process of moving a file or a directory according to the invention.
- the process involves a host driver capturing a MOVE or a RENAME event (at step 1701 ), and passing the event to the DMS file system data source object (at step 1703 ).
- the DMS file system data source object then opens the target object (and its parent object(s)) to handle the event. This is step 1705 .
- DMS handling of a MOVE or RENAME event occurs at steps 1705 and 1707 ; the particular functionality for object relocation varies depending on which object history model is adopted, and the details are discussed in following sections.
- step 1707 does not fail, the transaction is committed at step 1709 .
- Step 1713 indicates a success. If, however, a failure occurs during the renaming or relocation process, object resynchronization is performed at step 1711 .
- the host driver in the process flow is replaced by a master DMS file system data source, and the DMS file system data source is a replication data source. Otherwise, the process flow in FIG. 17 is identical.
- FIG. 18 shows DMS data structure changes when a file is renamed and a parent object does not track a child object name
- FIG. 19 shows DMS data structure changes when the file is renamed and parent object does track child object name.
- the resulting data structures illustrated are built from the data structure in FIG. 16 .
- no anchor pages are shown in the diagrams to simplify the representation.
- the target file system object does not move from one parent to another; thus, the process (corresponding to steps 1705 and 1707 in FIG. 17 ) is relatively straightforward.
- the target object is opened, a new version is created with the given timestamp T (i.e., the old version DateTimeEnded property as well as the new version DateTimeModified property are set to T), and the NAME property in the new version is changed to the new name.
- the new version is object 1850 , which is seen in FIG. 18 . If object name is not tracked (in the CHILDREN property of the parent directory), the CHILDREN property link (of the last version of the new object's parent) is changed to refer to the new object version (see, objects 1650 and 1850 ). If, however, object name is tracked in the parent's CHILDREN property, the parent object is opened, and once again a new version of the parent is created.
- the new version is seen as object 1951 in FIG. 19 .
- the new object name is changed on the CHILDREN property of the new parent version. This process is the same regardless of the whether the target object is a file or a directory.
- the destination name “foz” does not exist before the rename.
- a relocate process is used instead of the rename operation.
- the file system may use a MOVE or RENAME event to rename a file or a directory object.
- Event MOVE or RENAME Rename (object A, old name, new name, at time T) (Step 1705, 1707)
- object A may be a file or a directory.
- Open object A which has m version. Create a new version (m + 1). Copy all properties of m to m + 1.
- Set DateTimeEnded (object A, version m) T.
- FIGS. 20 and 21 show DMS object structure changes associated with relocating a file object.
- FIGS. 20 and 21 are built upon the data structure that remains in FIG. 19 .
- No anchor pages are shown in these diagrams to simplify the representation.
- there are two (2) different models for tracking history of file system object relocation one ( FIG. 20 ) is versioned by object instant while the other ( FIG. 21 ) is versioned by path.
- FIG. 20 the versioned by object instant model
- object versions are connected across the lifetime of the object regardless of where the object is relocated.
- new versions of the affected objects are created. This results in the following new versions: ( 2055 “fo2” v2), ( 2054 “dox” v3) and ( 2053 “do1” v7).
- the DateTimeModified property of these new versions is set to the time when “fo2” is relocated, and the DateTimeEnded property of the new versions is set to NULL.
- the DateTimeEnded property of the previous versions is set to the relocation time of “fo2.”
- the most current version of the parent-child link (CHILDREN property) for both “dox” and “do1” are fixed (with FSDS referring to object 2053 , and object 2053 referring to object 2054 ).
- the parent-child link (object 2054 to object 2055 ) from “dox” to “fo2” is removed, and parent-child link (object 2053 to object 2055 ) from “do1” to “fo2” is connected via CHILDREN property in object 2053 .
- object versions are only connected when the object is in the same directory container (i.e., the same parent pathname).
- the same object is moved out of the container, a new one is born on the new container, and the old one from the old container is terminated.
- FIG. 21 for example, when “fo2” is relocated from “dox” to “do1,” a new version of “dox” (object 2157 ) and a new version of “do1” (object 2156 ) are created.
- object 951 is “deleted” or “terminated” by having its DateTimeTerminated anchor property set to the object relocation time, and its DateTimeEnded property in the latest version also set to object relocation time. Because objects 951 and 2158 have the same content, they both share the same binary page 952 .
- variant 980 the newly arriving has a new anchor page and a first version page 996 that has nothing to do with object 995 .
- “f1” would be seen to have only one version.
- objects of the same name in the same path are always connected in versions and share the same anchor page as if they are the same object. For example, in this variant 981 , “f1” (object 999 ) is moved into “dir1” at T 4 ; back before T 3 , an object of the same name existed but was terminated.
- the old object is re-born; its DateTimeTerminated at object 992 is reset from T 3 to NULL. No new object is created; instead, a new version page (object 999 ) is created for the old object to fit in the new file.
- the DateTimeEnded of object 998 is set to T 3 and the DateTimeModified of object 999 is set to T 4 , so there is a version time gap during which the file never existed.
- T 4 in this case, there are three versions of “f1” in the entire history.
- Event MOVE or RENAME RelocateFile (File A, old path, new path, at time T) (Step 1705, 1707) Open current parent of A, P1, using the old path.
- P1 has k versions. Create a new version (k + 1) and copy all the properties of k to (k + 1).
- Set DateTimeEnded (P1, version k) T.
- P2 Open new parent of A, P2, using the new path.
- P2 has i versions. Create a new version (i + 1) and copy all the properties of i to (i + 1).
- Set DateTimeEnded (P2, version i) T.
- Copy properties (object A, version m) to properties (object C, version 1) this copies over the sparse index so that the binary and delta pages can be shared.
- the algorithm set forth above shows relocation of an object within a protected file system or folder (i.e., moving from a sub-folder to another sub-folder within a protected file system tree).
- a protected area to an unprotected are (e.g., outside of the protected file system)
- the handling process is similar to DELETE. This is because the object disappears from the protected area after the event.
- an unprotected area to a protected area it is treated as a creation of a new object.
- the DMS may also include a temporary file handling process to minimize storage and bandwidth usage, e.g., by not transferring and storing potentially useless temporary files in the file system history.
- Microsoft Word creates a temporary file when a Word document is modified. The updates are entered into a temporary file; upon a save event, the temporary file is renamed to the original file name.
- creation and/or modification of the temporary file may be avoided; thus, preferably, only when the RENAME occurs is the above relocation process applied and object history linked together by pathname.
- the above algorithm implements relocation of a file object; relocation of a directory object is more complex, as a directory may have children. Similar to relocating a file, the history management of relocation of a directory can also be based on model 1 (versioned by object instance) or model 2 (versioned by path). Also, one may connect the relocated object with a dead historical object while versioned by path or without connecting the relocated object with the historical object.
- FIGS. 23-26 illustrate the DMS data structure changes during relocation of a directory object. As in the previous examples, these figures do not show the object anchor pages.
- FIG. 23 illustrates a sample baseline structure.
- FIG. 24 illustrates a directory relocation based on versioned by object instance model using FIG. 23 as the initial baseline.
- FIG. 25 illustrates a directory relocation based on versioned by object path model using FIG. 23 as the initial baseline.
- FIG. 26 illustrates a directory relocation based on a combination of versioned by object path and versioned by object instance, again using FIG. 23 as the initial baseline.
- “dir4” is relocated from “dir2” to “dir3” using versioned by object instance model and figure FIG. 23 as the baseline.
- a new version of “dir2” is created (object 1031 ) and its CHILDREN property is modified such that it no-longer links to “dir4.”
- the DateTimeEnded of object 1005 and the DateTimeModified property of object 1031 are set to the time when “dir4” is relocated.
- the CHILDREN property of parent of “dir2,” which is version 2 of “dir1” (object 1002 ) is adjusted to refer to object 1031 instead of object 1005 . Note that because there is no addition or deletion to “dir1,” there is no need to create a new version.
- a new version of “dir3” 1030 is created, its CHILDREN reference is added “dir4” version 3 (object 1032 ), and its DateTimeModified property is set to the time when “dir4” is relocated.
- the parent reference of “dir3” (which is version 2 of “dir1” 1002 ) is also adjusted to refer to object 1030 .
- New version of “dir4” 1032 is created with the same CHILDREN reference as its previous version 1009 ; the NAME property and PARENT property of object 1032 is changed accordingly. Versioned by object instance for directory relocation is straightforward as the version of the children does not have to be adjusted (because the instance has not changed).
- FIG. 25 shows relocating of “dir4” from “dir2” to “dir3” using the versioned by object path model.
- new versions of “dir2” and “dir3” are created with their CHILDREN link, DateTimeModified property, and parent property adjusted accordingly.
- the object “dir4” 1009 is moved, the last version (object) 1009 ended, and the object is terminated; a new object for “di43” is created that has its own anchor page and a first version page 1042 . All the descendents of “dir4”, namely objects 1010 , 1013 , and 1014 , are also terminated and new corresponding objects (objects 1043 , 1044 , and 1045 ) created.
- the file object “f2” (version 1, 1043 ) and “f3” (version 1, 1045 ) refer to the same binary and delta pages for shared content storage usage reduction.
- the versioned by object path model has relatively high processing and storage cost when relocating a directory, although it is much simpler to traverse.
- the alternative is to have a versioned by object path and versioned by object instance hybrid as shown in FIG. 26 .
- “dir4” version 2 object 1009
- a new object “dir4” 1052 with a new anchor page and first version page is created.
- a new version is created for both “dir2” 1051 and “dir3” 1050 , and their parent link is fixed.
- the new version of “dir3” ( 1050 ) refers to version 1 of the new object 1052 , while version 3 of “dir2” ( 1051 ) no longer refers to “dir4.”
- New NAME property may be entered into object 1052 as relocation may also change the name of the directory. The descendents of “dir4” do not change in this case.
- Event MOVE or RENAME RelocateDirectory (directory A, old path, new path, at time T) (Steps 1705, 1707) Open current parent of A, P1, using the old path.
- P1 has k versions. Create a new version (k + 1) and copy all the properties of k to (k + 1).
- Set DateTimeEnded (P1, version k) T.
- P2 P1, otherwise, do the following: Open new parent of A, P2, using the new path.
- P2 has i versions. Create a new version (i + 1) and copy all the properties of i to (i + 1).
- Set DateTimeEnded (P2, version i) T.
- an object already owns the new path name open that object to terminate it. Remove the object version page from P2. If versioned by object instant ( FIG. 24 ) Open directory object A which has m version.
- Set PARENT property of C to refer to (P2, version i + 1). If versioned by object path without connecting to dead object ( FIG.
- the above algorithm only illustrates the process to relocate a directory object from a sub-folder to another sub-folder, all within a protected file system.
- the process is the same as that for deleting the direct object (i.e., the same process for a DELETE event).
- the process is similar triggered by a CREATE event as has been described above.
- the present invention has been described by a set of example data structures, but this is not a limitation of the present invention.
- these algorithms may be used with any object store as the starting or baseline data structure.
- the present invention addresses enterprise data protection and data management problems by continuously protecting all data changes and transactions in real time across local and wide area networks.
- the method and system of the invention take advantage of inexpensive, commodity processors to efficiently parallel process and route application-aware data changes between applications and low cost near storage.
- the present invention also relates to apparatus for performing the operations herein.
- this apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer.
- a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
- a given DMS appliance can provide one or more such services. It is a particular advantage that a given appliance can provide a consolidated set of data services on behalf of a particular data source. As has been described, this operation is facilitated through the provision of the host driver, which captures, as a data history, an application-aware data stream.
- the application-aware data stream typically comprises data change(s), events associated with the data change(s), and metadata associated with the data change(s). As has been described, this information is streamed continuously to the appliance (or to a set of cooperating appliances) to facilitate provision by the appliance of the desired service(s).
- an “object” is not limited to a construct that is used solely in an “object-oriented” implementation but should be construed broadly.
- an “object” may be represented by a row of data from one or more relational database tables, and an associated “link” may simply be a reference from one row to another row (e.g., a data row address or the like).
Abstract
A data management method is provided for storing a real-time history of a file system, or a component thereof, such as a directory or a file. The real-time history is stored as an object-oriented logical representation comprising at least a set of version metadata objects, and a set of one or more links that associate given objects of the set of version metadata objects. As one or more events occur in the real-time history, the logical representation is restructured dynamically. The logical representation is useful to provide any point-in-time reconstruction of the file system component on an as-needed basis.
Description
- This application is a continuation-in-part of U.S. Ser. No. 11/123,994, filed May 6, 2005, which application was based on and claimed priority to U.S. Ser. No. 60/569,164, filed May 7, 2004.
- This application is related to the following commonly-owned applications:
- Ser. No. 10/841,398, filed May 7, 2004, titled “Method and system for automated, no downtime, real-time, continuous data protection,”
- Ser. No. 10/842,286, filed May 10, 2004, titled “Method and system for real-time event journaling to provide enterprise data services,”
- Ser. No. 10/863,117, filed Jun. 8, 2004, titled “Method and system for no downtime, real-time, continuous data protection,”
- Ser. No. 10/862,971, filed Jun. 8, 2004, titled “Method and system for no downtime, resynchronization for real-time, continuous data protection,”
- Ser. No. 11/185,313, filed Jul. 20, 2005, titled “Method and system for virtual on-demand recovery for real-time, continuous data protection,” and
- Ser. No. 10/943,541, filed Sep. 17, 2004, titled “Method and system for data protection.”
- 1. Technical Field
- The present invention relates generally to enterprise data management.
- 2. Background of the Related Art
- A critical information technology (IT) problem is how to cost-effectively deliver network wide data protection and rapid data recovery. In 2002, for example, companies spent an estimated $50B worldwide managing data backup/restore and an estimated $30 B in system downtime costs. The “code red” virus alone cost an estimated $2.8 B in downtime, data loss, and recovery. The reason for these staggering costs is simple—traditional schedule based tape and in-storage data protection and recovery approaches can no longer keep pace with rapid data growth, geographically distributed operations, and the real time requirements of 24×7×265 enterprise data centers.
- Although many enterprises have embarked on availability and recovery improvement programs, many of these programs have been focused on the redundancy of the infrastructure, not on the data itself. Yet, without data availability, applications cannot be available.
- Today's legacy data protection and recovery solutions are highly fragmented across a wide variety of applications, systems, and storage models. The overhead and data management maze that existing approaches bring to the network, storage, tape, and application infrastructure has caused increasing expenditures with little tangible returns for the enterprise. Worse, manual recovery techniques compound the problem with the same issues that cause downtime in the first place—human errors and process issues constitute 80% of unplanned downtime.
- As a result, businesses are enduring high costs, high risk, and a constant drag on productivity. A recent survey by Aberdeen highlights IT managers' top data storage problems: managing backup and restore (78%), deploying disaster recovery (80%), and delivering required service levels (60%).
- One recently-introduced technique for addressing the complex problem of providing heterogeneous, enterprise-wide data management is illustrated in
FIG. 1 .FIG. 1 illustrates arepresentative enterprise 100 in which a data management system (DMS) is implemented to provide enterprise data protection. A commercial version of this architecture is available from Asempra Technologies, Inc., of Sunnyvale, Calif. In this illustrative example, anenterprise 100 comprises aprimary data tier 102 and asecondary data tier 104 distributed over IP-based wide area networks 106 and 108. Wide area network 106 interconnects twoprimary data centers satellite office 114 to the rest of the enterprise. Theprimary data tier 102 comprises application servers 116 running various applications such as databases, email servers, file servers, and the like, together with associated primary storage 118 (e.g., direct attached storage (DAS), network attached storage (NAS), storage area network (SAN)). Thesecondary data tier 104 typically comprises one or more data management server nodes, andsecondary storage 120, which may be DAS, NAS, and SAN. The secondary storage may be serial ATA interconnection through SCSI, Fibre Channel (FC or the like), or iSCSI. The data management server nodes create a logical layer that offers object virtualization and protected data storage. The secondary data tier is interconnected to the primary data tier, preferably through one or more host drivers to provide real-time data services. Data management policies 126 are implemented across the secondary storage in a well-known manner. A similar architecture is provided indata center 112. In this example, theregional office 114 does not have its own secondary storage, but relies instead on the facilities in the primary data centers. - As described in co-pending application Ser. No. 10/841,398, the DMS system associates a “host driver” 128 with one or more of the application(s) running in the application servers 116 to transparently and efficiently capture the real-time, continuous history of all (or substantially all) transactions and changes to data associated with such application(s) across the enterprise network. This facilitates real-time, so-called “application aware” protection, with substantially no data loss, to provide continuous data protection and other data services including, without limitation, data distribution, data replication, data copy, data access, and the like. In operation, a given
host driver 128 intercepts data events between an application and its primary data storage, and it may also receive data and application events directly from the application and database. Thehost driver 128 may be embedded in the host application server 116 where the application resides; alternatively, the host driver is embedded in the network on the application data path. By intercepting data through the application, fine grain (but opaque) data is captured to facilitate the data service(s). To this end, and as also illustrated inFIG. 1 , each of the primary data centers includes a set of one or more data management servers 130a-n that cooperate with thehost drivers 128 to facilitate the data services. The DMS servers provide a distributed object storage that can be built above raw storage devices, a traditional file system, a special purpose file system, a clustered file system, a database, or the like. In this illustrative example, thedata center 110 supports afirst core region 130, and thedata center 112 supports a second core region 132. - As described in co-pending application Ser. No. 11/123,994, each DMS node executes an object runtime environment. This object runtime environment includes an object manager that manages the lifecycle of all the DMS objects during runtime. The object manager creates DMS objects, and the object manager saves them in the shared storage. The objects continually undergo modification as the system protects data in the enterprise's primary storage. In an illustrative embodiment, the system automatically creates a trail of objects called versions; typically, the versions do not actually exist on primary storage, outside of the data management system. The DMS manages the creation, storage, display, recovery to primary storage, deletion (automatic via policy, or manual) and the like, of these versions. The host drivers protect data into the continuous object data store. Using this architecture, data in primary storage can be recovered to any point-in-time.
- A data management method is provided for storing a real-time history of a file system, or a component thereof, such as a directory or a file. The real-time history is stored as an object-oriented logical representation comprising at least a set of version metadata objects, and a set of one or more links that associate given objects of the set of version metadata objects. As one or more events occur in the real-time history, the logical representation is restructured dynamically. The logical representation is useful to provide any point-in-time reconstruction of the file system component on an as-needed basis.
- The object-oriented logical representation is advantageous as it provides an efficient way to index a real-time history of changing data in a file system. This representation preferably is constructed over a database, such as a relational database, a raw file system, or any other set of one or more storage devices.
- The foregoing has outlined some of the more pertinent features of the invention. These features should be construed to be merely illustrative. Many other beneficial results can be attained by applying the disclosed invention in a different manner or by modifying the invention as will be described.
- For a more complete understanding of the present invention and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:
-
FIG. 1 is an illustrative enterprise network in which the present invention may be deployed; -
FIG. 2 is an illustration of a general data management system (DMS) of the present invention; -
FIG. 3 is an illustration of a representative DMS network according to one embodiment of the present invention; -
FIG. 4 illustrates an object data structure for tracking data history according to a preferred embodiment; -
FIG. 5 illustrates a representative DMS object instance hierarchy according to a preferred embodiment; -
FIG. 6 illustrates a sample instance of a directory object; -
FIG. 7 illustrates a sample instance of a file object; -
FIG. 8 illustrates a sample file system history according to the present invention; -
FIG. 9 illustrates another sample file system history; -
FIG. 10 is a flow diagram illustrating a process for creating a file or a directory in the DMS file system history structure; -
FIG. 11 illustrates the sample file history ofFIG. 9 after a new file object has been created in the DMS; -
FIG. 12 is a flow diagram illustrating a process for modifying a file or a directory in the DMS file system history structure; -
FIG. 13 illustrates how modifying a directory object alters the DMS object store ofFIG. 11 ; -
FIG. 14 illustrates how modifying a file object alters the DMS object store ofFIG. 11 ; -
FIG. 15 is a flow diagram illustrating a process for deleting a file or a directory in the DMS file system history structure; -
FIG. 16 illustrates how deleting a file object alters the DMS object store ofFIG. 14 ; -
FIG. 17 is a flow diagram illustrating a process for renaming or relocating a file or a directory in the DMS file system history structure; -
FIG. 18 illustrates representative DMS data structure changes (with respect toFIG. 16 ) that occur when a file is renamed and the parent does not track a child name; -
FIG. 19 illustrates representative DMS data structure changes (with respect toFIG. 16 ) when the file is renamed and the parent does track child name; -
FIG. 20 illustrates representative DMS data structure changes (with respect toFIG. 19 ) when a file is relocated and versioned by object instance; -
FIG. 21 illustrates representative DMS data structure changes (once again with respect toFIG. 19 ) when the file is relocated and versioned by object path; -
FIG. 22 illustrates several variants of the relocation technique ofFIG. 21 ; -
FIG. 23 illustrates a sample baseline file system object store prior to a directory relocation; -
FIG. 24 illustrates a directory relocation based on a versioned by object instance model usingFIG. 23 as the initial baseline; -
FIG. 25 ; illustrates a directory relocation based on versioned by object path model usingFIG. 23 as the initial baseline; and -
FIG. 26 illustrates a directory relocation based on a combination of versioned by object path and versioned by object instance, once again usingFIG. 23 as the initial baseline. -
FIG. 2 illustrates a preferred hierarchical structure of adata management system 200 in which the present invention may be implemented. As illustrated, thedata management system 200 comprises one ormore regions 202 a-n, with eachregion 202 comprising one or more clusters 204 a-n. A given cluster 204 includes one ormore nodes 206 a-n and a sharedstorage 208 shared by thenodes 206 within the cluster 204. A givennode 206 is a data management server as described above with respect toFIG. 1 . Within a DMS cluster 204, preferably all thenodes 206 perform parallel access to the data in the sharedstorage 208. Preferably, thenodes 206 are hot swappable to enable new nodes to be added and existing nodes to be removed without causing cluster downtime. Preferably, a cluster is a tightly-coupled, share everything grouping of nodes. At a higher level, the DMS is a loosely-coupled share nothing grouping of DMS clusters. Preferably, all DMS clusters have shared knowledge of the entire network, and all clusters preferably share partial or summary information about the data that they possess. Network connections (e.g., sessions) to one DMS node in a DMS cluster may be re-directed to another DMS node in another cluster when data is not present in the first DMS cluster but may be present in the second DMS cluster. Also, new DMS clusters may be added to the DMS cloud without interfering with the operation of the existing DMS clusters. When a DMS cluster fails, its data may be accessed in another cluster transparently, and its data service responsibility may be passed on to another DMS cluster. -
FIG. 3 illustrates the data management system (DMS) as a network (in effect, a wide area network “cloud”) of peer-to-peer DMS service nodes. As discussed above with respect toFIG. 2 , the DMS cloud 300 typically comprises one or more DMS regions, with each region comprising one or more DMS “clusters.” In the illustrative embodiment ofFIG. 3 , typically there are two different types of DMS regions, in this example an “edge”region 306 and a “core”region 308. This nomenclature is not to be taken to limit the invention, of course. Anedge region 306 typically is a smaller office or data center where the amount of data hosted is limited and/or where a single node DMS cluster is sufficient to provide necessary data services. Typically,core regions 308 are medium or large size data centers where one or more multi-node clusters are required or desired to provide the necessary data services. The DMS preferably also includes a management gateway 310 for controlling the system. As seen inFIG. 3 , conceptually the DMS can be visualized as a set ofdata sources 312. A data source is a representation of a related group of fine grain data. For example, a data source may be a directory of files and subdirectory, or it may be a database, or a combination of both. Adata source 312 inside a DMS cluster captures a range of history and continuous changes of, for example, an external data source in a host server. A data source may reside in one cluster, and it may replicate to other clusters or regions based on subscription rules. If a data source exists in the storage of a DMS cluster, preferably it can be accessed through any one of the DMS nodes in that cluster. If a data source does not exist in a DMS cluster, then the requesting session may be redirected to another DMS cluster that has the data; alternatively, the current DMS cluster may perform an on-demand caching to bring in the data. - As described in U.S. Ser. Nos. 10/841,398 and 11/123,994, the DMS provides real time data services, such as continuous data protection, data replication, data distribution, any-point-in-time recovery, and any-point-in-time snapshot. To support these services, preferably the DMS host driver resides in an application host or the network, monitoring and capturing application events and data changes in real time, and then processing and forwarding actual data changes, events, and metadata to a DMS node. The host driver preferably performs delta reduction (e.g., to extract byte level changes), identifies metadata changes such as access control, detects application checkpoint events, and then forwards this information as a stream to a DMS node in a DMS cluster. A DMS cluster is a group of DMS nodes that share a storage module. These nodes work as a cooperative unit. Preferably, they obey a set of access rules such as acquiring lock of different classes, and they honor the access locks of the others so as to perform parallel access to the storage module. These nodes also watch for the health of one another and when one node fails, the other nodes preferably repair any partially modified or corrupted data that may be caused by the failure, and take over the tasks of the failed node.
- The DMS nodes are the entities that provides real-time data services. When providing continuous data protection and data distribution as subscriber, the nodes take incoming data streams, preferably translate the streams into an object-oriented data structure (or another structure that provides similar data associations and indices), and save the data in a storage module that is referred to herein as an object store. The object store is designed with the purpose of managing real-time continuous history. When providing data replication, data recovery, and generating a snapshot, the DMS node navigates its object store, reconstructs a desired point-in-time data object, and forms outbound data streams that are then delivered to target nodes or host machines. To provide continuous replication, once replicating a point-in-time data object, the DMS node also forwards, to a remote DMS or a remote host server, a continuous redo log of the objects (in the form of a real-time event journal). A goal of the DMS is to store fine grain and real-time data history. Thus, the DMS object store is designed to track fine grain data changes without using excessive storage. The DMS preferably also indexes by time and events all fine grain objects, application checkpoints, and metadata globally across DMS clusters. The events may include any object events such as email arrival, transaction activity, a file open, a file modification, a file close, a directory change, an application checkpoint, a system upgrade, a virus detection (such as from an external network service), a business event tag, or the like.
- The DMS nodes create distributed object storage to provide the necessary real-time data management services. The objects created by the DMS nodes are sometimes referred to herein as active objects. The active objects at any moment in time may be dormant in the storage or instantiated by the DMS nodes to handle requests and to perform activities. The details of active objects are discussed in the following sections.
- The distributed object store can be built above raw storage devices, a traditional file system, a special purpose file system, a clustered file system, a database, and so on. Preferably, DMS chooses to build the distributed object store over a special purpose file system for storage and access efficiency. The files in the special purpose file system and the active objects in the DMS preferably are all addressed by a (e.g., 128 bit) global unique identifier (GUID). During runtime, a GUID can be de-referenced to a physical address in a storage device. By doing so, this allows the object store to scale beyond a single storage device, such that an object (1) in a device (A) can refer to another object (2) in device (B), e.g., by referring to the GUID of object (2).
- Preferably, each DMS node executes an object runtime environment. This object runtime environment includes an object manager that manages the lifecycle of all the DMS objects during runtime. The object manager creates DMS objects, namely the active objects, and the object manager saves them in the shared storage. When requested, the object manager loads an existing active object from the storage, and then routes object requests directly to the instantiated active object. Once an active object is created or loaded (instantiated) into the memory, it is responsible for executing requests routed from the object manager. The object manager may perform authentication and/or authorization before allowing any access to an active object. An active object, upon request, may update its internal information, execute an object specific program, and terminate itself from the runtime environment. Both the object manager and the active objects are responsible for acquiring shared lock as necessary so that all the nodes can have parallel access to the same objects. The object manager is also responsible for permanently removing active objects from the shared storage when requested. In a non object-oriented embodiment, an object manager may not be required. Also, while the use of an object manner is preferred, it is also possible to implement the present invention by storing the object information in a different manner while still achieving similar results, and the processes and object functions that change the information may be modified accordingly.
- Preferably, an instance of an active object has a set of properties, with each property having a label and value pair. For example, an active object may have one property labeled as “name” with an associated value being “The design of a PC,” and another property labeled “content” which associated value is a binary blob. A property has a value type definition, for example, the value of the “name” property is a string, and the value of the “content” property is an opaque binary chunk of data.
- For example, when DMS protects a file from a server, the DMS active object for the file may have a list of representative properties such as shown below:
- ObjectClass: <a 128 bit file object class identifier>
- ObjGUID: <a 128 bit unique identifier for this object>
- Creator: <a user identifier>
- ExtemalCreationDateTime: <a time stamp>
- DMSCreationDateTime: <a time stamp>
- Name: <a string>
- ParentObject: <a GUID of a directory object>
- ACL: <an object GUID>
- Version: <integer or time stamp>
- Size: <integer>
-
- ExternalModifiedDateTime:<a time stamp>
- DMSModifiedDateTime:<a time stamp>
- DMSTerminationDateTime: <a time stamp>
- ModifiedBy: <a user identifier>
- Company: <a string>
- Department: <a string>
- Title: <a string>
- Subject: <a string>
- Keywords: <a string>
- Comments: <a string>
- Content: <a random binary blob>
- In the context of a traditional file system, preferably all properties beside the “content” property are classified as metadata whereas, in the DMS, preferably all properties including the “content” itself are managed as metadata. Preferably, the DMS active objects store metadata from the protected server as well as metadata generated by the DMS itself. In DMS active object point of view, all the properties are metadata, including the binary content from the external world, while binary content is just a specific property type (random access binary blob type).
- A property on an active object preferably also has specific attributes such as -modifiable, modifiable-internal, read-able, versionable, single-value vs multi-value, inheritable, index, mandatory, replicate-able, and the like. Some object properties, such as ObjectClass, ObjGUID, Creator, ExternalCreationDateTime, and DMSCreationDateTime do not change once the object is created, while the other properties can be modified. There are also properties, such as Version, DMSModifiedDateTime, and DMSTerminationDateTime, that are not modifiable by any external entity besides the Object Manager and the object itself.
- The following is a table of possible property types:
Property Type Description Integer a number String a Text string GUID Preferably a 128 bit global unique ID across all DMS nodes. This property store the GUID of another object that allows objects to be linked. Constant a set of related unique numbers that represent some specific information Random access binary blob Binary data for random access Sequential access binary blob Sequential records Boolean True/false ComplexType Combination of one or more of the above - The following is a table of possible attributes for each property:
Property attributes Default Description Modifiable True Property once created, can be modified by an internal or external request Modifiable- True Property once created, can be only be internal modified by the DMS internally Read-able True Property can be accessed by external request Version-able True Property can be versioned. For example, modification-date-time is a version-able property. Multi-value False If Multi-value is True, the property has many values. For example, the children property of a directory object is a multi-value property. If Multi-value is False, the property is single value property. Single value is the default of all property. Inheritable False If True, when object receives a request for the property, and if the property is not set, the object can request for the value from its parent in the object hierarchy. For example, a file object may request for a value from its directory object. By default, all properties are not inheritable. Index False If True, the DMS automatically generates a specific index for the property to accelerate search. Indeed, the entire object structure may be considered an indexing structure; however, by having a specific property index, the system allows for a focused and efficient search on that property. Once indexed, the object can be searched using the index of the property. The indexed properties are name, fingerprint, and the like. By default, a property is specifically indexed. If a property is not indexed, preferably it is still searchable by an algorithm iterating through all the objects. Replicate-able True If Replicate-able is True, then when the associated property is replicated when the object is replicated. - To track real-time changes, some object properties are defined as version-able. In the DMS, an object data structure for tracking data history is as shown in
FIG. 4 . InFIG. 4 , pages are simply logical and variable size chunk of data entities. Each page is labeled with a GUID. Ananchor page 401 contains the <property, value> of those metadata that are not version-able and do not change over time, while the metadata page (402, 403 and 404) of each version contains only the versioned properties. The pages refer to one another by GUID (which is an address or a link to another group of information). In addition, an object may have an access control list (ACL) that specifies who has what level of access right to the data. In the case of DMS, the ACL is stored in aseparate page - In DMS, preferably all the anchor and version metadata pages are combined together into a variable sized file. If desired, each one of the pages can be stored in a separate file, or in raw storage blocks. When stored in files, each file is also named by GUID. There are page GUID to file GUID mappings, and file GUID to physical address mappings so that the physical data of an object can be retrieved. An object can be reference by the GUID of its anchor page, or the GUID of its version metadata page. When referred by the GUID of its version metadata page, a point-in-time object is presented.
- According to another aspect of the inventive DMS, an active object has a basic set of behaviors and some specific set of behaviors that are schema dependent and may be created specifically for the class definition. The following are examples of interfaces that initiate specific object activities. In particular, a basic set of behaviors that may be initiated by the interface for life cycle management, getting and setting attributes:
-
- CreateObject (of a specific class)
- DestroyObject (an object GUID)
- ObjectOpen (an object GUID, a point-in-time, and mode)
- ObjectClose (an opened object handle)
- ObjectTerminate (an opened object handle)
- ObjectLock (an opened object handle, and mode)
- ObjectGet (an opened object handle, a list of properties)
- ObjectSet (an opened object handle, a property, a value)
- ObjectMVGetFirst (an opened object handle, a property)
- ObjectMVGetNext (an opened object handle, a property)
- ObjectMVGet (an opened object handle, a property, key)
- ObjectMVAdd (an opened object handle, a property, value)
- ObjectMVDelete (an opened object handle, a property, key)
- ObjectRead (an opened object handle, a property, an offset, a length)
- ObjectWrite (an opened object handle, a property, an offset, a length, data)
- ObjectApply (an opened object handle, a property, a delta string)
- ObjectRecordAppend (an opened object handle, a property, record, length)
- ObjectRecordGetFirst (an opened object handle, a property)
- ObjectRecordGetNext (an opened object handle, a property)
- ObjectRecordGetAt (an opened object handle, a property, a position)
- ObjectExecute (an open object handle, a function, parameters)
These functions may be implemented readily in software code, i.e., as a set of program instructions executable in a processor. CreateObject( ) creates a physical active object in the DMS object store, while DestroyObject( ) removes the physical object completely. Once created, an active object can be instantiated by ObjectOpen( ) and it can be manipulated. ObjectClose( ) ends the execution cycle of an object. ObjectTerminate( ) terminates an object version and prevents a new version from ever be created. ObjectGet( ) and ObjectSet( ) are for accessing a single value property; the generic behavior for setting a property is to first validate the property type before allowing the update to occur. ObjectMVGetFirst( ), ObjectMVGetNext( ), ObjectMVGet( ), ObjectMVAdd( ), and ObjectMVDelete( ) are for accessing a multi-value property. A multi-value property has unique key, for example, CHILDREN may be a multi-value property, and its unique key may be the name or the GUID of the child. ObjectRead( ), ObjectWrite( ), and ObjectApply( ) are for accessing metadata of a random access binary blob type. ObjectRecordAppend( ), ObjectRecordGetFirst( ), ObjectRecordGetNext( ), and ObjectRecordGetAt( ) are for accessing metadata of sequential access binary blob type.
- The above object interfaces are a representative subset of the actual basic object behaviors of the DMS. There are merely illustrative of the functional behavior of the active objects. If desired, an object class may define its own set of specific behaviors.
- In DMS, and as will be described in more detail below, preferably there are many data source active object classes, for example, a directory object, a file object, database object, and the like.
FIGS. 6-7 illustrate sample instances of a respective directory object and a file object. In particular, inFIG. 6 the directory object (FOO) has three versions. In the first version, the directory object only has theversion 1 of a subdirectory object—DOO. The subdirectory object changed its name to WOO, thus aversion 2 of the subdirectory object is created; as a result, aversion 2 of FOO is created to link to theversion 2 of the subdirectory. Onversion 3 of FOO, a new file under the directory FOO is created. The links, shown as dotted arrows, on the directory object FOO are stored as a “CHILDREN” property, and this property is of multi-value GUID type. These links allow the active object to build up object relationships or an object hierarchy; in this case, which is merely representative, it is parent-child relationship. This is a logical view of the directory data structure. For conservation of storage usage, the directory version pages may be combined into a table or a journal, and the table or journal may be stored in a special purpose file or a raw device block. For simplicity, the above diagram intentionally does not show the entire subdirectory and file objects (for example, the anchor pages are not shown). -
FIG. 7 is an example of a DMS file object, which is an active object that tracks history, as opposed to a file in a traditional file system. The DMS uses this object structure for storing the history of a file from an external host server. As previously mentioned, in one embodiment of the invention, the DMS overlays the object structure of its object store over a special purpose file system for storage usage efficiency. Thus, the object store is a logical structure and the file system is the physical structure. In the DMS file object, preferably there is a property called “CONTENT,” and this property is of the type random access binary blob. The binary value of this property type may be stored inside or outside of the metadata page. In this case, the binary data ofversion 1 is in abinary page 716 that has its own GUID. The changes (deltas) that are made to the file forversion 2 may be stored as a sequence of forward deltas in adelta page 717. The changes (deltas) ofversion 3 may also be appended to the same delta page or another new delta page. Both the binary and delta pages may be stored in one special purpose file, be broken up and stored in multiple special purpose files, be stored in a database, or be stored in raw storage devices. The purpose of storing a baseline and a set of deltas is for storage efficiency, and this binary data format can be used with other embodiments (such as where the logical representation is not in object-oriented form). Also, for access efficiency, there may be a new baseline after some number of deltas. This means that, for objects with a long history, there may be multiple baselines and a set of deltas for each baseline. - Active object binary data management is designed for managing history of random access binary blob property type. As shown in
FIG. 8 , the property type of random access binary blob may be stored inside a metadata page, or it may be stored outside a metadata page in both binary and delta pages. Regardless of how the random access binary data are stored, the DMS manages this data the same way, preferably through a sparse index. As mentioned earlier, for binary data management, an initial full binary content is first captured into a binary page, and then the random changes to the binary contents are stored as a sequence of forward deltas (or delta strings) in delta pages. Delta strings preferably are of specific syntax. A delta string can represent an insertion, a deletion, or a replacement to an existing binary blob. To avoid having to apply deltas in real-time when a file version is accessed, preferably a byte level index is maintained as part of the random access binary blob property. The sparse index forversion 1 of a file may specify that the entire binary content of the file is in a specific binary page. The sparse index forversion 2 of the same file may specify that certain byte ranges of the binary content ofversion 2 are in some specific locations of the binary page, while other byte ranges are in some specific locations of the delta pages. - For the active objects to manage history of sequential access binary blob such as database journal activities, a binary page of sequentially appended records structure can be used in the DMS. Records management is designed for managing property type of sequential access binary blob. There are three different types of record management namely—formatted records, unformatted records, and file object associated records. Formatted records are a sequence of well defined records, each record is of specific structure of fields, and each field has well defined data type and length. A record schema (record structure definition) is defined for formatted record property type. This type of record can be used to track SQL requests of a database history, or email activities of an email server history. A formatted record can also be used to track real-time events associated with any data object. Unformatted records are a sequence of binary record chunks, in this case, the record chunks may be appended continuously to a binary data page with or without a header that specifies the length of the record. Alternatively, records can be appended to a binary data page without a header, in which case, the boundary of each record chunk is tracked separately. The boundary of unformatted records can be tracked using formatted record management structure. This type of record can be used to track sequential binary journal of a database or sequential journal file of any application. The characteristic of this type of binary journal is that records are always appended to the end and never override previous records. File object associated records are sequences of meta-information containing binary data updates to an associated file object. A file object associated record is used to track the location and length of each modification to a file object. Besides tracking the file modifications, a file object associated record can also be used to track checkpoints that occur with respect to the file.
- Once an object schema is created, an active object instance can be created from the schema. The active object instance has the defined metadata and behavior. As in any object-oriented system, an object schema may be defined based on another object schema so that metadata and behaviors can be inherited, or so that coded functions can be reused. In DMS, a generic object is clsObject, which defines basic metadata such as name, creation date and time, creator, modification data and time, and so on. It also defines the basic object behavior. Preferably, other object schemas are defined based on clsObject (i.e., they inherit from clsObject). The object inheritance feature is an advantage of the object-oriented embodiment, however, it is not a limitation of the invention.
- Thus, to provide real-time data management services, DMS preferably defines a set of data management specific object schemas as shown in
FIG. 5 . These object schemas are used to create the “active” objects that have specific metadata and behaviors as defined in the schema. The DMS object definition set forth below is a preferred (but non-limiting) way of organizing the control, data, and functional structure for the DMS to provide real-time data management services. - The schema clsDMSSystem is a class for creating a DMS cloud
active object 520 that represents the logical network of the entire DMS system (with multiple DMS clusters over multiple regions). Preferably, there is only one instance of clsDMSSystem in a DMS network, as it is the root object instance of the entire DMS network. Preferably, this object is used for tracking DMS regions 512 (each as an instance of a clsRegion schema as described below) and DMS functional groups that own data across regions 516 (each as an instance of a clsGroup schema as described below). The instance typically has a randomly assigned unique identifier. The instance preferably is created automatically by the DMS network when a first cluster is configured, i.e. it is created by a first node. This object instance is populated to all the storage clusters in the entire DMS network. Preferably, there is only one master copy of this object, which is the original copy, the one that was created first. When the properties of the instance change, the properties are populated to all replicas. - The schema clsRegion is a class for creating DMS region
active objects 512 that represents and tracks a DMS cluster network, data network, and server network. Preferably, there is one instance of clsRegion in each physical location. An active object instance of clsRegion is used for tracking all the DMS clusters 530 (each as an instance of a clsCluster schema as described below), repositories 514 (each as an instance of a clsRepository schema as described below), and host servers 528 (each as an instance of a clsHost schema as described below) in the region. Because each region may have multiple storage clusters, the local instance of the clsRegion object is replicated to all the local storage clusters. The GUID of each instance of clsRegion are randomly assigned when created. Preferably, policies are encoded as properties in clsDMSSystem, clsRegion, clsRepository, clsGroup, and clsXXDataSource. - The schema clsRepository is a class for creating a
DMS data container 514 for storing protected data sources. A repository instance may havesub-repository instances 514 and/or protected data sources 518. A root repository object that is directly under a region represents a segment of a data network. A repository may be a child of a region or a child of another repository. The child of a region is the root of a DMS data object hierarchy. The repository object provides regional data grouping and policy enforcement. The policies in a repository are executed against all the data sources within the scope of the repository. Alternatively, a separate policy object may be defined and used for storing policies explicitly in the data hierarchy. If policy object instances are used, they can be attached to any one of the data container object instances. - The schema clsXXDataSource is a class for creating data source
instances 518. Preferably there are three basic data source schemas, clsFSDataSource, clsDatabaseDataSource, clsCompoundDataSource. If desired, there may be more schemas for application data other than the file system and one or more databases. An active object instance of a clsXXDataSource is a root container for a protected data source where a data source from a host is streamed. An instance of clsFSDataSource contains a file, a directory, or a volume of a file system and its history, while an instance of a clsDatabaseDataSource contains one or more databases and their history from a database server. An instance of a clsCompoundDataSource is a container for multiple data source instances. Unlike a repository that only provides logical containership, a compound data source instance preferably provides activity sequencing and indexing, as well as consistency marking to the real-time activities of its related group of data sources so that group consistency can be maintained. - The class clsFile is a schema for creating object instances for the DMS to store the information of a
file 520 from a host server and also to track the history of that file in the host. An instance of a clsFile is similar to a file in a file system, except that an instance captures, indexes and manages file history. In DMS, this object is used for data protection, with each instance of clsFile used to represent an external file in an external host. - The class clsDirectory is a schema for creating object instances for the DMS to store the information of a
directory 522 from a host server and also to track the history of that directory in the host. An instance of a directory simply represents a container of files and other sub-directories. - The class clsDatabase is a schema for creating object instances for the DMS to store the information of a
database 524 within a database server, and also for tracking and indexing the history and checkpoints of that database in the server. This object is used to provide database protection services. An instance of a clsDatabase represents a continuous consistent image of a database, across a range of time, from an external host server. - The class clsJournalGroup is a schema for creating
object instances 526 for the DMS to journal the redo and undo log journal) activities of a database. The database journal activities may be a sequence of updates to a group of related journal log files, or application level transaction records. - The class clsRecordFile is a schema for creating
object instances 527 for the DMS to track sequential journal entries within a journal group. - An active object instance of the clsHost is created whenever a host driver from a new host server first connects to the DMS network. This object allows the DMS to track the data services provided to the information on the
host 528. This object also associates the protected data sources in the DMS to the data source on its host server. An instance of clsHost preferably contains information such as the platform of the host, the operating system, the host configuration, data sources that are protected from the host, DMS data sources that are replicated to the host, and the like. The protected or replicated data source properties preferably include the host path, the size of the sources in the host, the activities and statistical information about those data sources, and the GUID of the clsXXDataSource instance. - An active object instance of the clsDMSCluster schema represents a
DMS cluster 530 with one or more DMS nodes and the DMS storage. This instance provides statistics and status information of its specific cluster. Typically, there is only instance per storage cluster, thus the processes (e.g., the object runtime environment) of all the nodes use this instance as shared memory to keep information such as node availability, master election, and the like. Information about a DMS cluster (as instances of a clsDMSCluster), a DMS node (as instances of clsDMSNode), and DMS storage (as instances of clsDMSStorage) may be stored together with the other active objects or may be in a specific volume used exclusively by the cluster manager. - An active object instance of the clsDMSNode schema represents a
DMS node 532 within a DMS cluster. This instance provides statistics and status information about the DMS node it represents. Preferably, the object runtime environment of a node is responsible for locating a cluster and joining that cluster. Once joined in a cluster, the runtime environment creates the clsDMSNode instance. - An active object instance of the clsDMSStorage schema represents the
storage volumes 534 of a DMS cluster. This instance allows the DMS storage to be configured, and it also provides statistics and status information of the storage volumes. - An active object instance of the clsGroup schema is a data container that also represents a
logical group 516 in an organization. This allows user to map data sources from one or multiple repositories in one or more regions to a functional group of an organization. Its purpose is to enable an administrator or other permitted entity to assign data management policy across multiple regions. - As described above, in the
FIG. 5 hierarchy preferably policies are stored as properties in a given data container although, in an alternate embodiment, a separate policy object (e.g., clsPolicyProfile) may be used. An active instance of the clsPolicyProfile schema may contain a set of data management policies. There may be one or many policy profiles in the DMS network. A policy profile object can be assigned (as a default data management policy) to any data container, such as the universe (an instance of clsDMSSystem), regions, repositories, groups, or protected data sources, or to any data object, such as files, directories, and databases. When assigned to a container, all sub-containers or the data objects within that root container are governed by the set of policy rules. As noted above, a region (or a repository) object allow an administrator to set policies for data in the same region, while a functional group object allows an administrator to set policies for data in multiple regions. Typically, a policy is a combination of a set of properties, e.g., a rule, an override rule, one or more qualifying events, one or more qualifying property values, and/or a schedule. A rule may be a Boolean expression with an action, and a rule may be nested. - Similar to an instance of a clsPolicyProfile object, an active object instance of a clsPolicyOverride can be introduced that may also contain a subset of data management policies. When assigned to a data container or data object, the policies in the override object takes precedent over the default policy on an assigned policy profile objects.
- The DMS object definition discussed above is merely one way of organizing the control, data and functional structure for the DMS to provide real-time data management services. One could easily reorganize the structure to achieve that goal, and the present invention is not limited to any specific organization. Thus, for example, clsRegion may be broken down in to multiple hierarchies to represent local lines of business and departments, clsDMSCluster may include and nodes and storage so as to eliminate clsDMSNode and clsDMSStorage definitions, clsJournalGroup may be part of clsDatabase definition, and so on. Also, as described above, the effect of this object-oriented hierarchy can be realized in different non object-oriented structures, such as a relational database. All of these variants are within the scope of the present invention.
-
FIG. 5 illustrates a relationship among DMS active objects. This diagram does not show any object history (object versions). Policy profile and policy override objects are also not shown in this figure to avoid complexity. - In
FIG. 5 , an active object instance is represented by I<object schema> (note that a schema is the same as a class; it is the definition of an object). The “I” stands for instance, and object schema is the definition of that object class. As illustrated, there is only one instance of the DMS system object 510 (i.e. one DMS network). As illustrated, one ormore regions 512, and zero or morefunctional groups 516 can be created under the DMS network. As noted above, the region and group active objects are used for storing configuration information about the region and the functional group. Functional groups may have sub-groups (i.e. group within group).Data repositories 514 can be created under aregion 512. Much like groups, repository may havesub-repositories 514, as has been described.Protected data sources 518 reside within arepository 514. Data may be streamed into a data source from a protected host server, or streamed into a data source from another DMS data source through remote distribution service provided by the DMS. A data source may be configured to replicate to a remote repository. Within adata source 518, the real-time history of data files 520,directories 522,databases 524,database journals 526, email databases, email messages, and the like, are captured and indexed. The present invention focuses on file system data history, as will be seen. Thegroups 516,repositories 514, protecteddata sources 518, and the data objects within the data sources are known as thedata network 502. Although not shown in this diagram, policy can be assigned to all the objects in the data network and all the objects above the hierarchy of the data network. Preferably, policies are enforced in hierarchical order and with specific override rules. - Whenever a DMS host driver is installed into a host server, the host driver reports to the DMS, and this operation results in an instance of
host object 528 being created in the DMS. As noted above, preferably ahost object 528 contains information such as the host OS and platform about the host server. Once a host object is created, IT administrators can identify host data to be protected, and then configure for the host data to be protected. An IT administrator can also configure for DMS protected data to be replicated to a host server. As noted above, the host active object refers to the data source(s) that are protected from its host server or data sources that are replicating to its host (as illustrated by the link between 518 and 528). The host objects in the DMS form an externalhost server network 506. - A region may have one or more DMS clusters, with all DMS clusters preferably tracked by the DMS via DMS cluster
active objects 530. Each cluster has a representation active object that refers to the nodeactive objects 532 and storageactive objects 534. The cluster object also contains cluster statistic and status information. Anode object 532 contains configuration information, statistics and status about the node. The storage object contains storage volume information, and storage group information. Volume information includes all the raw storage volumes that are provisioned to the DMS. It also includes the DMS partitioning of the raw storage volumes, and the assignment of the partitions to storage groups. In the DMS, a protected data source has its own storage space that is called a storage group. A storage group is an aggregated DMS storage partitions carved out from the volume groups. The cluster, storage, and node objects form aDMS server network 504. - File System Data History
- The following section describes representative object schemas defined for protecting a file system according to the present invention. Preferably, and with reference to
FIG. 5 , there are three object classes (schemas) for file system protection, namely File System Data Source class (clsFSDataSource), Directory class (clsDirectory) and File class (clsFile). - In the context of a file system at a host server, typically all properties except the content are usually known as metadata. As described above, the DMS active objects store metadata from the protected host server as well as metadata generated by the DMS itself. In the DMS, all the properties are metadata including the binary content from the external world. For a clsFile object, binary content is a “content” property with random access binary blob type.
- ClsFSDataSource
- This is a schema of a file system data source; as noted above, this object preferably serves as a container for the history of a protected file system or folder in a host. It is also a data service entity for managing inbound and outbound traffic for the file system, the policy management entity for its data, and a security guard for any access to the protected data history.
- The properties of this object class typically include the configuration of the protected data source. The following table illustrates representative property examples of this object class:
Properties of clsFSDataSource Descriptions ID GUID Name Name of the data source Parent GUID of its parent container (a repository object) DateTimeCreated Timestamp when this data source container is created Owner The user ID of the creator ACL Key or GUID to the access control list of this object DataSourceType File system RuntimeStates Protecting, replicating, disconnected from host, and the like Status Active, archived Master GUID of the original protected data source (if this is a replica) Replicas GUID of the replicas that need input from this object Host GUID of the associated host object where the data source resides HostPath The path name in the host that is protected by this object ProtectedDateTime Timestamp when protection begun ArchivedDateTime Timestamp when this data source became idle Children The root directories or files in this container EventTags List of entries with event and timestamp. The events are in data source level, may be set by users. - As can be seen, the above table is a subset of properties used in the DMS; one may add more or remove some of the above properties. For example, policy may be added, and one may not need RuntimeStates. In one embodiment, the properties of this object are not versioned so that the history of the object is not tracked. Alternatively, one can version some of the properties, such as HostPath, ProtectedDateTime, ArchivedDateTime, and Children, such that these configuration changes are recorded in time. When properties are versioned, it is desirable to track the version begin and end timestamp.
- ClsDirectory
- The ClsDirectory schema is defined for tracking the history of a directory (folder) in a file system. This schema is used for protecting a directory, and it is capable of recovering a directory to any point-in-time in the past.
- The properties of this object class preferably include the following:
Properties of clsDirectory Descriptions Non-versioned Properties: ID GUID of this object instance, also GUID of this anchor page DataSourceParent GUID of its protection data source container DateTimeCreated Timestamp when this object is created (from the protected host) Creator The user ID of the creator DateTimeTerminated Timestamp when this object is deleted (from the protected host) EventTags List of entries with event and timestamp. The event tags may be set by users for tracking purposes. FirstVersionID GUID of the first version LatestVersionID GUID of the latest version VersionCount Total number of versions Versioned Properties: ID The version GUID of this object, also GUID of this page AnchorID The GUID of the anchor page (i.e., the GUID of this object) PreviousVersionID The version GUID of the previous version NextVersionID The version GUID of the next version Parent GUID of parent object which can either be the data source container or another directory Name Name of the directory DateTimeModified Timestamp when the version is created (or when the modification occurs) ModifiedBy ID of a user who modified the directory DateTimeEnded Timestamp when this version is ended (i.e., a new modification results in another version being created and old version ended) ACL Key or GUID to the access control list of this object ChildrenCount Number of children Children A list of its children which can be sub-directories or files. Each entry is a reference to the version ID of a child. - These properties are merely illustrative of what a directory active object contains. One may include more properties, such as a full path name, children name, policies, metadata from the host server, and more.
- As can be seen, the above table shows the logical information of a directory object. Whenever a new child is added, an existing child is deleted, the directory is moved, the directory is renamed, or the name of its child has changed (if child name is also captured in this object), a new logical version of the directory is created. Whenever a new version is created, preferably a previous version is terminated. DateTimeModified of a new version must be after or same as the DateTimeEnd of the previous version. ModifiedBy indicates the user who made the modification to create the new version. If desired, an Event tag may be added; preferably, it is a sequence list of entries each having a timestamp.
- This logical layout may map directly into a physical store (e.g., overlaying a file system or a database), but this is not required. With respect to persistent storage, preferably DMS stores multiple logical versions of a directory in one physical store unit. Or, DMS may also combine multiple versions into one directory journal. For example, one physical storage unit of a directory object may contain the initial directory baseline information and all the changes to a directory within a period of time. A directory journal entry may be “version ID, DateTimeModified, add new child, child GUID, . . . ” and so on. Once that is done, a logical version of a directory can be constructed on demand (i.e., upon request) by applying the necessary activities to a baseline directory image. The present invention is not limited to any physical layout of the object in the physical store.
-
FIG. 6 shows a sample instance of a directory object. As can be seen, a representative directory object (FOO) has three versions. Theanchor 610 represents the entire directory object, and the anchor has a reference (FirstVersionID) to afirst version page 612, and a reference (LastVersionID) to alast version page 614. All three versions (612, 613 and 614) have reverse reference (Parent) to their object anchor. All three versions are linked together with their PreviousVersionID and NextVersionID. With these references, one can traverse a directory object and locate the directory information at any point-in-time in the past. In this example, all versions also reference to an ACL page (615 and 616) so that the access control at a point-in-time can also be located. In each of the version pages (612, 613, and 614) there are DateTimeModified and DateTimeEnded properties. As noted above, the DateTimeModified ofversion 2 should be before or equal to the DateTimeEnded ofversion 1; this property allows one to find out what version existed at what time frame. The version pages also preferably contain the ModifiedBy property, which allows one to find out who did what to the directory object when. User events and any system events that are meaningful to the directory can be tagged at the anchor page. When the directory is deleted, the DateTimeTerminated property in the anchor page is set to the deletion time. As can be seen, the this data structure and the associated metadata allows one to track a directory history from what information has changed at what time, by whom, through what event, as well as what meaningful events to this object occurred during its lifecycle. - In this example, in the
first version 612, the directory object only has theversion 1 of a subdirectory object, namely,DOO 617. At some point in time, the subdirectory object changed its name to WOO; thus, aversion 2 of the subdirectory object was created and is represented byreference number 618. In this example, the directory active object tracks its children's name; thus,version 2 ofFOO 613 was created to link to theversion 2 of thesubdirectory WOO 618. Onversion 3 ofFOO 614, a new file of the name GOO under the directory FOO was created. This is illustrated byreference numeral 619. The links, shown as dotted arrows, are references of the CHILDREN property of the directory object. As can be seen, these links allow active objects to build up object relationships or object hierarchy (e.g., a parent-child relationship). The result is a logical view of the directory data structure. To conserve data storage usage, the directory version pages may be combined into a table or a journal, and the table or journal may be stored in a physical storage unit. For simplicity, it should be appreciated that the above diagram does not show the complete subdirectory and file objects (for example, the anchor pages of the file and subdirectory objects are not shown). - ClsFile
- The ClsFile schema is defined for tracking the history of a file from a file system. This schema is used for protecting a file, and it allows for the recovery of the protected file to any point-in-time in the past.
- The properties of this object class preferably include the following:
Properties of clsFile Descriptions Non-versioned Properties: ID GUID of this object instance, also the GUID of this anchor page DataSourceParent GUID of its protection data source container DateTimeCreated Timestamp when this object is created (from the protected host) Creator The user ID of the creator DateTimeTerminated Timestamp when this object is deleted (from the protected host) AccessLog List of entries with timestamp, user id, and access mode. EventTags List of entries with event and timestamp. The event tags may be set by users for tracking purposes. FirstVersionID GUID of the first version LatestVersionID GUID of the latest version VersionCount Total number of versions Versioned Properties: ID The version GUID of this object also GUID of this page AnchorID The GUID of the anchor page (the ID of this object) PreviousVersionID The version GUID of the previous version NextVersionID The version GUID of the next version Parent GUID of parent object which can either be the data source container or a directory Name Name of this file at this version DateTimeModified Timestamp when the version is created (or when the modification occurs) ModifiedBy ID of a user who modified the file DateTimeEnded Timestamp when this version is ended (i.e., a new modification results in another version being created and an old version ended) Status Consistency, DMS checkpoint, suspect ACL Key or GUID to the access control list of this object Fingerprint A hash key of the entire content (e.g. MD5, SHA-1, CRC, or the like) Signatures A sequence of hash keys each generated from a contiguous chunk of the content Content The sparse index of this version. Sparse index is byte level reference to the binary content. Binary contents are in baseline binary pages and delta pages. Additional metadata and Information from the original document attributes - The above table is merely illustrative; other properties, such as a full path name, policies, and the like, may be included. As can be seen, the non-versioned properties preferably include a timestamp when the object is created, creator information, identification of access journal for forensic purposes, and event tags for tracking user events across time line. The versioned properties preferably include name, modification information, status, ACL, and content. Preferably, a new logical version is created when the name of the document changes, the content of the document changes, the ACL changes, document metadata or attributes change, or when the document is moved. When the document is deleted from the protected data source, the file object at the DMS is terminated with (DateTimeTerminated timestamped), and the last version ended.
-
FIG. 7 is an example of a DMS file object that stores data history of a file from an external host server according to the present invention. As described above, preferably the file object has ananchor page 710 for its non-versioned metadata. This example shows a file object with three versions (711, 712, and 713). The FirstVersionID and LatestVersionID properties from the anchor refer to the first and third version of the file. The AnchorID property on each version contains the GUID of its anchor page. The versions are connected into a double link list with the PreviousVersionID and NextVersionID properties on each version property set. In this example, each version has an ACL property that refers to the access control list. Each version page also has a pair of timestamps, DateTimeModified and DateTimeEnded, to indicate when the version becomes existent and when the version is ended and a new version born. There is also a ModifiedBy property to capture the user who modifies the file. When a file is deleted, the DateTimeEnded property on the last version page and the DateTimeTerminate property in the anchor page are set to the deletion date. The File version is created when a file is modified and ended when the file is closed. - In the DMS file object, preferably each version has an associated property called “CONTENT,” and this property is of the type random access binary blob. The binary value of this property type may be stored inside or outside of the metadata page. In this example, the binary data of
version 1 is in thebinary page 716, which has its own GUID. The changes (deltas) that are made to the file forversion 2 are stored as a sequence of forward deltas in thedelta page 717. The changes (deltas) ofversion 3 are appended to thesame delta page 717 or another new delta page. A file object may have one or multiple binary pages. The binary pages contain the baseline data. A file object also may have one or multiple delta pages for all its changes. The sparse index refers to the data in both the baseline and the deltas to make up the content for the version. The binary and delta pages may be stored in one physical storage unit; alternatively, the pages may be broken up and stored in multiple physical storage units. As one of ordinary skill will appreciate, the above-described example is simply one way in which DMS structures the binary data. Alternatively, each version may have its own binary pages so that no delta has to be kept. Yet another alternative is to store reverse deltas or multiple baselines at different versions with a combination of reverse and forward deltas. - This file object structure and the associated metadata allows DMS to track a file history, e.g., what information has changed at what time, by whom, through what event, and what meaningful events to this object occurred during the object's lifecycle. To conserve data storage usage, preferably the metadata of the version pages may be combined into a table or a journal, and preferably the table or journal may be stored in a physical storage unit. Also, this structure can be stored over a raw storage device, or by overlaying a file system or a database.
- Although not a limitation of the invention, the file object may also optimize storage usage through a sparse index, as more particularly described in Ser. No. 10/943,541, filed Sep. 17, 2004, which application is incorporated herein by reference.
- History of Protected File System
-
FIG. 8 shows a sample file system history captured by the DMS according to the present invention. For simplicity, only the version metadata pages are shown; the anchor pages and the ACL pages are omitted. As mentioned above, when a newer version of a file or directory is created, preferably the older version is terminated. Therefore, as indicated. each version preferably has a DateTimeModified and DateTimeEnded. The DateTimeEnded of the latest version is NULL (i.e., not ended yet). - In this example, it is assumed that the entire file system is uploaded to the DMS for protection from a host server at T1. This is represented by FSDS 801 (DataSource 1). At T1, there is a
version 1 of thedirectories files - At T2, the content of the file by the name “fo1” changed, which is represented by the
new object 842. Because this is a content change, the parent “do1” v1 (reference numeral 811) is unaffected. - At T3, the directory by the name “do2” changed its name to “dox” (as now indicated by object 822). Because in this example a directory also tracks the name of its children, this change causes parent “do1” (which has reference to this object) to also generate a
new version 812. - At T4, a new file by the name “fo3” is added to “do1” (as now indicated by object 831); thus, a third version of “do1” is generated as indicated by
reference 813. - As can be seen, within this DMS file system history, preferably there are version links, parent-child links (i.e., object relationships), as well as the data links to binary and delta pages (852, 843, 844). Therefore, this structure forms a three dimensional (3-D) object store. Navigating this object store enables DMS to identify the history and state of the
DataSource 1 at any point-in-time, as will be described in more detail below. - As mentioned in the above sections, physical structure of the object versions can be organized in any fashion to optimize for the storage usage at the DMS.
- As also mentioned, an alternate non object-oriented embodiment may be implemented with techniques that link and index the object versions, object relationships and data changes by applying a schema over a relational database, together with a set of processes (described below) that update the database according to the invention.
- File System Events and DMS Operations
- The above sections discuss the DMS logical object data structure for file system protection. The following sections discuss the functional behavior of file system protection in more detail.
- The present invention is directed to the end-to-end process (e.g., from host driver to active objects in one cluster, or from active objects in one cluster to active objects in another cluster) that changes the DMS logical object store structure when a file system history is captured. In particular, the present invention describes the processes involved in the storing of real-time history of a file system, and the use of the real-time history for any point-in-time recovery for guaranteed consistency. The DMS file system history structure changes are triggered by one or more events from file system, users, or applications.
- Thus, as illustrated in
FIG. 8 , DMS file system data source object (801) in a DMS cluster receives file system activities and other events, typically from a host driver that resides in a server or from another file system data source object that resides in another DMS cluster. If a data source receives a data stream directly from a host driver, it is providing a data protection service, and the data source/storage group in the DMS storage is a master data source. If a data source object receives a data stream from another data source object, the service is called data distribution, and the data source/storage group in the DMS storage is a replica. As described in Ser. No. 10/842,286, filed May 10, 2004, a file system data protection or data distribution stream contains real-time event journal of a file system. The file system event journal is a stream of file system events, metadata, and associated data. Metadata may include, for example, information such as who did what when. Typically, the events include OPEN, CLOSE, CREATE, DELETE, MOVE, RENAME, MODIFY (data, attributes or metadata such as ACL), DELTA APPLY, FLUSH, and CHECKPOINT. CREATE event results in new file system active object (version 1) being created. Host drivers (for data protection) or active objects in a source cluster (for data distribution) may accumulate changed data depending on the data type; host drivers send (either instantaneously or periodically) MODIFY and DELTA APPLY along with the data and metadata to the target DMS active objects. DELTA APPLY is used to send delta changes after delta reduction. For some data types, such as database log activities, the host driver does not perform delta reduction and does not accumulate changes; rather, the host driver instead forwards changes with MODIFY events as soon as the events are received. FLUSH, CLOSE, and CHECKPOINT each trigger all accumulated changes to be sent to the target DMS active objects through MODIFY and DELTA APPLY events. CLOSE and CHECKPOINT events result in an old version being terminated, and a new object version created. MOVE and RENAME re-locate or modify the name property of an active object version, and DELETE ends the life of an active object by setting a timestamp on DateTimeTerminated and ends the last version. - DMS Processes for File System
- The following sections describe the DMS (host driver and active object) processes and the associated data history structure changes in response to specific file system events. Illustrations of sample DMS file system history are shown for each case. For illustrative purposes,
FIG. 9 is the historical starting point of the sample file system. As can be seen, the history comprises first andsecond versions second versions second versions first version 951 of File-2. Binary and delta pages (952, 943 and 944) are also referenced. - Creation of a File or a Directory
- The creation of a file or a directory in the DMS file system history structure is initiated by a CREATE event captured by a DMS host driver operating to provide data protection, or by a similar event distributed from one data source to another data source. This function is illustrated in the process flow of
FIG. 10 . This method is implemented in software (a set of one or more program instructions) executable in one or more processors. In a data distribution scenario, the same event would be forwarded from the master DMS data source to another replicated DMS data source, which would cause an equivalent data structure change in the replica. For simplicity, the following paragraph describes the data protection scenario. - This process begins with the DMS host driver capturing a file or directory CREATE event at
step 1071. The host driver then issues an Object Create command to the associated DMS file system data source to create an active object with the following parameters—object class, parent path, object name, creation timestamp, owner, ACL, and other attributes. This isstep 1073. An object manager at the DMS handles the request for the DMS file system data source object by opening the parent active object and creating a new version thereof. This isstep 1075, and this operation has been described and illustrated above. The DateTimeEnded of the parent's previous version is set to T, and the DateTimeModified of its new version is set to T as well. The object manager also creates a new file or directory object with a first version and sets all the properties as necessary. This isstep 1077. The DateTimeCreated property in the anchor of the new object is set to T, as is the DateTimeModified property in the first version. Preferably, the state of the first version of this new object is temporarily set to SUSPECT, as it has not closed yet. Once the object is created, it is linked to its parent, preferably by adding its GUID to the CHILDREN property of its parent's latest version. This also occurs instep 1077. Thereafter, the parent object is closed and the new child handle remain open; this handle is passed over to the host driver, which can issue more updates to the new child. This isstep 1079. If any failures occur during the above-described steps of the process, the transaction is rolled back atstep 1081 and the host driver is notified; the host driver then performs a resynchronization on that object atstep 1084. The host driver keeps the child handle in an open handle list atstep 1083. If the new object is a file object, the host driver forwards data (via a MODIFY event) to the DMS file object handle and then closes the file handle to generate a consistent (State=CONSISTENT) version. At this point, the new object state is SUSPECT not CONSISTENT. - In the data distribution scenario, a master DMS data source object is forwarding events and a data stream to a target DMS replicated data source object. The process described in the flowchart of
FIG. 10 applies in this data distribution scenario as well; in that scenario, the host driver is replaced by a master DMS data source object in a first cluster, and the file system data source (FSDS) object is replaced by a target DMS replicated data source object in a second cluster. Otherwise, the operations are similar. -
FIG. 11 illustrates how a new file by the name “fo3” is created and added to the DMS file system data source shown inFIG. 9 . For simplicity again, the anchor page of the objects are not shown. An anchor page stores the permanent properties of an object, which properties do not changed over time. The creation of “fo3” results in new version of “do1” 1150 being created. The DateTimeEnded is set to T, and the DateTimeModified ofobject 1150 is also set to T. The anchor page (not shown in the diagram), version page 1151 (version 1), as well asbinary page 1152 for the new file object, are also created. The DateTimeCreated property in the anchor page (not shown) is set to T, as is the DateTimeModified property for theversion page 1151. The State property ofpage 1151 is set to SUSPECT temporarily (see the discussion below concerning closing a file for additional details). The GUID ofpage 1151 is added to the Children property inobject 1150, which links the parent-child relationship. The sparse index of the Content property refers to the content inbinary page 1152. If the new object added is a directory object, there is no binary page. - The following is a representative DMS file system object (file and directory) creation algorithm. This algorithm is associated with
steps FIG. 11 from the starting point inFIG. 9 .Event = CREATE Create (object A, in directory B, with metadata X, at time T) Where object A may be a file or a directory. Metadata includes creator, ACL, and so on. Open parent directory object B, which has n version. Create new version (n + 1) for object B, copy all the properties from version n. Set DateTimeModified (object B, version n + 1) = T, DateTimeEnded (object B, version n + 1) = NULL Set DateTimeEnded (object B, version n) = T. Create new object A, create 1 version. Set properties of A (anchor page and version 1 page) = metadata X.Set DateTimeCreated (object A, anchor) = T, DateTimeTerminated (object A, anchor) = NULL Set DateTimeModified (object A, version 1) = T, DateTimeEnded (object A, version 1) = NULL If object A is file, set State (object A, version 1) = Suspect Add object (A, version 1) to the property Children (object B, version n + 1) Set PARENT property of (A, version 1) to refer to (B, version n + 1) Open parent directory of object B. If B is the root, then the parent is the file system data source object (FSDS). Call this object C. Change the Children property of C at the latest version to refer to the new version of B*. Close object B and C (if C there is a C) Object A handle is left open for further updates. -
- This step is done to ensure that the live version (non-deleted and most current version) of a parent always refers to the most current version of the child. By doing so, the time stamped on DateTimeEnded of a directory version is always equal to or prior to the time stamped on DateTimeEnded of its children's version pages. This optimization simplifies navigating in both child-parent and time dimensions.
- The above algorithm is merely representative of the steps that may be used to transform the logical representation of
FIG. 9 to that shown inFIG. 11 in response to CREATE events. Because the logical representation can be structured in many different ways, however, the algorithm for maintaining such different structures may vary accordingly. For example, as noted above the logical representation can overlay a relational database, or the logical representation may overlay a file system or even raw storage blocks (in effect such that there are only virtual version pages). In embodiments where the version pages are, in effect, virtual, the version pages may be constructed as needed, and information necessary for constructing the version pages may be stored as a journal or in any other form, such as in a file or raw storage blocks. - Modification of a File or a Directory
- A file or a directory modification in the DMS object store preferably is represented by the creation of a new object version. The modification of a file system object preferably is broken into three phases, and each phase involves a set of events. The three phases of active object modification cycle are (1) instantiating an active object, (2) modifying the object properties, and (3) freezing the version.
FIG. 12 illustrates a process flow that is implemented (e.g., in software) to modify a file or a directory in a master data source operating in data protection scenario. Similar object store changes occur when the same events are forwarded from a master data source to a replicated data source in the data distribution scenario. - As noted above,
phase 1 is instantiation of the target active object, which can either be a CREATE (as inFIG. 11 ) or an OPEN process, as represented byblock 1201. Thus, instantiating an active object can be initiated by a CREATE event or an OPEN (write mode) event. When a CREATE event is received, a new object with the first version is created in the object store. The object handle remains open for further update until the target DMS active object is explicitly closed, e.g., in response to events to freeze the object version.FIG. 11 described the process for creating a file or directory. When a DMS host driver captures a file system OPEN event to update a file or a directory at step 1202, it issues an Object Open request to the associated file system data source active object. This is step 1203. When the DMS active object is opened, its handle is returned to the host driver at step 1205. The flow sub-diagram (in block 1201) describes the object open process in response to OPEN event. The host driver sends to DMS the timestamp when a file system object is created or opened; the timestamp is used for stamping on the DateTimeEnded property of the previous version of the target DMS object, and on the DateTimeModified property of the new version created. -
Phase 2 is the actual modification of the target object, which occurs either inblock 1225 or inblock 1209. The events that modify object properties preferably include MODIFY (metadata) and WRITE (binary data). There may be many more modification events depending on the application and system to which the DMS is applied. The test atstep 1208 determines which event has occurred. A MODIFY event changes file system object metadata (such as access control list (ACL), object title, company name, document statistics and other user defined properties) that is associated with a file system object. The flow sub-diagram atblock 1225 describes the process to modify object metadata. In particular, in response to capture of the modification event (steps 1207 and 1208), atstep 1226 the host driver issues an object MODIFY event to the target active object (via the opened object handle) at the DMS, which target object then changes the object property in the latest object version atstep 1227. - The WRITE event is for file object only; it represents binary content updates. In this path, when host driver captures the WRITE event (
steps 1207 1208), it enters theprocessing block 1209 in the file modification process. Host driver first decides if it should buffer the changes. This isstep 1210. For a database log file, for example, the host driver would not buffer the log entries; however, when dealing with a regular document changes are buffered. If changes are buffered, then the host driver decides if it is time to forward the changes to the DMS target active file object. This isstep 1211. If no data should be forwarded at the meantime, the host driver continues to watch for events atstep 1207. Otherwise, the host driver decides if delta reduction should be applied on the changes to extract the actual changed byte range. This isstep 1212. Again, for database log entries, delta reduction is not necessary because log entries are appended onto the file. If no delta reduction is necessary, the changed data is packaged with a WRITE event and forwarded to the DMS target active object. This isstep 1213. Otherwise, the host driver retrieves the last binary content signatures and, for one or more byte ranges that actually changed (deltas), the host driver calculates and forwards those deltas to the DMS target object. This is done using a host driver-generated (namely, APPLYDELTA) event and occurs atstep 1214. The target DMS file object receives both WRITE and APPLYDELTA events, applies second stage delta reduction as necessary to extract the exact bytes changed, saves the deltas or binary data in the binary or delta pages, and then creates or updates the sparse index in the working (last) object version. This isstep 1215. If the file has not been closed, the host driver continues to capture more modification events for the file atstep 1207; otherwise, the closing process continues, which isstep 1222. If any failure occurs, the host driver abandons all the events associated with the target file and performs resynchronization of the entire object atstep 1230. In the preferred embodiment, the host driver uses a FLUSH event as one of the events to decide if buffered data should be forwarded to the DMS without causing the DMS target object to generate new version. -
Phase 3 freezes the changes into an object version. This is block 1221. The possible events that cause a DMS target file or directory active object to freeze the latest object version (and thus to prevent any more changes into that version) are CLOSE, CHECKPOINT, and FORCE-CLOSE. The flow diagram in block 1221 illustrates the processing of handling of these events to freeze a DMS active file or directory object version. A CLOSE is a file system event. When this event is detected by the host driver, the associated file is consistent. A CHECKPOINT may be generated by an application with or without user initiative, or it may be generated by the host driver. A CHECKPOINT event is generated when the associated application or the host driver have taken some appropriate action to ensure that the version to be frozen is consistent in its application point of view. For example, a database manager periodically flushes its memory and generates an internal CHECKPOINT, during which a set of database files are consistent. The CHECKPOINT event from a database manager can be detected by the host driver, which indicates that the group of files belonging to the particular database is consistent and a DMS version of each of the files should be frozen. In yet another example, an application or the host driver may generate a CHECKPOINT to all the system state files (or even the entire file system) to create a snapshot of all the files all at once (an exact time). This CHECKPOINT forces all the related files to freeze their latest version all at once. If a CLOSE or CHECKPOINT event is detected by the host driver atstep 1208, the host driver checks if there is any buffered data for that object. This isstep 1220. If so, the host driver first forces the data to be forwarded to the target DMS object. After that, the host driver forwards the event to the DMS target object. This isstep 1222. Both CLOSE and CHECKPOINT events generate a consistent DMS object version with the State property of the frozen version set to “Consistent.” This isstep 1223. - As noted above, another event that freezes a file or a directory object is FORCE-CLOSE. This event may be generated by an application or the host driver itself (step 1207), or it can be generated by the DMS (step 1225) when an error is encountered. The error could be that the host driver connection to the DMS has failed. The FORCE-CLOSE event generated by an application or host driver goes through the same process as the CLOSE and CHECKPOINT events (
steps step 1223. Any DMS object that ends with Suspect state is eventually resynchronized with its corresponding file system object in the host, which isstep 1230. - In one embodiment, the DMS data source object automatically creates a new object version when it handles a CREATE or OPEN event. In this case,
step 1223 involves freeing an unmodified object version. An alternate embodiment forces the DMS data source object to create a new object version when it receives the first modification event. - The above described process with respect to the given events is merely illustrative. Other events and/or other handling techniques may be implemented. Thus, e.g., an alternative embodiment may choose to freeze file system objects more frequently (by using events such as FLUSH or possibly the WRITE events with TIMEOUT in step 1221). Another embodiment includes other application and host driver generated events, such as AUTO-SAVE. Also, with alternate embodiments, the process may be somewhat different than as illustrated in
FIG. 12 . For example, if a relational database is used to store the logical representation, the object-oriented behavior (with object methods/functions) would not be required. - In the data distribution scenario as noted above, a master DMS data source object is forwarding events and a data stream to a target DMS replicated data source object. The process described in
FIG. 12 applies in this data distribution scenario as well. In particular, the host driver is replaced by a master DMS data source object in a first cluster, and the DMS file system data source object (FSDS) and DMS objects are replaced by a target DMS replicated objects in a second cluster. -
FIG. 13 illustrates how modifying a directory object alters the DMS object store ofFIG. 11 .FIG. 14 illustrates how modifying a file object alters the DMS object store ofFIG. 13 . - In particular,
FIG. 13 illustrates the modification of an ACL onversion 3 of the Dir-1 directory object, which wasobject 1150 inFIG. 11 . Once again, for simplicity the anchor page of all objects is not shown. In this case, a new version (object 1350) of “do1” is created with its ACL property changed; other properties, such as the children links, remain unchanged. In other words, both version 4 (object 1350) and version 3 (object 1150) refer to the same version of their children. Suppose the ACL of “do1” is modified at T2, in such case, T2 would be stamped on the DateTimeEnded property of version 3 (object 1150), and on the DateTimeModified property of version 4 (object 1350) of the directory “do1.” After thenew version 1350 is created, the parent of “do1, in thiscase object 901, is modified to refer to the new version. -
FIG. 14 illustrates the modification of a file object (labeled 1151 inFIG. 11 ), onFIG. 13 whose content is modified. Note thatFIG. 13 is derived fromFIG. 11 as a result of a change to “do1.” This file object modification generates a new version of File-3, which is represented asobject 1460. In this case, the deltas of the modification are saved in a delta page (object 1461) or in the binary page (object 1152) associated with the prior version. Preferably, the sparse index in version 2 (object 1460) refers to the byte ranges in both the binary and delta pages for theversion 2 content. Suppose the file “fo3” is modified on T3, in such case T3 is stamped on the DateTimeEnded property of version 1 (object 1151) and on the DateTimeModified property of version 2 (object 1460). Because the content change to “fo3” does not affect directory “do1,” no new version is created.Version 4 of “do1” continues after T3, however, thus note that the child link to “fo3” (object 1150) is changed to refer to version 2 (object 1460) of “fo3” instead of version 1 (object 1151). This reflects the fact that, at the current point-in-time, the information of “do1” is in its V4 and that from there, the current point-in-time “fo3” can be located. - The following is a representative DMS file system object (file and directory) modification algorithm for implementing the object store changes described and illustrated above.
Phase 1: Events = CREATE, OPEN. Create (object A, in directory B, with metadata X, at time T) Open (object A, write mode, at time T) (step 1205) 1. Open object A, which has m version. 2. Create new version (m + 1) for object A, copy all the properties from version m. 3. Set DateTimeModified (object A, version m + 1) = T, DateTimeEnded (object A, version m + 1) = NULL 4. Set DateTimeEnded (object A, version m) = T. 5. If object A is file, set State (object A, version 1) = Suspect 6. Open parent of object A, and change the child link to this latest version (m + 1) of A. Phase 2: Events = WRITE, MODIFY, APPLYDELTA (may repeat multiple times) If FLUSH is used in phase 2, it simply triggers execution ofphase 2 as if there is a zerolength WRITE, which forces the accumulated changes to be recorded on DMS. Modify (object A, property = value) (step 1227) 1. Set property (object A, version m + 1) = value Write (object A, content = (offset, length, data)) (step 1215) ApplyDelta (object A, content = delta string) 1. If first version or if there is no need for delta reduction, write to binary page 2. otherwise, 2nd stage delta reduction, write to delta page 3. Update sparse index of object A, version m + 1 Phase 3: Events = CLOSE, CHECKPOINT, and FORCECLOSE. FLUSH may be applied. (Step 1223) Close (object A) Checkpoint (object A) 1. if file, set state (object A, version m + 1) = Consistent 2. close the object A and its parent object ForceClose (object A) 1. Close object A and its parent object (in this case state remains Suspect). - Deletion of a File or a Directory
-
FIG. 15 illustrates a process for deleting a file or a directory in the DMS file system history structure. This process is initiated by a DELETE event captured by a DMS host driver operating in the data protection scenario. In the data distribution scenario, the same event is forwarded from the master DMS data source to another replicated DMS data source, which causes equivalent data structure changes in the replica. The following section describes the data protection scenario. -
FIG. 15 begins with the DMS host driver capturing a DELETE event for a file or a directory. This isstep 1501. The event is forwarded to the file system data source active object, together with the target object name and timestamp T. This isstep 1503. The file system data source object then begins a transaction for the modification of properties in both the target object and its parent. In particular, on behalf of the file system data source object, the object manager opens the parent of the target DMS object and creates a new object version for the parent. The DateTimeEnded property of the previous version of the parent object is set to T, while the DateTimeModified property of the new version is also set to T. This isstep 1505. Thereafter, the target object is instantiated, and both the DateTimeTerminated anchor property and DateTimeEnded property at the latest version page are set to T. This isstep 1507. The next step is to remove from the latest parent version page the child reference to the target object. This also occurs instep 1507. Once the process is completed, the transaction is committed atstep 1509. Any failure results in rolling back the transaction (step 1511) and complete resynchronization of the target object between the host and the DMS (step 1515).Step 1513 illustrates that the process has succeeded. - In a data distribution scenario, as described above a master DMS data source object forwards events and the data stream to a target DMS replicated data source object. The process described
FIG. 15 applies in this scenario as well. In particular, the host driver is replaced by a master DMS data source object in a first cluster, and the file system data source (FSDS) object is replaced by a target DMS replicated data source object in a second cluster. -
FIG. 16 illustrates the deletion of a file object “fo1” 942 from the file system data source inFIG. 14 . Once again, the anchor pages of the objects are not shown. Atversion 4, “do1” (object 1350) has three children, namely “dox” v2, “fo1” v2, and “fo3” v2. When the DELETE event (to remove “fo1”) is detected at time T4, a new version of do1's parent is created, and this new version isobject 1650. This new version has its reference to “fo1” removed so that it is no longer linked to the deleted child. The DateTimeEnded property ofobject 1350 is set to time T4 and the DateTimeModified property ofobject 1650 is also set to T4. - In the “fo1” file object, the DateTimeTerminated property in the anchor page (not shown) is set to T4 to indicate that the object does not exist beyond T4. The latest version of “fo1,” which is version 2 (object 942) is ended by its DateTimeEnded property set to T4. As can be seen, preferably the object “fo1” does not get removed physically from the DMS object store when it is deleted. Instead, its history terminates at T4. Preferably, the DMS object store keeps growing its history until a user explicitly prunes the history, either manually or via retention policy, during which older versions of the active objects get dropped off at the tail end.
- Although
FIG. 16 shows the deletion of a file, the DMS file system history changes are similar when a directory object is deleted. In particular, a version is added to the parent directory of the target directory with the link between the parent and the target removed, and the target directory is terminated (in the same manner as if a target file object is terminated as illustrated). In deleting a directory, all the directory children should be terminated at once. In particular, the process traverses down the children of the directory object, sets the DateTimeTerminated property (at each anchor page of each child) to the time when the target directory is deleted, and sets the DateTimeEnded property at the latest version page (of all the children) to the same termination timestamp. - The following is a representative DMS file system object (file and directory) deletion algorithm for implementing the object store changes described and illustrated above.
Event = DELETE Delete (object A, at time T) ( steps 1505, 1507)Where object A may be a file or a directory. Open parent directory object B, which has n version. Create new version (n + 1) for object B, copy all the properties from version n. Set DateTimeModified (object B, version n + 1) = T, DateTimeEnded (object B, version n + 1) = NULL Set DateTimeEnded (object B, version n) = T. Open parent of object B, change the child reference of the latest version to refer to version n + 1 of B. Open object A, which has m version Set DateTimeTerminated of A (anchor page) = T. Set DateTimeEnded (object A, m) = T If object A is directory, traverse all its children. For all its children, open them, set DateTimeTerminated (all its children's anchor page) = T, and set Date TimeEnded (all its children's latest version page) = T. Remove object A from property Children (object B, version n + 1) Close all the objects - Relocating or renaming a File or a Directory
- In this section, renaming a file system object refers to changing the name of the object without moving it away from its directory. While relocating a file system object refers to moving an object from one directory to another different directory, the name of the object may also change during relocation. Relocation is a superset of renaming; one can relocate from within the same directory for changing an object's name path. In either case, the destination name either of the rename or relocate operation may already exist and be used by another object, in which case the original destination object is deleted and the target object to be renamed or relocated takes over the destination name.
- In some file systems, a MOVE event is used for both renaming a file system object (file or directory) as well as relocating (moving) a file system object from one directory to another. In other file systems, a RENAME event may be used for both renaming and relocating of a file system object. There are also file systems where a MOVE event is used for relocating file system objects while a RENAME event is used for re-labeling (renaming) file system objects. In one embodiment of this invention, both MOVE and RENAME events are treated the same, in other words, both events initiate renaming and relocating of file system objects.
-
FIG. 17 is a flow diagram illustrating a process of moving a file or a directory according to the invention. Typically, the process involves a host driver capturing a MOVE or a RENAME event (at step 1701), and passing the event to the DMS file system data source object (at step 1703). The DMS file system data source object then opens the target object (and its parent object(s)) to handle the event. This isstep 1705. DMS handling of a MOVE or RENAME event occurs atsteps step 1707 does not fail, the transaction is committed atstep 1709.Step 1713 indicates a success. If, however, a failure occurs during the renaming or relocation process, object resynchronization is performed atstep 1711. - As described previously, in the data distribution scenario the host driver in the process flow is replaced by a master DMS file system data source, and the DMS file system data source is a replication data source. Otherwise, the process flow in
FIG. 17 is identical. -
FIG. 18 shows DMS data structure changes when a file is renamed and a parent object does not track a child object name;FIG. 19 shows DMS data structure changes when the file is renamed and parent object does track child object name. In both cases the resulting data structures illustrated are built from the data structure inFIG. 16 . As before, no anchor pages are shown in the diagrams to simplify the representation. In a rename operation, the target file system object does not move from one parent to another; thus, the process (corresponding tosteps FIG. 17 ) is relatively straightforward. In such case, the target object is opened, a new version is created with the given timestamp T (i.e., the old version DateTimeEnded property as well as the new version DateTimeModified property are set to T), and the NAME property in the new version is changed to the new name. The new version isobject 1850, which is seen inFIG. 18 . If object name is not tracked (in the CHILDREN property of the parent directory), the CHILDREN property link (of the last version of the new object's parent) is changed to refer to the new object version (see,objects 1650 and 1850). If, however, object name is tracked in the parent's CHILDREN property, the parent object is opened, and once again a new version of the parent is created. In this case, however, the new version is seen asobject 1951 inFIG. 19 . Here, the new object name is changed on the CHILDREN property of the new parent version. This process is the same regardless of the whether the target object is a file or a directory. In the two examples (FIGS. 18 and 19 ), the destination name “foz” does not exist before the rename. In the event “foz” already exists and is owned by another object, a relocate process is used instead of the rename operation. - The following is a representative rename algorithm for use in the present invention. As noted above, the file system may use a MOVE or RENAME event to rename a file or a directory object.
Event = MOVE or RENAME Rename (object A, old name, new name, at time T) ( Step 1705, 1707)Where object A may be a file or a directory. Open object A which has m version. Create a new version (m + 1). Copy all properties of m to m + 1. Set DateTimeEnded (object A, version m) = T. Set DateTimeModified (object A, version m + 1) = T, DateTimeEnded (object A, version m + 1) = NULL Open parent directory (object B which has n versions) of object A. If Object B does not track child name, simply change its child reference to (m + 1). ( FIG. 18 )If Object B does track child name, create new version (n + 1) for object B, copy all the properties from version n. ( FIG. 19 )Set DateTimeModified (object B, version n + 1) = T, DateTimeEnded (object B, version n + 1) = NULL Set DateTimeEnded (object B, version n) = T. Change child reference of version (n + 1) to object A (m + 1). Open parent of object B, change the child reference of the latest version to refer to version n + 1 of B. Close all the objects -
FIGS. 20 and 21 show DMS object structure changes associated with relocating a file object. For convenience, bothFIGS. 20 and 21 are built upon the data structure that remains inFIG. 19 . This is not a limitation of the invention. No anchor pages are shown in these diagrams to simplify the representation. According to this feature, there are two (2) different models for tracking history of file system object relocation, one (FIG. 20 ) is versioned by object instant while the other (FIG. 21 ) is versioned by path. - In
FIG. 20 (the versioned by object instant model), object versions are connected across the lifetime of the object regardless of where the object is relocated. Thus, with reference toFIG. 20 , for example, when “fo2” relocated from “dox” to “do1,” new versions of the affected objects are created. This results in the following new versions: (2055 “fo2” v2), (2054 “dox” v3) and (2053 “do1” v7). The DateTimeModified property of these new versions is set to the time when “fo2” is relocated, and the DateTimeEnded property of the new versions is set to NULL. The DateTimeEnded property of the previous versions is set to the relocation time of “fo2.” The most current version of the parent-child link (CHILDREN property) for both “dox” and “do1” are fixed (with FSDS referring toobject 2053, andobject 2053 referring to object 2054). The parent-child link (object 2054 to object 2055) from “dox” to “fo2” is removed, and parent-child link (object 2053 to object 2055) from “do1” to “fo2” is connected via CHILDREN property inobject 2053. In this model, although “fo2” is relocated, its history continues to connect (via VERSION property) back to when it was a child under “dox” (object 2055 and object 951 are connected, andobject 2055 is v2 and object 951 is v1). In this case, where an object already exists that owns the destination pathname, the object is terminated (deleted). - In
FIG. 21 (the versioned by object path model), object versions are only connected when the object is in the same directory container (i.e., the same parent pathname). When the same object is moved out of the container, a new one is born on the new container, and the old one from the old container is terminated. InFIG. 21 , for example, when “fo2” is relocated from “dox” to “do1,” a new version of “dox” (object 2157) and a new version of “do1” (object 2156) are created. The parent of “do1,” whichFSDS 901 is now referring to “do1” v7 (object 2156), and the parent of“dox,” which is “do1” v7 (2156), is now referring to “dox” v3 (object 2157). In this model, because object versions are connected only if their path does not change, the path of “fo2” is changed from “\do1\dox\fo2” to “\do1\fo2”; thus, a new object (not version) with first version is created. This is illustrated asobject 2158, “fo2” v1. Because this is a new object and has nothing to do with the old one, there is no connection betweenobject 2158 and object 951 (as was the case in theFIG. 20 embodiment). The old “fo2” object (object 951) is “deleted” or “terminated” by having its DateTimeTerminated anchor property set to the object relocation time, and its DateTimeEnded property in the latest version also set to object relocation time. Becauseobjects binary page 952. - In the versioned by object path model of
FIG. 21 , there are two variants of history management structure. These two variants of structure depend on if there exists a file object of the same name in the destination in the timeline. In either case, if an object of the same name already exists in the destination and is still active, the destination object is terminated (deleted). In one variant, indicated byreference numeral 980 inFIG. 22 , all objects stand alone and are not connected to the past “deceased” objects. In this example, “f1” is moved into “dir1” at T4. As seen in the drawing, in the past a completely different object of the name “f1” existed; the former object was created at T1, modified at T2, and deleted/terminated at T3. Invariant 980, the newly arriving has a new anchor page and afirst version page 996 that has nothing to do withobject 995. In this structure, if one were to take a snapshot at T4, “f1” would be seen to have only one version. In a second variant, indicated byreference numeral 981 inFIG. 22 , objects of the same name in the same path are always connected in versions and share the same anchor page as if they are the same object. For example, in thisvariant 981, “f1” (object 999) is moved into “dir1” at T4; back before T3, an object of the same name existed but was terminated. In this case, the old object is re-born; its DateTimeTerminated atobject 992 is reset from T3 to NULL. No new object is created; instead, a new version page (object 999) is created for the old object to fit in the new file. The DateTimeEnded ofobject 998 is set to T3 and the DateTimeModified ofobject 999 is set to T4, so there is a version time gap during which the file never existed. At T4, in this case, there are three versions of “f1” in the entire history. - A representative file object relocation algorithm is set forth below:
Event = MOVE or RENAME RelocateFile (File A, old path, new path, at time T) ( Step 1705, 1707)Open current parent of A, P1, using the old path. P1 has k versions. Create a new version (k + 1) and copy all the properties of k to (k + 1). Set DateTimeEnded (P1, version k) = T. Set DateTimeModified (P1, version k + 1) = T, DateTimeEnded (P1, version k + 1) = NULL Remove A from CHILDREN property (P1, version k + 1) Change CHILDREN property in latest version of parent of P1 to refer to (k + 1). If new parent of A is not the same as its current parent, do the following: otherwise, P2 is the same as P1: Open new parent of A, P2, using the new path. P2 has i versions. Create a new version (i + 1) and copy all the properties of i to (i + 1). Set DateTimeEnded (P2, version i) = T. Set DateTimeModified (P2, version i + 1) = T, DateTimeEnded (P2, version i + 1) = NULL Change CHILDREN property in latest version of parent of P2 to refer to (i + 1). If an object existed in the new path (call it Z with r number of version), terminate it by setting DateTimeEnded (Z, version r) = T, and DateTimeTerminated (Z, anchor) = T. Remove version r of Z from the parent (P1) CHILDREN list. If versioned by object instant ( FIG. 21 )Open file object A which has m version. Create a new version (m + 1). Copy all properties of m to m + 1. Set DateTimeEnded (A, version m) = T Set DateTimeModified (A, version m + 1) = T, DateTimeEnded (A, version m + 1) = NULL Set Name (A, version m + 1) if name is to be changed as well Add Object (A, version m + 1) to CHILDREN property of (P2, version i + 1). Set PARENT property of (A, version m + 1) to (P2, version i + 1) If versioned by object path without connecting to dead object ( FIG. 20 , andvariant 980 ofFIG. 22 )Create new object C with version 1.Open file object A which has m version. Copy properties (object A, version m) to properties (object C, version 1) —this copies over the sparse index so that the binary and delta pages can be shared. Set DateTimeCreated (object C, anchor) = T, DateTimeTerminated (object C, anchor) = NULL, DateTimeModified (Object C, version 1) = T, DateTimeEnded (Object C, version 1) = NULL Set Name (C, version 1) if name is to be changed as well Set DateTimeTerminated (Object A, anchor) = T, DateTimeEnded (Object A, version m) = T. Add Object (C, version 1) to CHILDREN property of (P2, version i + 1). Set PARENT property (C, version 1) to (P2, version i + 1) If versioned by object path and connecting to dead object ( FIG. 21 , andvariant 981 ofFIG. 22 )Open object C which is a dead object in the new path with the same final name as object A. Object C has n version. Create n + 1 version. Open file object A which has m version. Copy properties (object A, version m) to properties (object C, version n + 1) —this copies over the sparse index so that the binary and delta pages can be shared. Set DateTimeTerminated (object C, anchor) = NULL, DateTimeModified (Object C, version n + 1) = T, DateTimeEnded (Object C, version n + 1) = NULL Set Name (C, version n + 1) if name is to be changed as well Set DateTimeTerminated (Object A, anchor) = T, DateTimeEnded (Object A, version m) = T. Add Object (C, version n + 1) to CHILDREN property of (P2, version i + 1). Set PARENT property of (C, version n + 1) to (P2, version i + 1). Close all the objects. - The algorithm set forth above shows relocation of an object within a protected file system or folder (i.e., moving from a sub-folder to another sub-folder within a protected file system tree). When an object is relocated from a protected area to an unprotected are (e.g., outside of the protected file system), the handling process is similar to DELETE. This is because the object disappears from the protected area after the event. Conversely, when an object is moved from an unprotected area to a protected area, it is treated as a creation of a new object.
- The DMS may also include a temporary file handling process to minimize storage and bandwidth usage, e.g., by not transferring and storing potentially useless temporary files in the file system history. For example, Microsoft Word creates a temporary file when a Word document is modified. The updates are entered into a temporary file; upon a save event, the temporary file is renamed to the original file name. In this case, preferably creation and/or modification of the temporary file may be avoided; thus, preferably, only when the RENAME occurs is the above relocation process applied and object history linked together by pathname.
- The above algorithm implements relocation of a file object; relocation of a directory object is more complex, as a directory may have children. Similar to relocating a file, the history management of relocation of a directory can also be based on model 1 (versioned by object instance) or model 2 (versioned by path). Also, one may connect the relocated object with a dead historical object while versioned by path or without connecting the relocated object with the historical object.
-
FIGS. 23-26 illustrate the DMS data structure changes during relocation of a directory object. As in the previous examples, these figures do not show the object anchor pages.FIG. 23 illustrates a sample baseline structure.FIG. 24 illustrates a directory relocation based on versioned by object instance model usingFIG. 23 as the initial baseline.FIG. 25 illustrates a directory relocation based on versioned by object path model usingFIG. 23 as the initial baseline.FIG. 26 illustrates a directory relocation based on a combination of versioned by object path and versioned by object instance, again usingFIG. 23 as the initial baseline. - In
FIG. 24 , “dir4” is relocated from “dir2” to “dir3” using versioned by object instance model and figureFIG. 23 as the baseline. In this case, a new version of “dir2” is created (object 1031) and its CHILDREN property is modified such that it no-longer links to “dir4.” The DateTimeEnded ofobject 1005 and the DateTimeModified property ofobject 1031 are set to the time when “dir4” is relocated. The CHILDREN property of parent of “dir2,” which isversion 2 of “dir1” (object 1002), is adjusted to refer toobject 1031 instead ofobject 1005. Note that because there is no addition or deletion to “dir1,” there is no need to create a new version. A new version of “dir3” 1030 is created, its CHILDREN reference is added “dir4” version 3 (object 1032), and its DateTimeModified property is set to the time when “dir4” is relocated. The parent reference of “dir3” (which isversion 2 of “dir1” 1002) is also adjusted to refer toobject 1030. New version of “dir4” 1032 is created with the same CHILDREN reference as itsprevious version 1009; the NAME property and PARENT property ofobject 1032 is changed accordingly. Versioned by object instance for directory relocation is straightforward as the version of the children does not have to be adjusted (because the instance has not changed). -
FIG. 25 shows relocating of “dir4” from “dir2” to “dir3” using the versioned by object path model. As inFIG. 24 , new versions of “dir2” and “dir3” are created with their CHILDREN link, DateTimeModified property, and parent property adjusted accordingly. In this model, when the object “dir4” 1009 is moved, the last version (object) 1009 ended, and the object is terminated; a new object for “di43” is created that has its own anchor page and afirst version page 1042. All the descendents of “dir4”, namely objects 1010, 1013, and 1014, are also terminated and new corresponding objects (objects version 1, 1043) and “f3” (version 1, 1045) refer to the same binary and delta pages for shared content storage usage reduction. - As can be seen, the versioned by object path model has relatively high processing and storage cost when relocating a directory, although it is much simpler to traverse. The alternative is to have a versioned by object path and versioned by object instance hybrid as shown in
FIG. 26 . InFIG. 26 , “dir4” version 2 (object 1009) is terminated when it is relocated from “dir2” to dir3,” a new object “dir4” 1052 with a new anchor page and first version page is created. A new version is created for both “dir2” 1051 and “dir3” 1050, and their parent link is fixed. The new version of “dir3” (1050) refers toversion 1 of thenew object 1052, whileversion 3 of “dir2” (1051) no longer refers to “dir4.” New NAME property may be entered intoobject 1052 as relocation may also change the name of the directory. The descendents of “dir4” do not change in this case. - The following is a directory object relocating algorithm.
Event = MOVE or RENAME RelocateDirectory (directory A, old path, new path, at time T) ( Steps 1705, 1707)Open current parent of A, P1, using the old path. P1 has k versions. Create a new version (k + 1) and copy all the properties of k to (k + 1). Set DateTimeEnded (P1, version k) = T. Set DateTimeModified (P1, version k + 1) = T, DateTimeEnded (P1, version k + 1) = NULL Remove A from CHILDREN property (P1, version k + 1) Change CHILDREN property in latest version of parent of P1 to refer to (k + 1). If new parent of A is the same as the old one, then P2 = P1, otherwise, do the following: Open new parent of A, P2, using the new path. P2 has i versions. Create a new version (i + 1) and copy all the properties of i to (i + 1). Set DateTimeEnded (P2, version i) = T. Set DateTimeModified (P2, version i + 1) = T, DateTimeEnded (P2, version i + 1) = NULL Change CHILDREN property in latest version of parent of P2 to refer to (i + 1). If an object already owns the new path name, open that object to terminate it. Remove the object version page from P2. If versioned by object instant ( FIG. 24 )Open directory object A which has m version. Create a new version (m + 1). Copy all properties of m to m + 1. Set DateTimeEnded (A, version m) = T Set DateTimeModified (A, version m + 1) = T, DateTimeEnded (A, version m + 1) = NULL Set Name (A, version m + 1) if name is to be changed as well Add Object (A, version m + 1) to CHILDREN property of (P2, version i + 1). Set PARENT property of A to refer to (P2, version i + 1). If versioned by combination of object path and object instance and do not connect to dead object ( FIG. 26 )Create new object C with version 1.Open directory object A which has m version. Copy properties (object A, version m) to properties (object C, version 1) —this copies over all the children links. Set DateTimeCreated (object C, anchor) = T, DateTimeTerminated (object C, anchor) = NULL, DateTimeModified (Object C, version 1) = T, DateTimeEnded (Object C, version 1) = NULL Set Name (C, version 1) if name is to be changed as well Set DateTimeTerminated (Object A, anchor) = T, DateTimeEnded (Object A, version m) = T. Add Object (C, version 1) to CHILDREN property of (P2, version i + 1). Set PARENT property of C to refer to (P2, version i + 1). If versioned by object path without connecting to dead object ( FIG. 25 )Perform object close for directory A. Traverse to all the descendents of directory A, terminate all the descendent using relocate with versioned by object path method. For each of the descendent, terminate the old one, create a new object with version 1, reset the parent-child link to connectthe new child ( version 1 of child) to the new parent (version 1 of parent).Close all the objects. - The above algorithm only illustrates the process to relocate a directory object from a sub-folder to another sub-folder, all within a protected file system. In the event a directory is relocated outside of the protected file system, the process is the same as that for deleting the direct object (i.e., the same process for a DELETE event). In the event a directory is relocated from an unprotected file system to a protected file system, the process is similar triggered by a CREATE event as has been described above.
- The present invention has been described by a set of example data structures, but this is not a limitation of the present invention. Thus, while is has been convenient to explain the various file and directory object algorithms (create, modify, delete, rename and relocate) by reference to a continuous sequence of sample data structures, these algorithms may be used with any object store as the starting or baseline data structure.
- As one of ordinary skill in the art will appreciate, the present invention addresses enterprise data protection and data management problems by continuously protecting all data changes and transactions in real time across local and wide area networks. Preferably, and as illustrated in
FIG. 1 , the method and system of the invention take advantage of inexpensive, commodity processors to efficiently parallel process and route application-aware data changes between applications and low cost near storage. - While the present invention has been described in the context of a method or process, the present invention also relates to apparatus for performing the operations herein. As described above, this apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
- While the above written description also describes a particular order of operations performed by certain embodiments of the invention, it should be understood that such order is exemplary, as alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, or the like. References in the specification to a given embodiment indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic.
- Although different data services have been described, it should be appreciated that one advantage of the present invention is that a given DMS appliance can provide one or more such services. It is a particular advantage that a given appliance can provide a consolidated set of data services on behalf of a particular data source. As has been described, this operation is facilitated through the provision of the host driver, which captures, as a data history, an application-aware data stream. The application-aware data stream typically comprises data change(s), events associated with the data change(s), and metadata associated with the data change(s). As has been described, this information is streamed continuously to the appliance (or to a set of cooperating appliances) to facilitate provision by the appliance of the desired service(s).
- As noted above, it is not required that the present invention be implemented in an “object-oriented” manner, even though it is one preferred implementation to do so. As described above, the invention may be implemented in a non object-oriented manner, e.g., by overlaying the logical representation over other data storage such as a relational database. Thus, as used herein, an “object” is not limited to a construct that is used solely in an “object-oriented” implementation but should be construed broadly. Thus, in the context of a relational database implementation, an “object” may be represented by a row of data from one or more relational database tables, and an associated “link” may simply be a reference from one row to another row (e.g., a data row address or the like).
Claims (23)
1. A data management method, comprising:
storing a real-time history of a data set, or a component thereof, as a logical representation, the data set having a hierarchical data structure, wherein the logical representation comprises at least a set of version metadata objects, and a set of one or more links that associate given objects of the set of version metadata objects; and
reconstituting the logical representation in response to a new event in the real-time history.
2. The data management method as described in claim 1 wherein the data set having a hierarchical data structure is a file system.
3. The data management method as described in claim 2 wherein the component is a component of the file system and is one of: a directory, and a file.
4. The data management method as described in claim 1 wherein the set of one or more links comprise at least one of: a version link, a parent-child link, and a data link.
5. The data management method as described in claim 2 wherein the new event is one of: a file create, a file modify, a file delete, a file rename, and a file relocate.
6. The data management method as described in claim 1 wherein the new event is one of: a directory create, a directory modify, a directory delete, a directory rename, and a directory relocate.
7. The data management method as described in claim 1 wherein the logical representation is n-dimensional.
8. The data management method as described in claim 1 wherein the set of version metadata objects conform to an object hierarchy.
9. The data management method as described in claim 8 wherein the object hierarchy comprises a set of data objects, wherein each data object in the set of data objects conforms to a given schema.
10. The data management method as described in claim 9 wherein the given schema includes at least one of: a directory class schema, and a file class schema.
11. The data management method as described in claim 1 further including:
generating the real-time history; and
transferring the real-time history from a first location to a second location remote from the first location.
12. The data management method as described in claim 11 wherein the first location is a data source having an associated host driver and the second location is a data store.
13. The data management method as described in claim 12 wherein the real-time history provides a data protection service.
14. The data management method as described in claim 11 wherein the first location is a first data store and the second location is a second data store.
15. The data management method as described in claim 14 wherein the real-time history provides a data distribution service.
16. A data management method, comprising:
generating a real-time event data stream by capturing data changes associated with one or more events associated with a file system data source;
receiving the real-time event data stream at a given location remote from the file system data source; and
storing the real-time event data stream at the given location as a first n-dimensional logical representation, wherein the n-dimensional logical representation comprises a set of version objects, and a set of links associating at least first and second of the version objects.
17. The method as described in claim 16 further including:
deriving a second n-dimensional logical representation from the first n-dimensional logical representation in response to a given event in the real-time event data stream.
18. The data management method as described in claim 16 wherein the set of one or more links comprise at least one of: a version link, a parent-child link, and a data link.
19. The data management method as described in claim 16 wherein the file system data source is one of: a directory, and a file.
20. The data management method as described in claim 16 wherein the given event is one of: a file create, a file modify, a file delete, a file rename, and a file relocate.
21. The data management method as described in claim 16 wherein the given event is one of: a directory create, a directory modify, a directory delete, a directory rename, and a directory relocate.
22. A data structure supported in a data store, comprising:
a set of data objects each of which conform to an object hierarchy, at least first and second of the data objects being associated with one another and representing a first version of a file system component and a subsequent version of the file system component, the file system component being one of: a directory, and a file; and
a set of links associating the set of data objects, wherein the set of links comprise at least one version link associating the first version of the file system component and the subsequent version of the file system component;
wherein the set of data objects and the set of links provide an n-dimensional logical representation of the file system component at a given point-in-time.
23. The data management method as described in claim 1 wherein the new event is one of: a transaction, a checkpoint, a software upgrade, a virus detection, a user or business tag, and a network event.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/638,253 US20070094312A1 (en) | 2004-05-07 | 2006-12-13 | Method for managing real-time data history of a file system |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US56916404P | 2004-05-07 | 2004-05-07 | |
US11/123,994 US8108429B2 (en) | 2004-05-07 | 2005-05-06 | System for moving real-time data events across a plurality of devices in a network for simultaneous data protection, replication, and access services |
US11/638,253 US20070094312A1 (en) | 2004-05-07 | 2006-12-13 | Method for managing real-time data history of a file system |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/123,994 Continuation-In-Part US8108429B2 (en) | 2004-05-07 | 2005-05-06 | System for moving real-time data events across a plurality of devices in a network for simultaneous data protection, replication, and access services |
Publications (1)
Publication Number | Publication Date |
---|---|
US20070094312A1 true US20070094312A1 (en) | 2007-04-26 |
Family
ID=35376451
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/123,994 Active 2026-09-14 US8108429B2 (en) | 2004-05-07 | 2005-05-06 | System for moving real-time data events across a plurality of devices in a network for simultaneous data protection, replication, and access services |
US11/638,253 Abandoned US20070094312A1 (en) | 2004-05-07 | 2006-12-13 | Method for managing real-time data history of a file system |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/123,994 Active 2026-09-14 US8108429B2 (en) | 2004-05-07 | 2005-05-06 | System for moving real-time data events across a plurality of devices in a network for simultaneous data protection, replication, and access services |
Country Status (3)
Country | Link |
---|---|
US (2) | US8108429B2 (en) |
EP (1) | EP1745362A4 (en) |
WO (1) | WO2005111788A2 (en) |
Cited By (94)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050262097A1 (en) * | 2004-05-07 | 2005-11-24 | Sim-Tang Siew Y | System for moving real-time data events across a plurality of devices in a network for simultaneous data protection, replication, and access services |
US20060101384A1 (en) * | 2004-11-02 | 2006-05-11 | Sim-Tang Siew Y | Management interface for a system that provides automated, real-time, continuous data protection |
US20060288050A1 (en) * | 2005-06-15 | 2006-12-21 | International Business Machines Corporation | Method, system, and computer program product for correlating directory changes to access control modifications |
US20070198555A1 (en) * | 2006-02-21 | 2007-08-23 | International Business Machines Corporation | Method, system, and program product for transferring document attributes |
US20070214382A1 (en) * | 2006-03-09 | 2007-09-13 | Kabushiki Kaisha Toshiba | Portable terminal |
US20080004549A1 (en) * | 2006-06-12 | 2008-01-03 | Anderson Paul J | Negative pressure wound treatment device, and methods |
US20080034039A1 (en) * | 2006-08-04 | 2008-02-07 | Pavel Cisler | Application-based backup-restore of electronic information |
US20080034013A1 (en) * | 2006-08-04 | 2008-02-07 | Pavel Cisler | User interface for backup management |
US20080034011A1 (en) * | 2006-08-04 | 2008-02-07 | Pavel Cisler | Restoring electronic information |
US20080034307A1 (en) * | 2006-08-04 | 2008-02-07 | Pavel Cisler | User interface for backup management |
US20080034018A1 (en) * | 2006-08-04 | 2008-02-07 | Pavel Cisler | Managing backup of content |
US20080034004A1 (en) * | 2006-08-04 | 2008-02-07 | Pavel Cisler | System for electronic backup |
US20080034017A1 (en) * | 2006-08-04 | 2008-02-07 | Dominic Giampaolo | Links to a common item in a data structure |
US20080033922A1 (en) * | 2006-08-04 | 2008-02-07 | Pavel Cisler | Searching a backup archive |
US20080034327A1 (en) * | 2006-08-04 | 2008-02-07 | Pavel Cisler | Navigation of electronic backups |
US20080059894A1 (en) * | 2006-08-04 | 2008-03-06 | Pavel Cisler | Conflict resolution in recovery of electronic data |
US20080126441A1 (en) * | 2006-08-04 | 2008-05-29 | Dominic Giampaolo | Event notification management |
US20080126442A1 (en) * | 2006-08-04 | 2008-05-29 | Pavel Cisler | Architecture for back up and/or recovery of electronic data |
US20080183773A1 (en) * | 2007-01-31 | 2008-07-31 | Jack Choy | Summarizing file system operations with a file system journal |
US20080263112A1 (en) * | 1999-05-18 | 2008-10-23 | Kom Inc. | Method and system for electronic file lifecycle management |
US20080307333A1 (en) * | 2007-06-08 | 2008-12-11 | Mcinerney Peter | Deletion in Electronic Backups |
US20080307017A1 (en) * | 2007-06-08 | 2008-12-11 | Apple Inc. | Searching and Restoring of Backups |
US20080307347A1 (en) * | 2007-06-08 | 2008-12-11 | Apple Inc. | Application-Based Backup-Restore of Electronic Information |
US20080307020A1 (en) * | 2007-06-08 | 2008-12-11 | Steve Ko | Electronic backup and restoration of encrypted data |
US20080307345A1 (en) * | 2007-06-08 | 2008-12-11 | David Hart | User Interface for Electronic Backup |
US20090106305A1 (en) * | 2007-10-19 | 2009-04-23 | Fuji Xerox Co., Ltd. | Document process history managing system, document process history managing apparatus, document process history managing method, and computer readable medium |
US20090157627A1 (en) * | 2007-09-28 | 2009-06-18 | Xcerion Ab | Network operating system |
US7590632B1 (en) * | 2004-10-12 | 2009-09-15 | Sun Microsystems, Inc. | Method for serializer maintenance and coalescing |
US20090248757A1 (en) * | 2008-04-01 | 2009-10-01 | Microsoft Corporation | Application-Managed File Versioning |
US20090254591A1 (en) * | 2007-06-08 | 2009-10-08 | Apple Inc. | Manipulating Electronic Backups |
US20090271586A1 (en) * | 1998-07-31 | 2009-10-29 | Kom Networks Inc. | Method and system for providing restricted access to a storage medium |
US20100030998A1 (en) * | 2008-07-30 | 2010-02-04 | Vmware, Inc. | Memory Management Using Transparent Page Transformation |
US7680834B1 (en) | 2004-06-08 | 2010-03-16 | Bakbone Software, Inc. | Method and system for no downtime resychronization for real-time, continuous data protection |
US7689602B1 (en) | 2005-07-20 | 2010-03-30 | Bakbone Software, Inc. | Method of creating hierarchical indices for a distributed object system |
US7788521B1 (en) | 2005-07-20 | 2010-08-31 | Bakbone Software, Inc. | Method and system for virtual on-demand recovery for real-time, continuous data protection |
US20100257403A1 (en) * | 2009-04-03 | 2010-10-07 | Microsoft Corporation | Restoration of a system from a set of full and partial delta system snapshots across a distributed system |
CN101965558A (en) * | 2008-02-29 | 2011-02-02 | 三菱电机株式会社 | Event history memory device, event history tracking device, event history memory method, event history memory program and data structure |
US7979404B2 (en) | 2004-09-17 | 2011-07-12 | Quest Software, Inc. | Extracting data changes and storing data history to allow for instantaneous access to and reconstruction of any point-in-time data |
US20110173601A1 (en) * | 2010-01-12 | 2011-07-14 | Google Inc. | Operating system auto-update procedure |
US20110191777A1 (en) * | 2010-01-29 | 2011-08-04 | Ajay Bansal | Method and Apparatus for Scheduling Data Backups |
US8060889B2 (en) | 2004-05-10 | 2011-11-15 | Quest Software, Inc. | Method and system for real-time event journaling to provide enterprise data services |
US8099392B2 (en) | 2007-06-08 | 2012-01-17 | Apple Inc. | Electronic backup of applications |
US8131723B2 (en) | 2007-03-30 | 2012-03-06 | Quest Software, Inc. | Recovering a file system to any point-in-time in the past with guaranteed structure, content consistency and integrity |
US20120084764A1 (en) * | 2007-07-11 | 2012-04-05 | Thorley Jeb Stuart | Method and system for version independent software release management |
US20120158657A1 (en) * | 2010-12-21 | 2012-06-21 | International Business Machines Corporation | Role-specific access control to sections of artifact content within a configuration management (cm) system |
US8209350B1 (en) * | 2007-09-12 | 2012-06-26 | The Mathworks, Inc. | Storing and maintaining consistency among folios holding associated information |
US20120216073A1 (en) * | 2011-02-18 | 2012-08-23 | Ab Initio Technology Llc | Restarting Processes |
US8311988B2 (en) | 2006-08-04 | 2012-11-13 | Apple Inc. | Consistent back up of electronic information |
US8364648B1 (en) | 2007-04-09 | 2013-01-29 | Quest Software, Inc. | Recovering a database to any point-in-time in the past with guaranteed data consistency |
US20130103706A1 (en) * | 2009-01-29 | 2013-04-25 | International Business Machines Corporation | Method for Objectclass Versioning |
US8453145B1 (en) | 2010-05-06 | 2013-05-28 | Quest Software, Inc. | Systems and methods for instant provisioning of virtual machine files |
US8468136B2 (en) | 2007-06-08 | 2013-06-18 | Apple Inc. | Efficient data backup |
US20130227028A1 (en) * | 2012-02-28 | 2013-08-29 | Microsoft Corporation | Enhanced replication for message services |
US20130290263A1 (en) * | 2009-06-26 | 2013-10-31 | Simplivity Corporation | File system |
US20130311428A1 (en) * | 2012-05-15 | 2013-11-21 | Splunk Inc. | Clustering for high availability and disaster recovery |
US20130325804A1 (en) * | 2012-06-05 | 2013-12-05 | International Business Machines Corporation | Replica identification and collision avoidance in file system replication |
US8725965B2 (en) | 2007-06-08 | 2014-05-13 | Apple Inc. | System setup for electronic backup |
US20140157407A1 (en) * | 2011-05-06 | 2014-06-05 | The University Of North Carolina At Chapel Hill | Methods, systems, and computer readable media for efficient computer forensic analysis and data access control |
US20140172803A1 (en) * | 2012-12-19 | 2014-06-19 | Microsoft Corporation | Main-memory database checkpointing |
US8943026B2 (en) | 2011-01-14 | 2015-01-27 | Apple Inc. | Visual representation of a local backup |
US8984029B2 (en) | 2011-01-14 | 2015-03-17 | Apple Inc. | File system management |
US9053107B1 (en) * | 2011-12-06 | 2015-06-09 | Google Inc. | Determining updates for files based on an organization of the files on different blocks of a storage device |
US20150234910A1 (en) * | 2014-02-17 | 2015-08-20 | Unify Square, Inc. | Lifecycle management and provisioning system for unified communications |
US9124612B2 (en) | 2012-05-15 | 2015-09-01 | Splunk Inc. | Multi-site clustering |
US9130971B2 (en) | 2012-05-15 | 2015-09-08 | Splunk, Inc. | Site-based search affinity |
US20150331755A1 (en) * | 2014-05-15 | 2015-11-19 | Carbonite, Inc. | Systems and methods for time-based folder restore |
US9251008B2 (en) | 2013-03-14 | 2016-02-02 | International Business Machines Corporation | Client object replication between a first backup server and a second backup server |
US9292388B2 (en) * | 2014-03-18 | 2016-03-22 | Palantir Technologies Inc. | Determining and extracting changed data from a data source |
US9361243B2 (en) | 1998-07-31 | 2016-06-07 | Kom Networks Inc. | Method and system for providing restricted access to a storage medium |
US9424139B1 (en) * | 2011-03-31 | 2016-08-23 | Emc Corporation | Version based data protection |
US9547562B1 (en) | 2010-08-11 | 2017-01-17 | Dell Software Inc. | Boot restore system for rapidly restoring virtual machine backups |
US20170192856A1 (en) * | 2015-12-30 | 2017-07-06 | Dropbox, Inc. | Techniques for providing user interface enhancements for online content management system version histories |
US9852205B2 (en) | 2013-03-15 | 2017-12-26 | Palantir Technologies Inc. | Time-sensitive cube |
WO2018009710A1 (en) * | 2016-07-07 | 2018-01-11 | Tuxera Inc | Systems and methods for performing data object renaming operations |
US9880987B2 (en) | 2011-08-25 | 2018-01-30 | Palantir Technologies, Inc. | System and method for parameterizing documents for automatic workflow generation |
US9898335B1 (en) | 2012-10-22 | 2018-02-20 | Palantir Technologies Inc. | System and method for batch evaluation programs |
US10176113B2 (en) | 2009-06-26 | 2019-01-08 | Hewlett Packard Enterprise Development Lp | Scalable indexing |
US10198452B2 (en) | 2014-05-30 | 2019-02-05 | Apple Inc. | Document tracking for safe save operations |
US10198515B1 (en) | 2013-12-10 | 2019-02-05 | Palantir Technologies Inc. | System and method for aggregating data from a plurality of data sources |
US10387448B2 (en) | 2012-05-15 | 2019-08-20 | Splunk Inc. | Replication of summary data in a clustered computing environment |
US20190296937A1 (en) * | 2017-01-10 | 2019-09-26 | Bayerische Motoren Werke Aktiengesellschaft | Central Data Store in Vehicle Electrical System |
US10452678B2 (en) | 2013-03-15 | 2019-10-22 | Palantir Technologies Inc. | Filter chains for exploring large data sets |
CN110569318A (en) * | 2018-05-16 | 2019-12-13 | 杭州海康威视数字技术股份有限公司 | space-time data storage method, query method, storage device and query device |
US10528440B2 (en) * | 2016-11-28 | 2020-01-07 | Sap Se | Metadata cataloging framework |
US10545913B1 (en) * | 2017-04-30 | 2020-01-28 | EMC IP Holding Company LLC | Data storage system with on-demand recovery of file import metadata during file system migration |
US10554664B2 (en) | 2016-05-02 | 2020-02-04 | Microsoft Technology Licensing, Llc | Activity feed for hosted files |
US10747952B2 (en) | 2008-09-15 | 2020-08-18 | Palantir Technologies, Inc. | Automatic creation and server push of multiple distinct drafts |
US10803093B2 (en) * | 2017-09-22 | 2020-10-13 | Microsoft Technology Licensing, Llc | Systems and methods for enabling a file management label to persist on a data file |
US10902185B1 (en) * | 2015-12-30 | 2021-01-26 | Google Llc | Distributed collaborative storage with operational transformation |
US10963376B2 (en) * | 2011-03-31 | 2021-03-30 | Oracle International Corporation | NUMA-aware garbage collection |
US11003687B2 (en) | 2012-05-15 | 2021-05-11 | Splunk, Inc. | Executing data searches using generation identifiers |
US11099982B2 (en) | 2011-03-31 | 2021-08-24 | Oracle International Corporation | NUMA-aware garbage collection |
US11531658B2 (en) * | 2014-05-19 | 2022-12-20 | Amazon Technologies, Inc. | Criterion-based retention of data object versions |
US11620186B1 (en) * | 2020-06-17 | 2023-04-04 | Egnyte, Inc. | System and method for resolving transient and localized errors in a hybrid cloud cache |
Families Citing this family (270)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7904428B2 (en) | 2003-09-23 | 2011-03-08 | Symantec Corporation | Methods and apparatus for recording write requests directed to a data store |
US7827362B2 (en) | 2004-08-24 | 2010-11-02 | Symantec Corporation | Systems, apparatus, and methods for processing I/O requests |
US7991748B2 (en) | 2003-09-23 | 2011-08-02 | Symantec Corporation | Virtual data store creation and use |
US7725760B2 (en) | 2003-09-23 | 2010-05-25 | Symantec Operating Corporation | Data storage system |
US7577806B2 (en) * | 2003-09-23 | 2009-08-18 | Symantec Operating Corporation | Systems and methods for time dependent data storage and recovery |
US7730222B2 (en) | 2004-08-24 | 2010-06-01 | Symantec Operating System | Processing storage-related I/O requests using binary tree data structures |
US7287133B2 (en) | 2004-08-24 | 2007-10-23 | Symantec Operating Corporation | Systems and methods for providing a modification history for a location within a data store |
US8051483B2 (en) | 2004-03-12 | 2011-11-01 | Fortinet, Inc. | Systems and methods for updating content detection devices and systems |
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 |
US7698401B2 (en) * | 2004-06-01 | 2010-04-13 | Inmage Systems, Inc | Secondary data storage and recovery system |
US8868858B2 (en) * | 2006-05-19 | 2014-10-21 | Inmage Systems, Inc. | Method and apparatus of continuous data backup and access using virtual machines |
US8224786B2 (en) * | 2004-06-01 | 2012-07-17 | Inmage Systems, Inc. | Acquisition and write validation of data of a networked host node to perform secondary storage |
US9209989B2 (en) * | 2004-06-01 | 2015-12-08 | Inmage Systems, Inc. | Causation of a data read operation against a first storage system by a server associated with a second storage system according to a host generated instruction |
US7979656B2 (en) | 2004-06-01 | 2011-07-12 | Inmage Systems, Inc. | Minimizing configuration changes in a fabric-based data protection solution |
US7676502B2 (en) * | 2006-05-22 | 2010-03-09 | Inmage Systems, Inc. | Recovery point data view shift through a direction-agnostic roll algorithm |
US8949395B2 (en) * | 2004-06-01 | 2015-02-03 | Inmage Systems, Inc. | Systems and methods of event driven recovery management |
US7565445B2 (en) | 2004-06-18 | 2009-07-21 | Fortinet, Inc. | Systems and methods for categorizing network traffic content |
US7363365B2 (en) | 2004-07-13 | 2008-04-22 | Teneros Inc. | Autonomous service backup and migration |
US7363366B2 (en) | 2004-07-13 | 2008-04-22 | Teneros Inc. | Network traffic routing |
US20060015584A1 (en) * | 2004-07-13 | 2006-01-19 | Teneros, Inc. | Autonomous service appliance |
US20060015764A1 (en) * | 2004-07-13 | 2006-01-19 | Teneros, Inc. | Transparent service provider |
WO2006026402A2 (en) | 2004-08-26 | 2006-03-09 | Availigent, Inc. | Method and system for providing high availability to computer applications |
US7664983B2 (en) | 2004-08-30 | 2010-02-16 | Symantec Corporation | Systems and methods for event driven recovery management |
US7876357B2 (en) | 2005-01-31 | 2011-01-25 | The Invention Science Fund I, Llc | Estimating shared image device operational capabilities or resources |
US9489717B2 (en) | 2005-01-31 | 2016-11-08 | Invention Science Fund I, Llc | Shared image device |
US9124729B2 (en) | 2005-01-31 | 2015-09-01 | The Invention Science Fund I, Llc | Shared image device synchronization or designation |
US8606383B2 (en) | 2005-01-31 | 2013-12-10 | The Invention Science Fund I, Llc | Audio sharing |
US9082456B2 (en) | 2005-01-31 | 2015-07-14 | The Invention Science Fund I Llc | Shared image device designation |
US8902320B2 (en) | 2005-01-31 | 2014-12-02 | The Invention Science Fund I, Llc | Shared image device synchronization or designation |
US9910341B2 (en) | 2005-01-31 | 2018-03-06 | The Invention Science Fund I, Llc | Shared image device designation |
US20060174203A1 (en) | 2005-01-31 | 2006-08-03 | Searete Llc, A Limited Liability Corporation Of The State Of Delaware | Viewfinder for shared image device |
US20060170956A1 (en) | 2005-01-31 | 2006-08-03 | Jung Edward K | Shared image devices |
US9325781B2 (en) | 2005-01-31 | 2016-04-26 | Invention Science Fund I, Llc | Audio sharing |
US20060221197A1 (en) * | 2005-03-30 | 2006-10-05 | Jung Edward K | Image transformation estimator of an imaging device |
US7920169B2 (en) | 2005-01-31 | 2011-04-05 | Invention Science Fund I, Llc | Proximity of shared image devices |
US9942511B2 (en) | 2005-10-31 | 2018-04-10 | Invention Science Fund I, Llc | Preservation/degradation of video/audio aspects of a data stream |
US9967424B2 (en) | 2005-06-02 | 2018-05-08 | Invention Science Fund I, Llc | Data storage usage protocol |
US9167195B2 (en) | 2005-10-31 | 2015-10-20 | Invention Science Fund I, Llc | Preservation/degradation of video/audio aspects of a data stream |
US8964054B2 (en) | 2006-08-18 | 2015-02-24 | The Invention Science Fund I, Llc | Capturing selected image objects |
US9819490B2 (en) | 2005-05-04 | 2017-11-14 | Invention Science Fund I, Llc | Regional proximity for shared image device(s) |
US7872675B2 (en) | 2005-06-02 | 2011-01-18 | The Invention Science Fund I, Llc | Saved-image management |
US9191611B2 (en) | 2005-06-02 | 2015-11-17 | Invention Science Fund I, Llc | Conditional alteration of a saved image |
US10003762B2 (en) | 2005-04-26 | 2018-06-19 | Invention Science Fund I, Llc | Shared image devices |
US20070222865A1 (en) | 2006-03-15 | 2007-09-27 | Searete Llc, A Limited Liability Corporation Of The State Of Delaware | Enhanced video/still image correlation |
US8253821B2 (en) | 2005-10-31 | 2012-08-28 | The Invention Science Fund I, Llc | Degradation/preservation management of captured data |
US9621749B2 (en) | 2005-06-02 | 2017-04-11 | Invention Science Fund I, Llc | Capturing selected image objects |
US8233042B2 (en) | 2005-10-31 | 2012-07-31 | The Invention Science Fund I, Llc | Preservation and/or degradation of a video/audio data stream |
US7782365B2 (en) | 2005-06-02 | 2010-08-24 | Searete Llc | Enhanced video/still image correlation |
US9001215B2 (en) | 2005-06-02 | 2015-04-07 | The Invention Science Fund I, Llc | Estimating shared image device operational capabilities or resources |
US9076208B2 (en) | 2006-02-28 | 2015-07-07 | The Invention Science Fund I, Llc | Imagery processing |
US8681225B2 (en) * | 2005-06-02 | 2014-03-25 | Royce A. Levien | Storage access technique for captured data |
US8072501B2 (en) | 2005-10-31 | 2011-12-06 | The Invention Science Fund I, Llc | Preservation and/or degradation of a video/audio data stream |
US9451200B2 (en) | 2005-06-02 | 2016-09-20 | Invention Science Fund I, Llc | Storage access technique for captured data |
US9093121B2 (en) | 2006-02-28 | 2015-07-28 | The Invention Science Fund I, Llc | Data management of an audio data stream |
US7765229B2 (en) * | 2005-07-12 | 2010-07-27 | Microsoft Corporation | Single view of data in a networked computer system with distributed storage |
CA2615659A1 (en) * | 2005-07-22 | 2007-05-10 | Yogesh Chunilal Rathod | Universal knowledge management and desktop search system |
US8694621B2 (en) | 2005-08-19 | 2014-04-08 | Riverbed Technology, Inc. | Capture, analysis, and visualization of concurrent system and network behavior of an application |
US8752049B1 (en) | 2008-12-15 | 2014-06-10 | Open Invention Network, Llc | Method and computer readable medium for providing checkpointing to windows application groups |
US8082468B1 (en) | 2008-12-15 | 2011-12-20 | Open Invention Networks, Llc | Method and system for providing coordinated checkpointing to a group of independent computer applications |
US8601225B2 (en) * | 2005-09-16 | 2013-12-03 | Inmage Systems, Inc. | Time ordered view of backup data on behalf of a host |
US8683144B2 (en) * | 2005-09-16 | 2014-03-25 | Inmage Systems, Inc. | Causation of a data read against a first storage system to optionally store a data write to preserve the version to allow viewing and recovery |
US8290910B2 (en) * | 2005-09-21 | 2012-10-16 | Infoblox Inc. | Semantic replication |
US8250030B2 (en) | 2005-09-21 | 2012-08-21 | Infoblox Inc. | Provisional authority in a distributed database |
US8533169B1 (en) | 2005-09-21 | 2013-09-10 | Infoblox Inc. | Transactional replication |
US20070120980A1 (en) | 2005-10-31 | 2007-05-31 | Searete Llc, A Limited Liability Corporation Of The State Of Delaware | Preservation/degradation of video/audio aspects of a data stream |
US20070106683A1 (en) * | 2005-11-08 | 2007-05-10 | 3Com Corporation | Distributed database |
US7631151B2 (en) | 2005-11-28 | 2009-12-08 | Commvault Systems, Inc. | Systems and methods for classifying and transferring information in a storage network |
US7822749B2 (en) | 2005-11-28 | 2010-10-26 | Commvault Systems, Inc. | Systems and methods for classifying and transferring information in a storage network |
US20200257596A1 (en) | 2005-12-19 | 2020-08-13 | Commvault Systems, Inc. | Systems and methods of unified reconstruction in storage systems |
US8930496B2 (en) | 2005-12-19 | 2015-01-06 | Commvault Systems, Inc. | Systems and methods of unified reconstruction in storage systems |
WO2007072310A1 (en) | 2005-12-22 | 2007-06-28 | Shapiro Alan J | System and method for software delivery |
US9286308B2 (en) | 2005-12-22 | 2016-03-15 | Alan Joshua Shapiro | System and method for metadata modification |
US8838615B2 (en) * | 2006-02-02 | 2014-09-16 | Oracle International Corporation | Computer implemented method for automatically managing stored checkpoint data |
US7580974B2 (en) | 2006-02-16 | 2009-08-25 | Fortinet, Inc. | Systems and methods for content type classification |
JP2007257023A (en) * | 2006-03-20 | 2007-10-04 | Nec Corp | Server multiplying system and server multiplying method |
TW200737954A (en) * | 2006-03-27 | 2007-10-01 | Arcadyan Technology Corp | Method of managing metadata and set top boxes device |
US7899780B1 (en) * | 2006-03-30 | 2011-03-01 | Emc Corporation | Methods and apparatus for structured partitioning of management information |
US8572040B2 (en) * | 2006-04-28 | 2013-10-29 | International Business Machines Corporation | Methods and infrastructure for performing repetitive data protection and a corresponding restore of data |
US8554727B2 (en) * | 2006-05-19 | 2013-10-08 | Inmage Systems, Inc. | Method and system of tiered quiescing |
US8527470B2 (en) * | 2006-05-22 | 2013-09-03 | Rajeev Atluri | Recovery point data view formation with generation of a recovery view and a coalesce policy |
US8527721B2 (en) * | 2008-12-26 | 2013-09-03 | Rajeev Atluri | Generating a recovery snapshot and creating a virtual view of the recovery snapshot |
US8838528B2 (en) * | 2006-05-22 | 2014-09-16 | Inmage Systems, Inc. | Coalescing and capturing data between events prior to and after a temporal window |
US7613750B2 (en) * | 2006-05-29 | 2009-11-03 | Microsoft Corporation | Creating frequent application-consistent backups efficiently |
US7587570B2 (en) * | 2006-05-31 | 2009-09-08 | International Business Machines Corporation | System and method for providing automated storage provisioning |
US9250972B2 (en) * | 2006-06-19 | 2016-02-02 | International Business Machines Corporation | Orchestrated peer-to-peer server provisioning |
US8078585B2 (en) * | 2006-06-29 | 2011-12-13 | Emc Corporation | Reactive file recovery based on file naming and access information |
US7634507B2 (en) * | 2006-08-30 | 2009-12-15 | Inmage Systems, Inc. | Ensuring data persistence and consistency in enterprise storage backup systems |
US8612570B1 (en) | 2006-09-18 | 2013-12-17 | Emc Corporation | Data classification and management using tap network architecture |
US10394849B2 (en) * | 2006-09-18 | 2019-08-27 | EMC IP Holding Company LLC | Cascaded discovery of information environment |
US7882077B2 (en) | 2006-10-17 | 2011-02-01 | Commvault Systems, Inc. | Method and system for offline indexing of content and classifying stored data |
US8370442B2 (en) | 2008-08-29 | 2013-02-05 | Commvault Systems, Inc. | Method and system for leveraging identified changes to a mail server |
EP2102750B1 (en) | 2006-12-04 | 2014-11-05 | Commvault Systems, Inc. | System and method for creating copies of data, such as archive copies |
US8135135B2 (en) * | 2006-12-08 | 2012-03-13 | Microsoft Corporation | Secure data protection during disasters |
US7882076B2 (en) * | 2006-12-14 | 2011-02-01 | Lam Research Corporation | Primary server architectural networking arrangement and methods therefor |
US8019723B2 (en) * | 2006-12-20 | 2011-09-13 | International Business Machines Corporation | Deferred copy target pull of volume data |
US7925626B2 (en) * | 2006-12-20 | 2011-04-12 | International Business Machines Corporation | Immediate copy target pull of volume data |
US20080228771A1 (en) | 2006-12-22 | 2008-09-18 | Commvault Systems, Inc. | Method and system for searching stored data |
US7840537B2 (en) | 2006-12-22 | 2010-11-23 | Commvault Systems, Inc. | System and method for storing redundant information |
US7685189B2 (en) * | 2006-12-27 | 2010-03-23 | Microsoft Corporation | Optimizing backup and recovery utilizing change tracking |
US7801867B2 (en) * | 2006-12-27 | 2010-09-21 | Microsoft Corporation | Optimizing backup and recovery utilizing change tracking |
US9166989B2 (en) * | 2006-12-28 | 2015-10-20 | Hewlett-Packard Development Company, L.P. | Storing log data efficiently while supporting querying |
US7974981B2 (en) * | 2007-07-19 | 2011-07-05 | Microsoft Corporation | Multi-value property storage and query support |
US8554734B1 (en) * | 2007-07-19 | 2013-10-08 | American Megatrends, Inc. | Continuous data protection journaling in data storage systems |
US8548964B1 (en) | 2007-09-28 | 2013-10-01 | Emc Corporation | Delegation of data classification using common language |
US8868720B1 (en) | 2007-09-28 | 2014-10-21 | Emc Corporation | Delegation of discovery functions in information management system |
US9323901B1 (en) | 2007-09-28 | 2016-04-26 | Emc Corporation | Data classification for digital rights management |
US9461890B1 (en) | 2007-09-28 | 2016-10-04 | Emc Corporation | Delegation of data management policy in an information management system |
US9141658B1 (en) | 2007-09-28 | 2015-09-22 | Emc Corporation | Data classification and management for risk mitigation |
US8522248B1 (en) | 2007-09-28 | 2013-08-27 | Emc Corporation | Monitoring delegated operations in information management systems |
US20090096276A1 (en) * | 2007-10-16 | 2009-04-16 | Consolidated Metco, Inc. | Wheel hub stress reduction system |
US7836174B2 (en) | 2008-01-30 | 2010-11-16 | Commvault Systems, Inc. | Systems and methods for grid-based data scanning |
US8296301B2 (en) | 2008-01-30 | 2012-10-23 | Commvault Systems, Inc. | Systems and methods for probabilistic data classification |
US8055613B1 (en) * | 2008-04-29 | 2011-11-08 | Netapp, Inc. | Method and apparatus for efficiently detecting and logging file system changes |
US9098495B2 (en) | 2008-06-24 | 2015-08-04 | Commvault Systems, Inc. | Application-aware and remote single instance data management |
US8166263B2 (en) | 2008-07-03 | 2012-04-24 | Commvault Systems, Inc. | Continuous data protection over intermittent connections, such as continuous data backup for laptops or wireless devices |
US8706694B2 (en) * | 2008-07-15 | 2014-04-22 | American Megatrends, Inc. | Continuous data protection of files stored on a remote storage device |
US8028194B2 (en) * | 2008-07-25 | 2011-09-27 | Inmage Systems, Inc | Sequencing technique to account for a clock error in a backup system |
US8307177B2 (en) | 2008-09-05 | 2012-11-06 | Commvault Systems, Inc. | Systems and methods for management of virtualization data |
US9015181B2 (en) | 2008-09-26 | 2015-04-21 | Commvault Systems, Inc. | Systems and methods for managing single instancing data |
WO2010036754A1 (en) | 2008-09-26 | 2010-04-01 | Commvault Systems, Inc. | Systems and methods for managing single instancing data |
US9189427B2 (en) * | 2008-10-29 | 2015-11-17 | Bruce Backa | System and method for policy-based data archiving triggered by user activity |
US8412677B2 (en) | 2008-11-26 | 2013-04-02 | Commvault Systems, Inc. | Systems and methods for byte-level or quasi byte-level single instancing |
US8281317B1 (en) | 2008-12-15 | 2012-10-02 | Open Invention Network Llc | Method and computer readable medium for providing checkpointing to windows application groups |
US8341631B2 (en) | 2009-04-10 | 2012-12-25 | Open Invention Network Llc | System and method for application isolation |
US8782670B2 (en) * | 2009-04-10 | 2014-07-15 | Open Invention Network, Llc | System and method for application isolation |
US8752048B1 (en) | 2008-12-15 | 2014-06-10 | Open Invention Network, Llc | Method and system for providing checkpointing to windows application groups |
US8904004B2 (en) * | 2009-04-10 | 2014-12-02 | Open Invention Network, Llc | System and method for maintaining mappings between application resources inside and outside isolated environments |
US8880473B1 (en) * | 2008-12-15 | 2014-11-04 | Open Invention Network, Llc | Method and system for providing storage checkpointing to a group of independent computer applications |
US8539488B1 (en) | 2009-04-10 | 2013-09-17 | Open Invention Network, Llc | System and method for application isolation with live migration |
US8464256B1 (en) | 2009-04-10 | 2013-06-11 | Open Invention Network, Llc | System and method for hierarchical interception with isolated environments |
US8069227B2 (en) * | 2008-12-26 | 2011-11-29 | Inmage Systems, Inc. | Configuring hosts of a secondary data storage and recovery system |
US8401996B2 (en) | 2009-03-30 | 2013-03-19 | Commvault Systems, Inc. | Storing a variable number of instances of data objects |
US8805953B2 (en) * | 2009-04-03 | 2014-08-12 | Microsoft Corporation | Differential file and system restores from peers and the cloud |
US9577893B1 (en) | 2009-04-10 | 2017-02-21 | Open Invention Network Llc | System and method for cached streaming application isolation |
US8555360B1 (en) | 2009-04-10 | 2013-10-08 | Open Invention Network Llc | System and method for on-line and off-line streaming application isolation |
US9058599B1 (en) | 2009-04-10 | 2015-06-16 | Open Invention Network, Llc | System and method for usage billing of hosted applications |
US8418236B1 (en) | 2009-04-10 | 2013-04-09 | Open Invention Network Llc | System and method for streaming application isolation |
US10419504B1 (en) | 2009-04-10 | 2019-09-17 | Open Invention Network Llc | System and method for streaming application isolation |
US11538078B1 (en) | 2009-04-10 | 2022-12-27 | International Business Machines Corporation | System and method for usage billing of hosted applications |
US8935366B2 (en) * | 2009-04-24 | 2015-01-13 | Microsoft Corporation | Hybrid distributed and cloud backup architecture |
US8769055B2 (en) * | 2009-04-24 | 2014-07-01 | Microsoft Corporation | Distributed backup and versioning |
US8560639B2 (en) * | 2009-04-24 | 2013-10-15 | Microsoft Corporation | Dynamic placement of replica data |
US8769049B2 (en) * | 2009-04-24 | 2014-07-01 | Microsoft Corporation | Intelligent tiers of backup data |
US8578120B2 (en) | 2009-05-22 | 2013-11-05 | Commvault Systems, Inc. | Block-level single instancing |
US8370306B1 (en) * | 2009-11-13 | 2013-02-05 | Symantec Corporation | Systems and methods for recovering from continuous-data-protection blackouts |
US8503984B2 (en) * | 2009-12-23 | 2013-08-06 | Amos Winbush, III | Mobile communication device user content synchronization with central web-based records and information sharing system |
US20110149086A1 (en) | 2009-12-23 | 2011-06-23 | Winbush Iii Amos | Camera user content synchronization with central web-based records and information sharing system |
US8442983B2 (en) | 2009-12-31 | 2013-05-14 | Commvault Systems, Inc. | Asynchronous methods of data classification using change journals and other data structures |
US8825601B2 (en) * | 2010-02-01 | 2014-09-02 | Microsoft Corporation | Logical data backup and rollback using incremental capture in a distributed database |
US20110231698A1 (en) * | 2010-03-22 | 2011-09-22 | Zlati Andrei C | Block based vss technology in workload migration and disaster recovery in computing system environment |
US8959054B1 (en) * | 2010-03-25 | 2015-02-17 | Emc Corporation | Methods and apparatus for optimal journaling for continuous data replication |
US9813529B2 (en) | 2011-04-28 | 2017-11-07 | Microsoft Technology Licensing, Llc | Effective circuits in packet-switched networks |
US8438244B2 (en) | 2010-04-19 | 2013-05-07 | Microsoft Corporation | Bandwidth-proportioned datacenters |
US9170892B2 (en) | 2010-04-19 | 2015-10-27 | Microsoft Technology Licensing, Llc | Server failure recovery |
US8447833B2 (en) | 2010-04-19 | 2013-05-21 | Microsoft Corporation | Reading and writing during cluster growth phase |
US9454441B2 (en) | 2010-04-19 | 2016-09-27 | Microsoft Technology Licensing, Llc | Data layout for recovery and durability |
US8181061B2 (en) | 2010-04-19 | 2012-05-15 | Microsoft Corporation | Memory management and recovery for datacenters |
US8533299B2 (en) | 2010-04-19 | 2013-09-10 | Microsoft Corporation | Locator table and client library for datacenters |
US8996611B2 (en) | 2011-01-31 | 2015-03-31 | Microsoft Technology Licensing, Llc | Parallel serialization of request processing |
US10002202B2 (en) * | 2010-05-28 | 2018-06-19 | Microsoft Technology Licensing, Llc | Realtime websites with publication and subscription |
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 |
WO2012045023A2 (en) | 2010-09-30 | 2012-04-05 | Commvault Systems, Inc. | Archiving data objects using secondary copies |
US20120124497A1 (en) * | 2010-11-12 | 2012-05-17 | Yokogawa Electric Corporation | Method and apparatus for data virtualization and display |
US8719264B2 (en) | 2011-03-31 | 2014-05-06 | Commvault Systems, Inc. | Creating secondary copies of data based on searches for content |
US8949182B2 (en) | 2011-06-17 | 2015-02-03 | International Business Machines Corporation | Continuous and asynchronous replication of a consistent dataset |
US8843502B2 (en) | 2011-06-24 | 2014-09-23 | Microsoft Corporation | Sorting a dataset of incrementally received data |
US20130138615A1 (en) * | 2011-11-29 | 2013-05-30 | International Business Machines Corporation | Synchronizing updates across cluster filesystems |
US9020890B2 (en) | 2012-03-30 | 2015-04-28 | Commvault Systems, Inc. | Smart archiving and data previewing for mobile devices |
US8892523B2 (en) | 2012-06-08 | 2014-11-18 | Commvault Systems, Inc. | Auto summarization of content |
US8904224B2 (en) | 2012-07-20 | 2014-12-02 | International Business Machines Corporation | Providing replication and fail-over as a network service in data centers |
US9778856B2 (en) | 2012-08-30 | 2017-10-03 | Microsoft Technology Licensing, Llc | Block-level access to parallel storage |
US10346369B2 (en) | 2012-10-11 | 2019-07-09 | Delphix Corp. | Retrieving point-in-time copies of a source database for creating virtual databases |
US9223597B2 (en) | 2012-12-21 | 2015-12-29 | Commvault Systems, Inc. | Archiving virtual machines in a data storage system |
US20140181046A1 (en) | 2012-12-21 | 2014-06-26 | Commvault Systems, Inc. | Systems and methods to backup unprotected virtual machines |
US9633022B2 (en) | 2012-12-28 | 2017-04-25 | Commvault Systems, Inc. | Backup and restoration for a deduplicated file system |
US20140196038A1 (en) | 2013-01-08 | 2014-07-10 | Commvault Systems, Inc. | Virtual machine management in a data storage system |
US9047248B2 (en) | 2013-01-29 | 2015-06-02 | Sungard Availability Services, Lp | Logical domain recovery |
GB2515501A (en) * | 2013-06-25 | 2014-12-31 | Ibm | Replication for on-line hot-standby database |
US11422907B2 (en) | 2013-08-19 | 2022-08-23 | Microsoft Technology Licensing, Llc | Disconnected operation for systems utilizing cloud storage |
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 |
US9158633B2 (en) | 2013-12-24 | 2015-10-13 | International Business Machines Corporation | File corruption recovery in concurrent data protection |
US10324897B2 (en) | 2014-01-27 | 2019-06-18 | Commvault Systems, Inc. | Techniques for serving archived electronic mail |
US9798631B2 (en) | 2014-02-04 | 2017-10-24 | Microsoft Technology Licensing, Llc | Block storage by decoupling ordering from durability |
WO2015139026A2 (en) | 2014-03-14 | 2015-09-17 | Go Tenna Inc. | System and method for digital communication between computing devices |
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 |
US10474659B2 (en) * | 2014-06-28 | 2019-11-12 | Microsoft Technology Licensing, Llc | Large scale network system upgrade |
US20160019317A1 (en) | 2014-07-16 | 2016-01-21 | Commvault Systems, Inc. | Volume or virtual machine level backup and generating placeholders for virtual machine files |
US10528752B2 (en) | 2014-08-13 | 2020-01-07 | Hewlett Packard Enterprise Development Lp | Non-volatile storage of management data |
US9558078B2 (en) | 2014-10-28 | 2017-01-31 | Microsoft Technology Licensing, Llc | Point in time database restore from storage snapshots |
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 |
CN104484470B (en) * | 2014-12-31 | 2018-06-08 | 天津南大通用数据技术股份有限公司 | A kind of data-base cluster metadata management method |
US11132336B2 (en) | 2015-01-12 | 2021-09-28 | Qumulo, Inc. | Filesystem hierarchical capacity quantity and aggregate metrics |
US9836480B2 (en) | 2015-01-12 | 2017-12-05 | Qumulo, Inc. | Filesystem capacity and performance metrics and visualizations |
US10324914B2 (en) | 2015-05-20 | 2019-06-18 | Commvalut Systems, Inc. | Handling user queries against production and archive storage systems, such as for enterprise customers having large and/or numerous files |
US9959334B1 (en) * | 2015-06-16 | 2018-05-01 | Amazon Technologies, Inc. | Live drone observation data recording |
US11561863B2 (en) | 2015-08-20 | 2023-01-24 | International Business Machines Corporation | PDSE member generation clustering and recovery |
CN105389368A (en) * | 2015-11-16 | 2016-03-09 | 天津南大通用数据技术股份有限公司 | Method for managing metadata of database cluster of MPP architecture |
US9477555B1 (en) * | 2015-11-16 | 2016-10-25 | International Business Machines Corporation | Optimized disaster-recovery-as-a-service system |
US10261867B1 (en) * | 2016-01-25 | 2019-04-16 | Veritas Technologies Llc | Intelligent point-in-time selector |
US11010409B1 (en) * | 2016-03-29 | 2021-05-18 | EMC IP Holding Company LLC | Multi-streaming with synthetic replication |
US11100056B2 (en) * | 2016-05-17 | 2021-08-24 | International Business Machines Corporation | Life cycle data set repository |
US10417102B2 (en) | 2016-09-30 | 2019-09-17 | Commvault Systems, Inc. | Heartbeat monitoring of virtual machines for initiating failover operations in a data storage management system, including virtual machine distribution logic |
US10540516B2 (en) | 2016-10-13 | 2020-01-21 | Commvault Systems, Inc. | Data protection within an unsecured storage environment |
US10162528B2 (en) | 2016-10-25 | 2018-12-25 | Commvault Systems, Inc. | Targeted snapshot based on virtual machine location |
US10389810B2 (en) | 2016-11-02 | 2019-08-20 | Commvault Systems, Inc. | Multi-threaded scanning of distributed file systems |
US10922189B2 (en) | 2016-11-02 | 2021-02-16 | Commvault Systems, Inc. | Historical network data-based scanning thread generation |
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 |
US10459647B1 (en) * | 2017-03-02 | 2019-10-29 | Amazon Technologies, Inc. | Multiple storage class representation in versioned storage |
US10802746B1 (en) * | 2017-03-02 | 2020-10-13 | Amazon Technologies, Inc. | Policy-driven multiple storage class representation in versioned storage |
US10474542B2 (en) * | 2017-03-24 | 2019-11-12 | Commvault Systems, Inc. | Time-based virtual machine reversion |
US10387073B2 (en) | 2017-03-29 | 2019-08-20 | Commvault Systems, Inc. | External dynamic virtual machine synchronization |
US10915498B2 (en) * | 2017-03-30 | 2021-02-09 | International Business Machines Corporation | Dynamically managing a high speed storage tier of a data storage system |
US10795575B2 (en) | 2017-03-31 | 2020-10-06 | International Business Machines Corporation | Dynamically reacting to events within a data storage system |
US10984041B2 (en) | 2017-05-11 | 2021-04-20 | Commvault Systems, Inc. | Natural language processing integrated with database and data storage management |
US11222076B2 (en) * | 2017-05-31 | 2022-01-11 | Microsoft Technology Licensing, Llc | Data set state visualization comparison lock |
US10248385B1 (en) * | 2017-11-30 | 2019-04-02 | International Business Machines Corporation | Extracting mobile application workflow from design files |
US10944669B1 (en) | 2018-02-09 | 2021-03-09 | GoTenna, Inc. | System and method for efficient network-wide broadcast in a multi-hop wireless network using packet echos |
US10642886B2 (en) | 2018-02-14 | 2020-05-05 | Commvault Systems, Inc. | Targeted search of backup data using facial recognition |
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 |
US10073856B1 (en) * | 2018-04-30 | 2018-09-11 | Qumulo, Inc. | Continuous replication for secure distributed filesystems |
US11360936B2 (en) | 2018-06-08 | 2022-06-14 | Qumulo, Inc. | Managing per object snapshot coverage in filesystems |
CN110609845A (en) * | 2018-06-15 | 2019-12-24 | 网宿科技股份有限公司 | Big data redundancy disaster recovery method, big data service system and query method |
CA3107919A1 (en) | 2018-07-27 | 2020-01-30 | GoTenna, Inc. | Vinetm: zero-control routing using data packet inspection for wireless mesh networks |
US11126505B1 (en) * | 2018-08-10 | 2021-09-21 | Amazon Technologies, Inc. | Past-state backup generator and interface for database systems |
US11159469B2 (en) | 2018-09-12 | 2021-10-26 | Commvault Systems, Inc. | Using machine learning to modify presentation of mailbox objects |
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 |
US10621147B1 (en) | 2018-12-19 | 2020-04-14 | Qumulo, Inc. | Replicating file system objects in distributed file systems |
US10534758B1 (en) | 2018-12-20 | 2020-01-14 | Qumulo, Inc. | File system cache tiers |
US10474635B1 (en) | 2018-12-21 | 2019-11-12 | Qumulo, Inc. | Dynamic evaluation and selection of file system pre-fetch policy |
US11151092B2 (en) | 2019-01-30 | 2021-10-19 | Qumulo, Inc. | Data replication in distributed file systems |
US10768971B2 (en) | 2019-01-30 | 2020-09-08 | Commvault Systems, Inc. | Cross-hypervisor live mount of backed up virtual machine data |
US10614033B1 (en) | 2019-01-30 | 2020-04-07 | Qumulo, Inc. | Client aware pre-fetch policy scoring system |
US11082344B2 (en) | 2019-03-08 | 2021-08-03 | GoTenna, Inc. | Method for utilization-based traffic throttling in a wireless mesh network |
CN110175084B (en) * | 2019-04-04 | 2023-04-25 | 阿里巴巴集团控股有限公司 | Data change monitoring method and device |
CN110413842B (en) * | 2019-07-29 | 2021-07-27 | 北京小川在线网络技术有限公司 | Content auditing method, system, electronic equipment and medium based on public opinion situation perception |
US11341159B2 (en) | 2019-08-22 | 2022-05-24 | International Business Machines Corporation | In-stream data load in a replication environment |
US10725977B1 (en) | 2019-10-21 | 2020-07-28 | Qumulo, Inc. | Managing file system state during replication jobs |
CN111258810A (en) * | 2020-01-09 | 2020-06-09 | 广东小天才科技有限公司 | Method, system, terminal equipment and storage medium for realizing data source switching |
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 |
WO2021173006A1 (en) * | 2020-02-25 | 2021-09-02 | Production Robots Engineering Limited | Realtime distribution of granular data streams on a network |
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 |
US11907260B2 (en) | 2020-04-19 | 2024-02-20 | International Business Machines Corporation | Compare processing using replication log-injected compare records in a replication environment |
US11500669B2 (en) | 2020-05-15 | 2022-11-15 | Commvault Systems, Inc. | Live recovery of virtual machines in a public cloud computing environment |
US11494417B2 (en) | 2020-08-07 | 2022-11-08 | Commvault Systems, Inc. | Automated email classification in an information management system |
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 |
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 |
US11567660B2 (en) | 2021-03-16 | 2023-01-31 | Qumulo, Inc. | Managing cloud storage for distributed file systems |
US11132126B1 (en) | 2021-03-16 | 2021-09-28 | Qumulo, Inc. | Backup services for distributed file systems in cloud computing environments |
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 |
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 |
US20240004860A1 (en) * | 2022-06-30 | 2024-01-04 | Amazon Technologies, Inc. | Handshake protocol for efficient exchange of transactional information for a hybrid transactional and analytical processing architecture |
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 |
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 |
CN117591496A (en) * | 2024-01-18 | 2024-02-23 | 中核武汉核电运行技术股份有限公司 | High-reliability time sequence data transmission and storage system based on cloud edge cooperation |
Citations (53)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5287504A (en) * | 1989-08-01 | 1994-02-15 | Silicon Graphics, Inc. | File alteration monitor for computer operating and file management system |
US5729743A (en) * | 1995-11-17 | 1998-03-17 | Deltatech Research, Inc. | Computer apparatus and method for merging system deltas |
US5794252A (en) * | 1995-01-24 | 1998-08-11 | Tandem Computers, Inc. | Remote duplicate database facility featuring safe master audit trail (safeMAT) checkpointing |
US5819020A (en) * | 1995-10-16 | 1998-10-06 | Network Specialists, Inc. | Real time backup system |
US6047323A (en) * | 1995-10-19 | 2000-04-04 | Hewlett-Packard Company | Creation and migration of distributed streams in clusters of networked computers |
US6158019A (en) * | 1996-12-15 | 2000-12-05 | Delta-Tek Research, Inc. | System and apparatus for merging a write event journal and an original storage to produce an updated storage using an event map |
US6163856A (en) * | 1998-05-29 | 2000-12-19 | Sun Microsystems, Inc. | Method and apparatus for file system disaster recovery |
US6189016B1 (en) * | 1998-06-12 | 2001-02-13 | Microsoft Corporation | Journaling ordered changes in a storage volume |
US6366988B1 (en) * | 1997-07-18 | 2002-04-02 | Storactive, Inc. | Systems and methods for electronic data storage management |
US6389427B1 (en) * | 1998-02-20 | 2002-05-14 | Redleaf Group, Inc. | File system performance enhancement |
US6393582B1 (en) * | 1998-12-10 | 2002-05-21 | Compaq Computer Corporation | Error self-checking and recovery using lock-step processor pair architecture |
US20020091722A1 (en) * | 2000-03-03 | 2002-07-11 | Surgient Networks, Inc. | Systems and methods for resource management in information storage environments |
US6460055B1 (en) * | 1999-12-16 | 2002-10-01 | Livevault Corporation | Systems and methods for backing up data files |
US20020144177A1 (en) * | 1998-12-10 | 2002-10-03 | Kondo Thomas J. | System recovery from errors for processor and associated components |
US6463565B1 (en) * | 1999-01-05 | 2002-10-08 | Netspeak Corporation | Method for designing object-oriented table driven state machines |
US20020147807A1 (en) * | 1998-01-23 | 2002-10-10 | Domenico Raguseo | Dynamic redirection |
US20020172222A1 (en) * | 2001-03-29 | 2002-11-21 | International Business Machines Corporation | Method and system for network management providing access to application bandwidth usage calculations |
US6487561B1 (en) * | 1998-12-31 | 2002-11-26 | Emc Corporation | Apparatus and methods for copying, backing up, and restoring data using a backup segment size larger than the storage block size |
US6487581B1 (en) * | 1999-05-24 | 2002-11-26 | Hewlett-Packard Company | Apparatus and method for a multi-client event server |
US20020178397A1 (en) * | 2001-05-23 | 2002-11-28 | Hitoshi Ueno | System for managing layered network |
US20020199152A1 (en) * | 2001-06-22 | 2002-12-26 | Garney John I. | Method and apparatus for preservation of failure state in a read destructive memory |
US6519612B1 (en) * | 1996-11-27 | 2003-02-11 | 1Vision Software, Inc. | Internet storage manipulation and navigation system |
US6526418B1 (en) * | 1999-12-16 | 2003-02-25 | Livevault Corporation | Systems and methods for backing up data files |
US20030051026A1 (en) * | 2001-01-19 | 2003-03-13 | Carter Ernst B. | Network surveillance and security system |
US6549916B1 (en) * | 1999-08-05 | 2003-04-15 | Oracle Corporation | Event notification system tied to a file system |
US6611867B1 (en) * | 1999-08-31 | 2003-08-26 | Accenture Llp | System, method and article of manufacture for implementing a hybrid network |
US6625623B1 (en) * | 1999-12-16 | 2003-09-23 | Livevault Corporation | Systems and methods for backing up data files |
US6629109B1 (en) * | 1999-03-05 | 2003-09-30 | Nec Corporation | System and method of enabling file revision management of application software |
US6670974B1 (en) * | 1999-10-12 | 2003-12-30 | Gateway, Inc. | Persistent usage context |
US20040010544A1 (en) * | 2002-06-07 | 2004-01-15 | Slater Alastair Michael | Method of satisfying a demand on a network for a network resource, method of sharing the demand for resources between a plurality of networked resource servers, server network, demand director server, networked data library, method of network resource management, method of satisfying a demand on an internet network for a network resource, tier of resource serving servers, network, demand director, metropolitan video serving network, computer readable memory device encoded with a data structure for managing networked resources, method of making available computer network resources to users of a |
US20040047354A1 (en) * | 2002-06-07 | 2004-03-11 | Slater Alastair Michael | Method of maintaining availability of requested network resources, method of data storage management, method of data storage management in a network, network of resource servers, network, resource management server, content management server, network of video servers, video server, software for controlling the distribution of network resources |
US20040080504A1 (en) * | 1996-03-26 | 2004-04-29 | Pixion, Inc. | Real-time, multi-point, multi-speed, multi-stream scalable computer network communications system |
US6751753B2 (en) * | 2001-02-27 | 2004-06-15 | Sun Microsystems, Inc. | Method, system, and program for monitoring system components |
US6779003B1 (en) * | 1999-12-16 | 2004-08-17 | Livevault Corporation | Systems and methods for backing up data files |
US20040199486A1 (en) * | 2003-04-02 | 2004-10-07 | Sun Microsystems, Inc. | Distributed data system with incremental data updates |
US6816872B1 (en) * | 1990-04-26 | 2004-11-09 | Timespring Software Corporation | Apparatus and method for reconstructing a file from a difference signature and an original file |
US6826711B2 (en) * | 2000-02-18 | 2004-11-30 | Avamar Technologies, Inc. | System and method for data protection with multidimensional parity |
US20040250212A1 (en) * | 2003-05-20 | 2004-12-09 | Fish Edmund J. | User interface for presence and geographic location notification based on group identity |
US6836756B1 (en) * | 2000-11-13 | 2004-12-28 | Nortel Networks Limited | Time simulation techniques to determine network availability |
US6839740B1 (en) * | 2002-12-27 | 2005-01-04 | Veritas Operating Corporation | System and method for performing virtual device I/O operations |
US6847984B1 (en) * | 1999-12-16 | 2005-01-25 | Livevault Corporation | Systems and methods for backing up data files |
US6907551B2 (en) * | 2000-10-02 | 2005-06-14 | Ntt Docomo, Inc. | Fault notification method and related provider facility |
US20050166179A1 (en) * | 2004-01-28 | 2005-07-28 | Vronay David P. | System and method for ordering events |
US20050251540A1 (en) * | 2004-05-10 | 2005-11-10 | Sim-Tang Siew Y | Method and system for real-time event journaling to provide enterprise data services |
US20060020586A1 (en) * | 2000-03-03 | 2006-01-26 | Michel Prompt | System and method for providing access to databases via directories and other hierarchical structures and interfaces |
US6993706B2 (en) * | 2002-01-15 | 2006-01-31 | International Business Machines Corporation | Method, apparatus, and program for a state machine framework |
US20060026220A1 (en) * | 2003-02-26 | 2006-02-02 | Permabit, Inc. | History preservation in a computer storage system |
US7039663B1 (en) * | 2002-04-19 | 2006-05-02 | Network Appliance, Inc. | System and method for checkpointing and restarting an asynchronous transfer of data between a source and destination snapshot |
US7080081B2 (en) * | 2002-04-15 | 2006-07-18 | International Business Machines Corporation | Multidimensional data clustering scheme for query processing and maintenance in relational databases |
US7096392B2 (en) * | 2004-05-07 | 2006-08-22 | Asempra Technologies, Inc. | Method and system for automated, no downtime, real-time, continuous data protection |
US7206805B1 (en) * | 1999-09-09 | 2007-04-17 | Oracle International Corporation | Asynchronous transcription object management system |
US7290056B1 (en) * | 1999-09-09 | 2007-10-30 | Oracle International Corporation | Monitoring latency of a network to manage termination of distributed transactions |
US7325159B2 (en) * | 2004-02-04 | 2008-01-29 | Network Appliance, Inc. | Method and system for data recovery in a continuous data protection system |
Family Cites Families (173)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US252004A (en) * | 1882-01-03 | James a | ||
US252432A (en) * | 1882-01-17 | Rowing-gear | ||
US3555184A (en) | 1964-10-21 | 1971-01-12 | Bell Telephone Labor Inc | Data character assembler |
US3555195A (en) | 1967-10-05 | 1971-01-12 | Rca Corp | Multiplex synchronizing circuit |
US3555251A (en) | 1967-12-06 | 1971-01-12 | Honeywell Inc | Optimizing system for a plurality of temperature conditioning apparatuses |
US3555204A (en) | 1968-01-12 | 1971-01-12 | Ibm | Electronic sweep magnetic scanning transducer |
US3648250A (en) | 1970-11-13 | 1972-03-07 | Nasa | Digital video display system using cathode-ray tube |
US4162536A (en) | 1976-01-02 | 1979-07-24 | Gould Inc., Modicon Div. | Digital input/output system and method |
US4502082A (en) | 1977-06-16 | 1985-02-26 | Burroughs Corporation | Spiral recording and associated system |
NL7909178A (en) | 1979-12-20 | 1981-07-16 | Philips Nv | CALCULATOR WITH DISTRIBUTED REDUNDANCY DISTRIBUTED OVER DIFFERENT INSULATION AREAS FOR ERRORS. |
US4450556A (en) | 1980-10-17 | 1984-05-22 | Northern Telecom Limited | Digital signal subscriber loop and interface circuit |
DE3040171C2 (en) | 1980-10-24 | 1986-05-22 | Max-Josef Dr.-Ing. Zürich Schönhuber | Data registration system for recording the data of certain quantities of goods, in particular milk deliveries |
DE3108891C2 (en) | 1981-03-09 | 1983-03-17 | OBO Bettermann oHG, 5750 Menden | Electric stud welding device Password: Coding |
NL8104342A (en) | 1981-09-21 | 1983-04-18 | Philips Nv | CALCULATOR SYSTEM, BASED ON A SYMBOL-CORRECTING CODE WITH TWO WORKING MODES. |
US4451108A (en) | 1982-08-30 | 1984-05-29 | Skidmore Donald D | Data-terminal service outlet |
US4796260A (en) | 1987-03-30 | 1989-01-03 | Scs Telecom, Inc. | Schilling-Manela forward error correction and detection code method and apparatus |
EP0301282A1 (en) | 1987-07-31 | 1989-02-01 | BBC Brown Boveri AG | Signal transmission method |
US4916450A (en) | 1988-05-12 | 1990-04-10 | Radar Control Systems Corporation | Radar system for headway control of a vehicle |
US4972474A (en) | 1989-05-01 | 1990-11-20 | Cylink Corporation | Integer encryptor |
US5224212A (en) | 1989-05-01 | 1993-06-29 | Motorola, Inc. | Asynchronous operation in a database management system |
DE58908975D1 (en) | 1989-11-21 | 1995-03-16 | Itt Ind Gmbh Deutsche | Two-way data transfer facility. |
US5005197A (en) | 1989-11-30 | 1991-04-02 | Communications Test Design, Inc. | Method and apparatus as for testing a telephone line interface card |
DE69026821T2 (en) | 1990-03-09 | 1996-09-05 | Hewlett Packard Ltd | DEVICE FOR STORING ON A MAGNETIC TAPE |
JP3448051B2 (en) | 1990-03-31 | 2003-09-16 | 株式会社東芝 | Nonvolatile semiconductor memory device |
US5479654A (en) | 1990-04-26 | 1995-12-26 | Squibb Data Systems, Inc. | Apparatus and method for reconstructing a file from a difference signature and an original file |
US5319395A (en) | 1990-05-16 | 1994-06-07 | International Business Machines Corporation | Pixel depth converter for a computer video display |
EP0553277A1 (en) | 1990-10-16 | 1993-08-04 | Motorola, Inc. | Mobile isdn radio system |
US5177796A (en) | 1990-10-19 | 1993-01-05 | International Business Machines Corporation | Image data processing of correlated images |
US5303393A (en) | 1990-11-06 | 1994-04-12 | Radio Satellite Corporation | Integrated radio satellite response system and method |
DE69220108T2 (en) | 1991-03-08 | 1997-09-18 | Fuji Photo Film Co Ltd | Photographic film packaging |
KR960002006B1 (en) | 1991-03-12 | 1996-02-09 | 가부시끼가이샤 도시바 | Eeprom with write/verify controller using two reference levels |
US5148479A (en) | 1991-03-20 | 1992-09-15 | International Business Machines Corp. | Authentication protocols in communication networks |
JP2863653B2 (en) | 1991-07-16 | 1999-03-03 | 三菱電機株式会社 | Microcomputer with built-in communication device |
US5365516A (en) | 1991-08-16 | 1994-11-15 | Pinpoint Communications, Inc. | Communication system and method for determining the location of a transponder unit |
GB9126289D0 (en) | 1991-12-10 | 1992-02-12 | Int Computers Ltd | Computer system |
US6400996B1 (en) * | 1999-02-01 | 2002-06-04 | Steven M. Hoffberg | Adaptive pattern recognition based control system and method |
US5377102A (en) | 1992-03-05 | 1994-12-27 | Nishiishigaki; Kenji | Apparatus for preparing map data with regional properties |
US5305326A (en) | 1992-03-06 | 1994-04-19 | Data General Corporation | High availability disk arrays |
DE69322713T2 (en) | 1992-08-31 | 1999-05-06 | Victor Company Of Japan | Device for orthogonal transformation coding and decoding |
AU4626893A (en) | 1992-09-14 | 1994-03-24 | Aprex Corporation | Contactless communication system |
US5657398A (en) | 1992-10-28 | 1997-08-12 | Protocol Systems, Inc. | High-quality, low-bit-rate method of compressing waveform data |
US5388074A (en) | 1992-12-17 | 1995-02-07 | Vlsi Technology, Inc. | FIFO memory using single output register |
US5392209A (en) | 1992-12-18 | 1995-02-21 | Abbott Laboratories | Method and apparatus for providing a data interface between a plurality of test information sources and a database |
JPH06223201A (en) | 1993-01-22 | 1994-08-12 | Matsushita Electric Ind Co Ltd | Parallel image generating device |
US5311197A (en) | 1993-02-01 | 1994-05-10 | Trimble Navigation Limited | Event-activated reporting of vehicle location |
JPH06275098A (en) | 1993-03-24 | 1994-09-30 | Mitsubishi Electric Corp | Semiconductor memory |
US5373372A (en) | 1993-03-25 | 1994-12-13 | Hewlett-Packard Company | Method and an apparatus for limited variable speed scanning |
US5416831A (en) | 1993-04-15 | 1995-05-16 | Bellsouth Corporation | System for communicating with an ADSI-compatible telephone via a service circuit node |
US5511212A (en) | 1993-06-10 | 1996-04-23 | Rockoff; Todd E. | Multi-clock SIMD computer and instruction-cache-enhancement thereof |
DE69323870T2 (en) | 1993-08-02 | 1999-07-29 | Trw Inc | Modular solid-state mass storage device for video servers |
GB2281644A (en) | 1993-09-02 | 1995-03-08 | Ibm | Fault tolerant transaction-oriented data processing. |
JPH0793893A (en) | 1993-09-24 | 1995-04-07 | Toshiba Corp | Picture information processing device |
US5495607A (en) | 1993-11-15 | 1996-02-27 | Conner Peripherals, Inc. | Network management system having virtual catalog overview of files distributively stored across network domain |
US5440686A (en) | 1993-12-22 | 1995-08-08 | International Business Machines Corporation | Selecting a data unit candidate to be demoted to a backing store from a front store based upon thresholds individual to each of the data candidates |
US5640159A (en) | 1994-01-03 | 1997-06-17 | International Business Machines Corporation | Quantization method for image data compression employing context modeling algorithm |
USRE38410E1 (en) * | 1994-01-31 | 2004-01-27 | Axs Technologies, Inc. | Method and apparatus for a parallel data storage and processing server |
JP3354330B2 (en) | 1994-02-03 | 2002-12-09 | ブラザー工業株式会社 | Sewing data correction device |
US5387994A (en) | 1994-02-14 | 1995-02-07 | Thermo King Corporation | Communications adapter for converting wire-based communication to wireless communication |
US5487581A (en) * | 1994-03-18 | 1996-01-30 | Carmo; Robert A. | Hand grip for carrying heavy plastic bags |
US5602638A (en) | 1994-04-01 | 1997-02-11 | Boulware; Jim L. | Apparatus for accurately determining a moving ball's position and speed |
US5499512A (en) | 1994-05-09 | 1996-03-19 | Thermo King Corporation | Methods and apparatus for converting a manually operable refrigeration unit to remote operation |
US5507024A (en) | 1994-05-16 | 1996-04-09 | Allegro Microsystems, Inc. | FM data-system radio receiver |
US5822749A (en) | 1994-07-12 | 1998-10-13 | Sybase, Inc. | Database system with methods for improving query performance with cache optimization strategies |
US5430830A (en) | 1994-08-22 | 1995-07-04 | Motorola, Inc. | Adaptive weight adjusting circuit for an neural network |
US5560033A (en) | 1994-08-29 | 1996-09-24 | Lucent Technologies Inc. | System for providing automatic power control for highly available n+k processors |
JP3216449B2 (en) | 1994-10-31 | 2001-10-09 | 安藤電気株式会社 | Self-diagnosis device for semiconductor memory failure |
US5980096A (en) | 1995-01-17 | 1999-11-09 | Intertech Ventures, Ltd. | Computer-based system, methods and graphical interface for information storage, modeling and stimulation of complex systems |
US5781612A (en) | 1995-03-10 | 1998-07-14 | Northern Telecom Limited | Radio terminal interfaces for voice and data telecommunications, and methods for their operation |
US5742509A (en) | 1995-04-11 | 1998-04-21 | Trimble Navigation Limited | Personal tracking system integrated with base station |
US5854834A (en) | 1995-04-21 | 1998-12-29 | Mci Communications Corporation | Network information concentrator |
US5606601A (en) | 1995-05-10 | 1997-02-25 | Mci Communications Corporation | Centralizing storage and verification element for telephone network |
US5627855A (en) | 1995-05-25 | 1997-05-06 | Golden Bridge Technology, Inc. | Programmable two-part matched filter for spread spectrum |
US5644763A (en) | 1995-06-28 | 1997-07-01 | Sybase, Inc. | Database system with improved methods for B-tree maintenance |
US5841771A (en) | 1995-07-07 | 1998-11-24 | Northern Telecom Limited | Telecommunications switch apparatus and method for time switching |
US5862136A (en) | 1995-07-07 | 1999-01-19 | Northern Telecom Limited | Telecommunications apparatus and method |
US5737399A (en) | 1995-07-13 | 1998-04-07 | Mci Communications Corporation | Network information architecture having centralizing storage and verification element |
US5848072A (en) | 1995-08-10 | 1998-12-08 | Motorola, Inc. | Method of and apparatus for communicating messages |
US5778370A (en) | 1995-08-25 | 1998-07-07 | Emerson; Mark L. | Data village system |
US5930732A (en) | 1995-09-15 | 1999-07-27 | Accumed International, Inc. | System for simplifying the implementation of specified functions |
US5684693A (en) | 1995-11-14 | 1997-11-04 | Western Atlas International, Inc. | Method for bit-stream data compression |
US5742915A (en) | 1995-12-13 | 1998-04-21 | Caterpillar Inc. | Position referenced data for monitoring and controlling |
JP3461076B2 (en) | 1995-12-28 | 2003-10-27 | 富士通株式会社 | Charged particle beam exposure apparatus and method capable of reading data at high speed |
US5724241A (en) | 1996-01-11 | 1998-03-03 | Western Atlas International, Inc. | Distributed seismic data-gathering system |
US5754772A (en) | 1996-03-26 | 1998-05-19 | Unisys Corporation | Transaction service independent HTTP server-to-transaction gateway |
US5768159A (en) | 1996-05-02 | 1998-06-16 | Northern Telecom Limited | Method of simulating AC timing characteristics of integrated circuits |
US5928327A (en) | 1996-08-08 | 1999-07-27 | Wang; Pong-Sheng | System and process for delivering digital data on demand |
US5784366A (en) | 1996-08-27 | 1998-07-21 | Transsky Corp. | Wideband code-division-multiple access system and method |
US5930762A (en) | 1996-09-24 | 1999-07-27 | Rco Software Limited | Computer aided risk management in multiple-parameter physical systems |
US5805798A (en) | 1996-10-29 | 1998-09-08 | Electronic Data Systems Corporation | Fail-safe event driven transaction processing system and method |
US6035297A (en) | 1996-12-06 | 2000-03-07 | International Business Machines Machine | Data management system for concurrent engineering |
US5864875A (en) | 1996-12-06 | 1999-01-26 | International Business Machines Corporation | Data management system for problems, releases and parts |
US6088693A (en) | 1996-12-06 | 2000-07-11 | International Business Machines Corporation | Data management system for file and database management |
US5878408A (en) | 1996-12-06 | 1999-03-02 | International Business Machines Corporation | Data management system and process |
US5950201A (en) | 1996-12-06 | 1999-09-07 | International Business Machines Corporation | Computerized design automation method using a single logical PFVL paradigm |
US5920867A (en) | 1996-12-06 | 1999-07-06 | International Business Machines Corporation | Data management system having data management configuration |
US5826265A (en) | 1996-12-06 | 1998-10-20 | International Business Machines Corporation | Data management system having shared libraries |
US5920873A (en) | 1996-12-06 | 1999-07-06 | International Business Machines Corporation | Data management control system for file and database |
US5812130A (en) * | 1996-12-06 | 1998-09-22 | International Business Machines Corporation | Data management system and method for concurrent engineering |
JP3720934B2 (en) | 1996-12-17 | 2005-11-30 | 富士通株式会社 | Semiconductor memory device and data read / write method |
US5918248A (en) | 1996-12-30 | 1999-06-29 | Northern Telecom Limited | Shared memory control algorithm for mutual exclusion and rollback |
US6108318A (en) | 1997-03-04 | 2000-08-22 | Ericsson Inc | System and method for data link synchronization |
US5958010A (en) | 1997-03-20 | 1999-09-28 | Firstsense Software, Inc. | Systems and methods for monitoring distributed applications including an interface running in an operating system kernel |
US5805155A (en) | 1997-04-15 | 1998-09-08 | Time Warner Entertainment Co. L.P. Time Warner Cable | Virtual assets in an interactive television cable system |
US6031848A (en) | 1997-05-07 | 2000-02-29 | 3Com Corporation | Apparatus for an improved ISDN terminal adapter having baud rate unblocking and methods for use therein |
US6005846A (en) | 1997-05-07 | 1999-12-21 | 3Com Corporation | Apparatus for an improved ISDN terminal adapter having automatic SPID configuration and methods for use therein |
US5931928A (en) | 1997-05-07 | 1999-08-03 | 3Com Corporaton | System for ISDN terminal adapter DCE for automatically negotiating data compression with it's PPP peer when DTE is unable or unwilling to negotiate compression |
US5937168A (en) | 1997-05-30 | 1999-08-10 | Bellsouth Corporation | Routing information within an adaptive routing architecture of an information retrieval system |
DE69802294T2 (en) | 1997-08-29 | 2002-05-16 | Hewlett Packard Co | SYSTEMS FOR DATA BACKUP AND RECOVERY |
US6108410A (en) | 1997-09-16 | 2000-08-22 | Nynex Science And Technology Inc. | Methods and apparatus for automating the detection, reporting and correction of operator input errors |
US5894494A (en) | 1997-10-29 | 1999-04-13 | Golden Bridge Technology, Inc. | Parallel correlator architecture for synchronizing direct sequence spread-spectrum signals |
JP3917734B2 (en) | 1997-11-07 | 2007-05-23 | 富士通株式会社 | Semiconductor memory device |
US5940823A (en) | 1997-11-10 | 1999-08-17 | International Business Machines Corporation | System for the distribution and storage of electronic mail information |
US5966707A (en) | 1997-12-02 | 1999-10-12 | International Business Machines Corporation | Method for managing a plurality of data processes residing in heterogeneous data repositories |
US6178121B1 (en) | 1997-12-11 | 2001-01-23 | Seiko Epson Corporation | Semiconductor memory device, semiconductor device, and electronic apparatus using the semiconductor device |
US5877742A (en) | 1997-12-11 | 1999-03-02 | Klink; James | Medical identification bracelet |
US5953729A (en) | 1997-12-23 | 1999-09-14 | Microsoft Corporation | Using sparse file technology to stage data that will then be stored in remote storage |
US6065018A (en) | 1998-03-04 | 2000-05-16 | International Business Machines Corporation | Synchronizing recovery log having time stamp to a remote site for disaster recovery of a primary database having related hierarchial and relational databases |
US6397242B1 (en) | 1998-05-15 | 2002-05-28 | Vmware, Inc. | Virtualization system including a virtual machine monitor for a computer with a segmented architecture |
US6243348B1 (en) | 1998-06-05 | 2001-06-05 | Massachusetts Institute Of Technology | Very-high-density memory device utilizing a scintillating data-storage medium |
US20010056362A1 (en) * | 1998-07-29 | 2001-12-27 | Mike Hanagan | Modular, convergent customer care and billing system |
JP3076309B2 (en) | 1998-09-17 | 2000-08-14 | 日本電気アイシーマイコンシステム株式会社 | Semiconductor storage device |
US6249824B1 (en) | 1998-12-12 | 2001-06-19 | Joseph Reid Henrichs | Magnetic data storage fixed hard disk drive using stationary microhead array chips in place of flying-heads and rotary voice-coil actuators |
US6366926B1 (en) | 1998-12-31 | 2002-04-02 | Computer Associates Think, Inc. | Method and apparatus for the dynamic filtering and routing of events |
US6446136B1 (en) | 1998-12-31 | 2002-09-03 | Computer Associates Think, Inc. | System and method for dynamic correlation of events |
US6502133B1 (en) | 1999-03-25 | 2002-12-31 | Lucent Technologies Inc. | Real-time event processing system with analysis engine using recovery information |
US6496944B1 (en) | 1999-10-06 | 2002-12-17 | International Business Machines Corporation | Method for database assisted file system restore |
US6807550B1 (en) * | 1999-12-01 | 2004-10-19 | Microsoft Corporation | Methods and systems for providing random access to structured media content |
US7636665B2 (en) | 2000-01-04 | 2009-12-22 | Intuit Inc. | Method and system for remotely managing business and employee administration functions |
US7240099B2 (en) | 2000-03-06 | 2007-07-03 | Sony Corporation | System and method for efficiently performing data transfer operations |
KR100341335B1 (en) | 2000-05-18 | 2002-06-22 | 윤종용 | Optical disc player and a method for recording information on a disc of the optical disc player or a method for playing the optical disc player |
US6769074B2 (en) | 2000-05-25 | 2004-07-27 | Lumigent Technologies, Inc. | System and method for transaction-selective rollback reconstruction of database objects |
US7386610B1 (en) | 2000-09-18 | 2008-06-10 | Hewlett-Packard Development Company, L.P. | Internet protocol data mirroring |
US6823336B1 (en) | 2000-09-26 | 2004-11-23 | Emc Corporation | Data storage system and method for uninterrupted read-only access to a consistent dataset by one host processor concurrent with read-write access by another host processor |
ATE381191T1 (en) | 2000-10-26 | 2007-12-15 | Prismedia Networks Inc | METHOD AND SYSTEM FOR MANAGING DISTRIBUTED CONTENT AND CORRESPONDING METADATA |
US6735595B2 (en) | 2000-11-29 | 2004-05-11 | Hewlett-Packard Development Company, L.P. | Data structure and storage and retrieval method supporting ordinality based searching and data retrieval |
US6839721B2 (en) | 2001-01-12 | 2005-01-04 | Hewlett-Packard Development Company, L.P. | Integration of a database into file management software for protecting, tracking, and retrieving data |
DE60140902D1 (en) | 2001-05-30 | 2010-02-04 | Opentv Inc | DEMANDED INTERACTIVE MAGAZINE |
KR100436365B1 (en) | 2001-06-23 | 2004-06-18 | 삼성전자주식회사 | ATM-based delay adaptive scheduling apparatus according to traffic types and method thereof |
US20030004947A1 (en) * | 2001-06-28 | 2003-01-02 | Sun Microsystems, Inc. | Method, system, and program for managing files in a file system |
US20030009552A1 (en) | 2001-06-29 | 2003-01-09 | International Business Machines Corporation | Method and system for network management with topology system providing historical topological views |
US20030088372A1 (en) | 2001-11-02 | 2003-05-08 | Caulfield David D | Array calibration and quality assurance |
US6961860B2 (en) | 2001-12-07 | 2005-11-01 | Nokia Corporation | Method and system for optimizing power consumption during data read/write operation in disk-based memory |
JP2005515556A (en) | 2002-01-15 | 2005-05-26 | ネットワーク アプライアンス, インコーポレイテッド | Active file change notification |
US7287033B2 (en) | 2002-03-06 | 2007-10-23 | Ori Software Development, Ltd. | Efficient traversals over hierarchical data and indexing semistructured data |
US7644392B2 (en) | 2002-04-12 | 2010-01-05 | Telelogic Technologies North America, Inc. | System and method for active configuration management |
US7546382B2 (en) * | 2002-05-28 | 2009-06-09 | International Business Machines Corporation | Methods and systems for authoring of mixed-initiative multi-modal interactions and related browsing mechanisms |
US7246128B2 (en) | 2002-06-12 | 2007-07-17 | Jordahl Jena J | Data storage, retrieval, manipulation and display tools enabling multiple hierarchical points of view |
AU2003262015A1 (en) | 2002-09-09 | 2004-04-30 | Catena Corporation | Requirement defining method, method for developing software, method for changing requirement word, and newly defining method |
US7430616B2 (en) * | 2002-09-16 | 2008-09-30 | Clearcube Technology, Inc. | System and method for reducing user-application interactions to archivable form |
KR100532325B1 (en) | 2002-11-23 | 2005-11-29 | 삼성전자주식회사 | Input control method and apparatus for turbo decoder |
US7200233B1 (en) | 2002-12-10 | 2007-04-03 | L-3 Communications Corporation | System and method for fast data encryption/decryption using time slot numbering |
US7376754B2 (en) | 2003-02-27 | 2008-05-20 | Bea Systems, Inc. | System and method for communications between servers in a cluster |
US7499925B2 (en) | 2003-03-27 | 2009-03-03 | Microsoft Corporation | File system for displaying items of different types and from different physical locations |
JP4289045B2 (en) | 2003-07-01 | 2009-07-01 | 株式会社ニコン | Electronic still camera, electronic still camera system and program |
US20050240592A1 (en) * | 2003-08-27 | 2005-10-27 | Ascential Software Corporation | Real time data integration for supply chain management |
US7814470B2 (en) * | 2003-08-27 | 2010-10-12 | International Business Machines Corporation | Multiple service bindings for a real time data integration service |
US8417673B2 (en) | 2003-10-07 | 2013-04-09 | International Business Machines Corporation | Method, system, and program for retaining versions of files |
US8108429B2 (en) | 2004-05-07 | 2012-01-31 | Quest Software, Inc. | System for moving real-time data events across a plurality of devices in a network for simultaneous data protection, replication, and access services |
US7519870B1 (en) | 2004-06-08 | 2009-04-14 | Asempra Technologies, Inc. | Method and system for no downtime, initial data upload for real-time, continuous data protection |
WO2006012211A2 (en) | 2004-06-24 | 2006-02-02 | Meshnetworks, Inc. | A system and method for adaptive rate selection for wireless networks |
US7983160B2 (en) | 2004-09-08 | 2011-07-19 | Sony Corporation | Method and apparatus for transmitting a coded video signal |
US7979404B2 (en) | 2004-09-17 | 2011-07-12 | Quest Software, Inc. | Extracting data changes and storing data history to allow for instantaneous access to and reconstruction of any point-in-time data |
KR100664306B1 (en) | 2004-10-29 | 2007-01-04 | 삼성전자주식회사 | Apparatus and method of generating and detecting the prevention and control data for verifying the validity of a data |
US7904913B2 (en) | 2004-11-02 | 2011-03-08 | Bakbone Software, Inc. | Management interface for a system that provides automated, real-time, continuous data protection |
US20060236149A1 (en) | 2005-04-14 | 2006-10-19 | Dell Products L.P. | System and method for rebuilding a storage disk |
US7274313B2 (en) | 2005-05-13 | 2007-09-25 | Texas Instruments Incorporated | High speed data recording with input duty cycle distortion |
US7207224B2 (en) | 2005-06-10 | 2007-04-24 | Brooks Automation, Inc. | Wide-range combination vacuum gauge |
US7689602B1 (en) | 2005-07-20 | 2010-03-30 | Bakbone Software, Inc. | Method of creating hierarchical indices for a distributed object system |
US7788521B1 (en) | 2005-07-20 | 2010-08-31 | Bakbone Software, Inc. | Method and system for virtual on-demand recovery for real-time, continuous data protection |
US20070067278A1 (en) | 2005-09-22 | 2007-03-22 | Gtess Corporation | Data file correlation system and method |
US7634679B2 (en) | 2005-11-30 | 2009-12-15 | Microsoft Corporation | Remote location failover server application |
US7555502B2 (en) | 2006-03-10 | 2009-06-30 | Oracle International Corporation | Detecting database events using recovery logs |
US8131723B2 (en) | 2007-03-30 | 2012-03-06 | Quest Software, Inc. | Recovering a file system to any point-in-time in the past with guaranteed structure, content consistency and integrity |
-
2005
- 2005-05-06 US US11/123,994 patent/US8108429B2/en active Active
- 2005-05-07 EP EP05746701A patent/EP1745362A4/en not_active Withdrawn
- 2005-05-07 WO PCT/US2005/015662 patent/WO2005111788A2/en active Application Filing
-
2006
- 2006-12-13 US US11/638,253 patent/US20070094312A1/en not_active Abandoned
Patent Citations (58)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5287504A (en) * | 1989-08-01 | 1994-02-15 | Silicon Graphics, Inc. | File alteration monitor for computer operating and file management system |
US6816872B1 (en) * | 1990-04-26 | 2004-11-09 | Timespring Software Corporation | Apparatus and method for reconstructing a file from a difference signature and an original file |
US5794252A (en) * | 1995-01-24 | 1998-08-11 | Tandem Computers, Inc. | Remote duplicate database facility featuring safe master audit trail (safeMAT) checkpointing |
US5819020A (en) * | 1995-10-16 | 1998-10-06 | Network Specialists, Inc. | Real time backup system |
US5974563A (en) * | 1995-10-16 | 1999-10-26 | Network Specialists, Inc. | Real time backup system |
US6047323A (en) * | 1995-10-19 | 2000-04-04 | Hewlett-Packard Company | Creation and migration of distributed streams in clusters of networked computers |
US5729743A (en) * | 1995-11-17 | 1998-03-17 | Deltatech Research, Inc. | Computer apparatus and method for merging system deltas |
US5893119A (en) * | 1995-11-17 | 1999-04-06 | Deltatech Research, Inc. | Computer apparatus and method for merging system deltas |
US20040080504A1 (en) * | 1996-03-26 | 2004-04-29 | Pixion, Inc. | Real-time, multi-point, multi-speed, multi-stream scalable computer network communications system |
US6519612B1 (en) * | 1996-11-27 | 2003-02-11 | 1Vision Software, Inc. | Internet storage manipulation and navigation system |
US6158019A (en) * | 1996-12-15 | 2000-12-05 | Delta-Tek Research, Inc. | System and apparatus for merging a write event journal and an original storage to produce an updated storage using an event map |
US6366988B1 (en) * | 1997-07-18 | 2002-04-02 | Storactive, Inc. | Systems and methods for electronic data storage management |
US20020147807A1 (en) * | 1998-01-23 | 2002-10-10 | Domenico Raguseo | Dynamic redirection |
US6389427B1 (en) * | 1998-02-20 | 2002-05-14 | Redleaf Group, Inc. | File system performance enhancement |
US6163856A (en) * | 1998-05-29 | 2000-12-19 | Sun Microsystems, Inc. | Method and apparatus for file system disaster recovery |
US6189016B1 (en) * | 1998-06-12 | 2001-02-13 | Microsoft Corporation | Journaling ordered changes in a storage volume |
US6393582B1 (en) * | 1998-12-10 | 2002-05-21 | Compaq Computer Corporation | Error self-checking and recovery using lock-step processor pair architecture |
US20020144177A1 (en) * | 1998-12-10 | 2002-10-03 | Kondo Thomas J. | System recovery from errors for processor and associated components |
US6487561B1 (en) * | 1998-12-31 | 2002-11-26 | Emc Corporation | Apparatus and methods for copying, backing up, and restoring data using a backup segment size larger than the storage block size |
US6463565B1 (en) * | 1999-01-05 | 2002-10-08 | Netspeak Corporation | Method for designing object-oriented table driven state machines |
US6629109B1 (en) * | 1999-03-05 | 2003-09-30 | Nec Corporation | System and method of enabling file revision management of application software |
US6487581B1 (en) * | 1999-05-24 | 2002-11-26 | Hewlett-Packard Company | Apparatus and method for a multi-client event server |
US6549916B1 (en) * | 1999-08-05 | 2003-04-15 | Oracle Corporation | Event notification system tied to a file system |
US6611867B1 (en) * | 1999-08-31 | 2003-08-26 | Accenture Llp | System, method and article of manufacture for implementing a hybrid network |
US7206805B1 (en) * | 1999-09-09 | 2007-04-17 | Oracle International Corporation | Asynchronous transcription object management system |
US7290056B1 (en) * | 1999-09-09 | 2007-10-30 | Oracle International Corporation | Monitoring latency of a network to manage termination of distributed transactions |
US6670974B1 (en) * | 1999-10-12 | 2003-12-30 | Gateway, Inc. | Persistent usage context |
US6460055B1 (en) * | 1999-12-16 | 2002-10-01 | Livevault Corporation | Systems and methods for backing up data files |
US6847984B1 (en) * | 1999-12-16 | 2005-01-25 | Livevault Corporation | Systems and methods for backing up data files |
US6625623B1 (en) * | 1999-12-16 | 2003-09-23 | Livevault Corporation | Systems and methods for backing up data files |
US6526418B1 (en) * | 1999-12-16 | 2003-02-25 | Livevault Corporation | Systems and methods for backing up data files |
US6779003B1 (en) * | 1999-12-16 | 2004-08-17 | Livevault Corporation | Systems and methods for backing up data files |
US6826711B2 (en) * | 2000-02-18 | 2004-11-30 | Avamar Technologies, Inc. | System and method for data protection with multidimensional parity |
US20060020586A1 (en) * | 2000-03-03 | 2006-01-26 | Michel Prompt | System and method for providing access to databases via directories and other hierarchical structures and interfaces |
US20020091722A1 (en) * | 2000-03-03 | 2002-07-11 | Surgient Networks, Inc. | Systems and methods for resource management in information storage environments |
US6907551B2 (en) * | 2000-10-02 | 2005-06-14 | Ntt Docomo, Inc. | Fault notification method and related provider facility |
US6836756B1 (en) * | 2000-11-13 | 2004-12-28 | Nortel Networks Limited | Time simulation techniques to determine network availability |
US20030051026A1 (en) * | 2001-01-19 | 2003-03-13 | Carter Ernst B. | Network surveillance and security system |
US6751753B2 (en) * | 2001-02-27 | 2004-06-15 | Sun Microsystems, Inc. | Method, system, and program for monitoring system components |
US20020172222A1 (en) * | 2001-03-29 | 2002-11-21 | International Business Machines Corporation | Method and system for network management providing access to application bandwidth usage calculations |
US20020178397A1 (en) * | 2001-05-23 | 2002-11-28 | Hitoshi Ueno | System for managing layered network |
US20020199152A1 (en) * | 2001-06-22 | 2002-12-26 | Garney John I. | Method and apparatus for preservation of failure state in a read destructive memory |
US6993706B2 (en) * | 2002-01-15 | 2006-01-31 | International Business Machines Corporation | Method, apparatus, and program for a state machine framework |
US7080081B2 (en) * | 2002-04-15 | 2006-07-18 | International Business Machines Corporation | Multidimensional data clustering scheme for query processing and maintenance in relational databases |
US7039663B1 (en) * | 2002-04-19 | 2006-05-02 | Network Appliance, Inc. | System and method for checkpointing and restarting an asynchronous transfer of data between a source and destination snapshot |
US20040010544A1 (en) * | 2002-06-07 | 2004-01-15 | Slater Alastair Michael | Method of satisfying a demand on a network for a network resource, method of sharing the demand for resources between a plurality of networked resource servers, server network, demand director server, networked data library, method of network resource management, method of satisfying a demand on an internet network for a network resource, tier of resource serving servers, network, demand director, metropolitan video serving network, computer readable memory device encoded with a data structure for managing networked resources, method of making available computer network resources to users of a |
US20040047354A1 (en) * | 2002-06-07 | 2004-03-11 | Slater Alastair Michael | Method of maintaining availability of requested network resources, method of data storage management, method of data storage management in a network, network of resource servers, network, resource management server, content management server, network of video servers, video server, software for controlling the distribution of network resources |
US7028078B1 (en) * | 2002-12-27 | 2006-04-11 | Veritas Operating Corporation | System and method for performing virtual device I/O operations |
US6839740B1 (en) * | 2002-12-27 | 2005-01-04 | Veritas Operating Corporation | System and method for performing virtual device I/O operations |
US20060026220A1 (en) * | 2003-02-26 | 2006-02-02 | Permabit, Inc. | History preservation in a computer storage system |
US20040199486A1 (en) * | 2003-04-02 | 2004-10-07 | Sun Microsystems, Inc. | Distributed data system with incremental data updates |
US20040250212A1 (en) * | 2003-05-20 | 2004-12-09 | Fish Edmund J. | User interface for presence and geographic location notification based on group identity |
US20050166179A1 (en) * | 2004-01-28 | 2005-07-28 | Vronay David P. | System and method for ordering events |
US7325159B2 (en) * | 2004-02-04 | 2008-01-29 | Network Appliance, Inc. | Method and system for data recovery in a continuous data protection system |
US7096392B2 (en) * | 2004-05-07 | 2006-08-22 | Asempra Technologies, Inc. | Method and system for automated, no downtime, real-time, continuous data protection |
US7363549B2 (en) * | 2004-05-07 | 2008-04-22 | Asempra Technologies, Inc. | Method and system for automated, no downtime, real-time, continuous data protection |
US20050251540A1 (en) * | 2004-05-10 | 2005-11-10 | Sim-Tang Siew Y | Method and system for real-time event journaling to provide enterprise data services |
US7565661B2 (en) * | 2004-05-10 | 2009-07-21 | Siew Yong Sim-Tang | Method and system for real-time event journaling to provide enterprise data services |
Cited By (215)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8234477B2 (en) | 1998-07-31 | 2012-07-31 | Kom Networks, Inc. | Method and system for providing restricted access to a storage medium |
US9361243B2 (en) | 1998-07-31 | 2016-06-07 | Kom Networks Inc. | Method and system for providing restricted access to a storage medium |
US20090271586A1 (en) * | 1998-07-31 | 2009-10-29 | Kom Networks Inc. | Method and system for providing restricted access to a storage medium |
US20080263112A1 (en) * | 1999-05-18 | 2008-10-23 | Kom Inc. | Method and system for electronic file lifecycle management |
US8782009B2 (en) | 1999-05-18 | 2014-07-15 | Kom Networks Inc. | Method and system for electronic file lifecycle management |
US20050262097A1 (en) * | 2004-05-07 | 2005-11-24 | Sim-Tang Siew Y | System for moving real-time data events across a plurality of devices in a network for simultaneous data protection, replication, and access services |
US8108429B2 (en) | 2004-05-07 | 2012-01-31 | Quest Software, Inc. | System for moving real-time data events across a plurality of devices in a network for simultaneous data protection, replication, and access services |
US8060889B2 (en) | 2004-05-10 | 2011-11-15 | Quest Software, Inc. | Method and system for real-time event journaling to provide enterprise data services |
US7680834B1 (en) | 2004-06-08 | 2010-03-16 | Bakbone Software, Inc. | Method and system for no downtime resychronization for real-time, continuous data protection |
US20100198788A1 (en) * | 2004-06-08 | 2010-08-05 | Siew Yong Sim-Tang | Method and system for no downtime resynchronization for real-time, continuous data protection |
US7979404B2 (en) | 2004-09-17 | 2011-07-12 | Quest Software, Inc. | Extracting data changes and storing data history to allow for instantaneous access to and reconstruction of any point-in-time data |
US8650167B2 (en) | 2004-09-17 | 2014-02-11 | Dell Software Inc. | Method and system for data reduction |
US8195628B2 (en) | 2004-09-17 | 2012-06-05 | Quest Software, Inc. | Method and system for data reduction |
US7657543B1 (en) | 2004-10-12 | 2010-02-02 | Sun Microsystems, Inc. | Method and system for creating and using shadow roots |
US7778970B1 (en) * | 2004-10-12 | 2010-08-17 | Oracle America, Inc. | Method and system for managing independent object evolution |
US7590632B1 (en) * | 2004-10-12 | 2009-09-15 | Sun Microsystems, Inc. | Method for serializer maintenance and coalescing |
US8544023B2 (en) | 2004-11-02 | 2013-09-24 | Dell Software Inc. | Management interface for a system that provides automated, real-time, continuous data protection |
US7904913B2 (en) | 2004-11-02 | 2011-03-08 | Bakbone Software, Inc. | Management interface for a system that provides automated, real-time, continuous data protection |
US20060101384A1 (en) * | 2004-11-02 | 2006-05-11 | Sim-Tang Siew Y | Management interface for a system that provides automated, real-time, continuous data protection |
US20060288050A1 (en) * | 2005-06-15 | 2006-12-21 | International Business Machines Corporation | Method, system, and computer program product for correlating directory changes to access control modifications |
US20100146004A1 (en) * | 2005-07-20 | 2010-06-10 | Siew Yong Sim-Tang | Method Of Creating Hierarchical Indices For A Distributed Object System |
US7979441B2 (en) | 2005-07-20 | 2011-07-12 | Quest Software, Inc. | Method of creating hierarchical indices for a distributed object system |
US7689602B1 (en) | 2005-07-20 | 2010-03-30 | Bakbone Software, Inc. | Method of creating hierarchical indices for a distributed object system |
US8365017B2 (en) * | 2005-07-20 | 2013-01-29 | Quest Software, Inc. | Method and system for virtual on-demand recovery |
US8429198B1 (en) | 2005-07-20 | 2013-04-23 | Quest Software, Inc. | Method of creating hierarchical indices for a distributed object system |
US20120266019A1 (en) * | 2005-07-20 | 2012-10-18 | Quest Software, Inc. | Method and system for virtual on-demand recovery |
US7788521B1 (en) | 2005-07-20 | 2010-08-31 | Bakbone Software, Inc. | Method and system for virtual on-demand recovery for real-time, continuous data protection |
US8200706B1 (en) | 2005-07-20 | 2012-06-12 | Quest Software, Inc. | Method of creating hierarchical indices for a distributed object system |
US8151140B2 (en) | 2005-07-20 | 2012-04-03 | Quest Software, Inc. | Method and system for virtual on-demand recovery for real-time, continuous data protection |
US8639974B1 (en) | 2005-07-20 | 2014-01-28 | Dell Software Inc. | Method and system for virtual on-demand recovery |
US8375248B2 (en) | 2005-07-20 | 2013-02-12 | Quest Software, Inc. | Method and system for virtual on-demand recovery |
US8903763B2 (en) * | 2006-02-21 | 2014-12-02 | International Business Machines Corporation | Method, system, and program product for transferring document attributes |
US9170999B2 (en) | 2006-02-21 | 2015-10-27 | International Business Machines Corporation | Method, system, and program product for transferring document attributes |
US20070198555A1 (en) * | 2006-02-21 | 2007-08-23 | International Business Machines Corporation | Method, system, and program product for transferring document attributes |
US20070214382A1 (en) * | 2006-03-09 | 2007-09-13 | Kabushiki Kaisha Toshiba | Portable terminal |
US20080004549A1 (en) * | 2006-06-12 | 2008-01-03 | Anderson Paul J | Negative pressure wound treatment device, and methods |
US8504527B2 (en) | 2006-08-04 | 2013-08-06 | Apple Inc. | Application-based backup-restore of electronic information |
US20110083098A1 (en) * | 2006-08-04 | 2011-04-07 | Apple Inc. | User Interface For Backup Management |
US9009115B2 (en) | 2006-08-04 | 2015-04-14 | Apple Inc. | Restoring electronic information |
US8775378B2 (en) | 2006-08-04 | 2014-07-08 | Apple Inc. | Consistent backup of electronic information |
US20080034039A1 (en) * | 2006-08-04 | 2008-02-07 | Pavel Cisler | Application-based backup-restore of electronic information |
US8495024B2 (en) | 2006-08-04 | 2013-07-23 | Apple Inc. | Navigation of electronic backups |
US8311988B2 (en) | 2006-08-04 | 2012-11-13 | Apple Inc. | Consistent back up of electronic information |
US8370853B2 (en) | 2006-08-04 | 2013-02-05 | Apple Inc. | Event notification management |
US20080034013A1 (en) * | 2006-08-04 | 2008-02-07 | Pavel Cisler | User interface for backup management |
US20080126442A1 (en) * | 2006-08-04 | 2008-05-29 | Pavel Cisler | Architecture for back up and/or recovery of electronic data |
US20080126441A1 (en) * | 2006-08-04 | 2008-05-29 | Dominic Giampaolo | Event notification management |
US20080059894A1 (en) * | 2006-08-04 | 2008-03-06 | Pavel Cisler | Conflict resolution in recovery of electronic data |
US7809687B2 (en) | 2006-08-04 | 2010-10-05 | Apple Inc. | Searching a backup archive |
US7809688B2 (en) | 2006-08-04 | 2010-10-05 | Apple Inc. | Managing backup of content |
US8166415B2 (en) | 2006-08-04 | 2012-04-24 | Apple Inc. | User interface for backup management |
US7853566B2 (en) | 2006-08-04 | 2010-12-14 | Apple Inc. | Navigation of electronic backups |
US7853567B2 (en) | 2006-08-04 | 2010-12-14 | Apple Inc. | Conflict resolution in recovery of electronic data |
US7856424B2 (en) | 2006-08-04 | 2010-12-21 | Apple Inc. | User interface for backup management |
US7860839B2 (en) | 2006-08-04 | 2010-12-28 | Apple Inc. | Application-based backup-restore of electronic information |
US20080034327A1 (en) * | 2006-08-04 | 2008-02-07 | Pavel Cisler | Navigation of electronic backups |
US20080033922A1 (en) * | 2006-08-04 | 2008-02-07 | Pavel Cisler | Searching a backup archive |
US20080034017A1 (en) * | 2006-08-04 | 2008-02-07 | Dominic Giampaolo | Links to a common item in a data structure |
US8538927B2 (en) | 2006-08-04 | 2013-09-17 | Apple Inc. | User interface for backup management |
US20110087976A1 (en) * | 2006-08-04 | 2011-04-14 | Apple Inc. | Application-Based Backup-Restore Of Electronic Information |
US20080034004A1 (en) * | 2006-08-04 | 2008-02-07 | Pavel Cisler | System for electronic backup |
US20080034018A1 (en) * | 2006-08-04 | 2008-02-07 | Pavel Cisler | Managing backup of content |
US20080034307A1 (en) * | 2006-08-04 | 2008-02-07 | Pavel Cisler | User interface for backup management |
US20080034011A1 (en) * | 2006-08-04 | 2008-02-07 | Pavel Cisler | Restoring electronic information |
US9715394B2 (en) | 2006-08-04 | 2017-07-25 | Apple Inc. | User interface for backup management |
US20080183773A1 (en) * | 2007-01-31 | 2008-07-31 | Jack Choy | Summarizing file system operations with a file system journal |
US8874517B2 (en) * | 2007-01-31 | 2014-10-28 | Hewlett-Packard Development Company, L.P. | Summarizing file system operations with a file system journal |
US8131723B2 (en) | 2007-03-30 | 2012-03-06 | Quest Software, Inc. | Recovering a file system to any point-in-time in the past with guaranteed structure, content consistency and integrity |
US8972347B1 (en) * | 2007-03-30 | 2015-03-03 | Dell Software Inc. | Recovering a file system to any point-in-time in the past with guaranteed structure, content consistency and integrity |
US8352523B1 (en) * | 2007-03-30 | 2013-01-08 | Quest Software, Inc. | Recovering a file system to any point-in-time in the past with guaranteed structure, content consistency and integrity |
US8712970B1 (en) | 2007-04-09 | 2014-04-29 | Dell Software Inc. | Recovering a database to any point-in-time in the past with guaranteed data consistency |
US8364648B1 (en) | 2007-04-09 | 2013-01-29 | Quest Software, Inc. | Recovering a database to any point-in-time in the past with guaranteed data consistency |
US8099392B2 (en) | 2007-06-08 | 2012-01-17 | Apple Inc. | Electronic backup of applications |
US20080307017A1 (en) * | 2007-06-08 | 2008-12-11 | Apple Inc. | Searching and Restoring of Backups |
US9360995B2 (en) | 2007-06-08 | 2016-06-07 | Apple Inc. | User interface for electronic backup |
US9454587B2 (en) | 2007-06-08 | 2016-09-27 | Apple Inc. | Searching and restoring of backups |
US8725965B2 (en) | 2007-06-08 | 2014-05-13 | Apple Inc. | System setup for electronic backup |
US20080307333A1 (en) * | 2007-06-08 | 2008-12-11 | Mcinerney Peter | Deletion in Electronic Backups |
US20090254591A1 (en) * | 2007-06-08 | 2009-10-08 | Apple Inc. | Manipulating Electronic Backups |
US8429425B2 (en) | 2007-06-08 | 2013-04-23 | Apple Inc. | Electronic backup and restoration of encrypted data |
US10891020B2 (en) | 2007-06-08 | 2021-01-12 | Apple Inc. | User interface for electronic backup |
US8745523B2 (en) | 2007-06-08 | 2014-06-03 | Apple Inc. | Deletion in electronic backups |
US9354982B2 (en) | 2007-06-08 | 2016-05-31 | Apple Inc. | Manipulating electronic backups |
US8965929B2 (en) | 2007-06-08 | 2015-02-24 | Apple Inc. | Manipulating electronic backups |
US8566289B2 (en) | 2007-06-08 | 2013-10-22 | Apple Inc. | Electronic backup of applications |
US8468136B2 (en) | 2007-06-08 | 2013-06-18 | Apple Inc. | Efficient data backup |
US20080307347A1 (en) * | 2007-06-08 | 2008-12-11 | Apple Inc. | Application-Based Backup-Restore of Electronic Information |
US8307004B2 (en) | 2007-06-08 | 2012-11-06 | Apple Inc. | Manipulating electronic backups |
US20080307345A1 (en) * | 2007-06-08 | 2008-12-11 | David Hart | User Interface for Electronic Backup |
US8010900B2 (en) | 2007-06-08 | 2011-08-30 | Apple Inc. | User interface for electronic backup |
US20080307020A1 (en) * | 2007-06-08 | 2008-12-11 | Steve Ko | Electronic backup and restoration of encrypted data |
US8504516B2 (en) | 2007-06-08 | 2013-08-06 | Apple Inc. | Manipulating electronic backups |
US20120084764A1 (en) * | 2007-07-11 | 2012-04-05 | Thorley Jeb Stuart | Method and system for version independent software release management |
US8219985B2 (en) * | 2007-07-11 | 2012-07-10 | Trend Micro Incorporated | Method and system for version independent software release management |
US8739152B2 (en) | 2007-07-11 | 2014-05-27 | Trend Micro Incorporated | Method and system for version independent software release management |
US8209350B1 (en) * | 2007-09-12 | 2012-06-26 | The Mathworks, Inc. | Storing and maintaining consistency among folios holding associated information |
US20090192969A1 (en) * | 2007-09-28 | 2009-07-30 | Xcerion Aktiebolag | Network operating system |
US9344497B2 (en) | 2007-09-28 | 2016-05-17 | Xcerion Aktiebolag | State management of applications and data |
US8280925B2 (en) | 2007-09-28 | 2012-10-02 | Xcerion Aktiebolag | Resolution of multi-instance application execution |
US8996459B2 (en) | 2007-09-28 | 2015-03-31 | Xcerion Aktiebolag | Offline and/or client-side execution of a network application |
US8239511B2 (en) | 2007-09-28 | 2012-08-07 | Xcerion Aktiebolag | Network operating system |
US8234315B2 (en) * | 2007-09-28 | 2012-07-31 | Xcerion Aktiebolag | Data source abstraction system and method |
US9071623B2 (en) * | 2007-09-28 | 2015-06-30 | Xcerion Aktiebolag | Real-time data sharing |
US20090157627A1 (en) * | 2007-09-28 | 2009-06-18 | Xcerion Ab | Network operating system |
US8156146B2 (en) * | 2007-09-28 | 2012-04-10 | Xcerion Aktiebolag | Network file system |
US9621649B2 (en) | 2007-09-28 | 2017-04-11 | Xcerion Aktiebolag | Network operating system |
US8112460B2 (en) * | 2007-09-28 | 2012-02-07 | Xcerion Aktiebolag | Framework for applying rules |
US8108426B2 (en) | 2007-09-28 | 2012-01-31 | Xcerion Aktiebolag | Application and file system hosting framework |
US8099671B2 (en) * | 2007-09-28 | 2012-01-17 | Xcerion Aktiebolag | Opening an application view |
US11838358B2 (en) | 2007-09-28 | 2023-12-05 | Xcerion Aktiebolag | Network operating system |
US8615531B2 (en) * | 2007-09-28 | 2013-12-24 | Xcerion Aktiebolag | Programmatic data manipulation |
US8620863B2 (en) * | 2007-09-28 | 2013-12-31 | Xcerion Aktiebolag | Message passing in a collaborative environment |
US8959123B2 (en) * | 2007-09-28 | 2015-02-17 | Xcerion Aktiebolag | User interface framework |
US8954526B2 (en) | 2007-09-28 | 2015-02-10 | Xcerion Aktiebolag | Network operating system |
US8688627B2 (en) | 2007-09-28 | 2014-04-01 | Xcerion Aktiebolag | Transaction propagation in a networking environment |
US20090164592A1 (en) * | 2007-09-28 | 2009-06-25 | Xcerion Ab | Network operating system |
US20090171974A1 (en) * | 2007-09-28 | 2009-07-02 | Xcerion Ab | Network operating system |
US8738567B2 (en) * | 2007-09-28 | 2014-05-27 | Xcerion Aktiebolag | Network file system with enhanced collaboration features |
US20090254610A1 (en) * | 2007-09-28 | 2009-10-08 | Xcerion Ab | Network operating system |
US20090172087A1 (en) * | 2007-09-28 | 2009-07-02 | Xcerion Ab | Network operating system |
US20090192992A1 (en) * | 2007-09-28 | 2009-07-30 | Xcerion Aktiebolag | Network operating system |
US20090177734A1 (en) * | 2007-09-28 | 2009-07-09 | Xcerion Ab | Network operating system |
US20090171993A1 (en) * | 2007-09-28 | 2009-07-02 | Xcerion Ab | Network operating system |
US20090172569A1 (en) * | 2007-09-28 | 2009-07-02 | Xcerion Ab | Network operating system |
US8843942B2 (en) | 2007-09-28 | 2014-09-23 | Xcerion Aktiebolag | Interpreting semantic application code |
US20090106305A1 (en) * | 2007-10-19 | 2009-04-23 | Fuji Xerox Co., Ltd. | Document process history managing system, document process history managing apparatus, document process history managing method, and computer readable medium |
CN101965558A (en) * | 2008-02-29 | 2011-02-02 | 三菱电机株式会社 | Event history memory device, event history tracking device, event history memory method, event history memory program and data structure |
US20110078218A1 (en) * | 2008-02-29 | 2011-03-31 | Mitsubishi Electronic Corporation | Event history storage device, event history tracking device, event history storage method, event history storage program, and data structure |
US8856088B2 (en) * | 2008-04-01 | 2014-10-07 | Microsoft Corporation | Application-managed file versioning |
US20090248757A1 (en) * | 2008-04-01 | 2009-10-01 | Microsoft Corporation | Application-Managed File Versioning |
US20100030998A1 (en) * | 2008-07-30 | 2010-02-04 | Vmware, Inc. | Memory Management Using Transparent Page Transformation |
US9665498B2 (en) * | 2008-07-30 | 2017-05-30 | Vmware, Inc. | Memory management using transparent page transformation |
US10747952B2 (en) | 2008-09-15 | 2020-08-18 | Palantir Technologies, Inc. | Automatic creation and server push of multiple distinct drafts |
US20130103706A1 (en) * | 2009-01-29 | 2013-04-25 | International Business Machines Corporation | Method for Objectclass Versioning |
US9760585B2 (en) * | 2009-01-29 | 2017-09-12 | International Business Machines Corporation | Objectclass versioning |
US20100257403A1 (en) * | 2009-04-03 | 2010-10-07 | Microsoft Corporation | Restoration of a system from a set of full and partial delta system snapshots across a distributed system |
US20130290263A1 (en) * | 2009-06-26 | 2013-10-31 | Simplivity Corporation | File system |
US10474631B2 (en) | 2009-06-26 | 2019-11-12 | Hewlett Packard Enterprise Company | Method and apparatus for content derived data placement in memory |
US9367551B2 (en) * | 2009-06-26 | 2016-06-14 | Simplivity Corporation | File system accessing an object store |
US9965483B2 (en) | 2009-06-26 | 2018-05-08 | Hewlett Packard Enterprise Company | File system |
US10176113B2 (en) | 2009-06-26 | 2019-01-08 | Hewlett Packard Enterprise Development Lp | Scalable indexing |
US20110173601A1 (en) * | 2010-01-12 | 2011-07-14 | Google Inc. | Operating system auto-update procedure |
US8566287B2 (en) * | 2010-01-29 | 2013-10-22 | Hewlett-Packard Development Company, L.P. | Method and apparatus for scheduling data backups |
US20110191777A1 (en) * | 2010-01-29 | 2011-08-04 | Ajay Bansal | Method and Apparatus for Scheduling Data Backups |
US9032403B1 (en) | 2010-05-06 | 2015-05-12 | Dell Software Inc. | Systems and methods for instant provisioning of virtual machine files |
US9465642B1 (en) | 2010-05-06 | 2016-10-11 | Dell Software Inc. | Systems and methods for instant provisioning of virtual machine files |
US8453145B1 (en) | 2010-05-06 | 2013-05-28 | Quest Software, Inc. | Systems and methods for instant provisioning of virtual machine files |
US9547562B1 (en) | 2010-08-11 | 2017-01-17 | Dell Software Inc. | Boot restore system for rapidly restoring virtual machine backups |
US20120158657A1 (en) * | 2010-12-21 | 2012-06-21 | International Business Machines Corporation | Role-specific access control to sections of artifact content within a configuration management (cm) system |
US9411812B2 (en) | 2011-01-14 | 2016-08-09 | Apple Inc. | File system management |
US8943026B2 (en) | 2011-01-14 | 2015-01-27 | Apple Inc. | Visual representation of a local backup |
US8984029B2 (en) | 2011-01-14 | 2015-03-17 | Apple Inc. | File system management |
US10303652B2 (en) | 2011-01-14 | 2019-05-28 | Apple Inc. | File system management |
US20120216073A1 (en) * | 2011-02-18 | 2012-08-23 | Ab Initio Technology Llc | Restarting Processes |
US9021299B2 (en) * | 2011-02-18 | 2015-04-28 | Ab Initio Technology Llc | Restarting processes |
US11099982B2 (en) | 2011-03-31 | 2021-08-24 | Oracle International Corporation | NUMA-aware garbage collection |
US10963376B2 (en) * | 2011-03-31 | 2021-03-30 | Oracle International Corporation | NUMA-aware garbage collection |
US9424139B1 (en) * | 2011-03-31 | 2016-08-23 | Emc Corporation | Version based data protection |
US11775429B2 (en) | 2011-03-31 | 2023-10-03 | Oracle International Corporation | NUMA-aware garbage collection |
US20140157407A1 (en) * | 2011-05-06 | 2014-06-05 | The University Of North Carolina At Chapel Hill | Methods, systems, and computer readable media for efficient computer forensic analysis and data access control |
US9721089B2 (en) * | 2011-05-06 | 2017-08-01 | The University Of North Carolina At Chapel Hill | Methods, systems, and computer readable media for efficient computer forensic analysis and data access control |
US9880987B2 (en) | 2011-08-25 | 2018-01-30 | Palantir Technologies, Inc. | System and method for parameterizing documents for automatic workflow generation |
US10706220B2 (en) | 2011-08-25 | 2020-07-07 | Palantir Technologies, Inc. | System and method for parameterizing documents for automatic workflow generation |
US9053107B1 (en) * | 2011-12-06 | 2015-06-09 | Google Inc. | Determining updates for files based on an organization of the files on different blocks of a storage device |
US8805940B2 (en) * | 2012-02-28 | 2014-08-12 | Microsoft Corporation | Enhanced replication for message services |
US10031958B2 (en) | 2012-02-28 | 2018-07-24 | Microsoft Technology Licensing, Llc | Enhanced replication |
US20130227028A1 (en) * | 2012-02-28 | 2013-08-29 | Microsoft Corporation | Enhanced replication for message services |
US9984128B2 (en) | 2012-05-15 | 2018-05-29 | Splunk Inc. | Managing site-based search configuration data |
US9984129B2 (en) * | 2012-05-15 | 2018-05-29 | Splunk Inc. | Managing data searches using generation identifiers |
US9124612B2 (en) | 2012-05-15 | 2015-09-01 | Splunk Inc. | Multi-site clustering |
US20130311428A1 (en) * | 2012-05-15 | 2013-11-21 | Splunk Inc. | Clustering for high availability and disaster recovery |
US11675810B2 (en) * | 2012-05-15 | 2023-06-13 | Splunkinc. | Disaster recovery in a clustered environment using generation identifiers |
US10474682B2 (en) | 2012-05-15 | 2019-11-12 | Splunk Inc. | Data replication in a clustered computing environment |
US9130971B2 (en) | 2012-05-15 | 2015-09-08 | Splunk, Inc. | Site-based search affinity |
US20150347523A1 (en) * | 2012-05-15 | 2015-12-03 | Splunk Inc. | Managing data searches using generation identifiers |
US9160798B2 (en) * | 2012-05-15 | 2015-10-13 | Splunk, Inc. | Clustering for high availability and disaster recovery |
US11003687B2 (en) | 2012-05-15 | 2021-05-11 | Splunk, Inc. | Executing data searches using generation identifiers |
US10387448B2 (en) | 2012-05-15 | 2019-08-20 | Splunk Inc. | Replication of summary data in a clustered computing environment |
US20130325804A1 (en) * | 2012-06-05 | 2013-12-05 | International Business Machines Corporation | Replica identification and collision avoidance in file system replication |
US9305004B2 (en) * | 2012-06-05 | 2016-04-05 | International Business Machines Corporation | Replica identification and collision avoidance in file system replication |
US9703803B2 (en) | 2012-06-05 | 2017-07-11 | International Business Machines Corporation | Replica identification and collision avoidance in file system replication |
US9898335B1 (en) | 2012-10-22 | 2018-02-20 | Palantir Technologies Inc. | System and method for batch evaluation programs |
US11182204B2 (en) | 2012-10-22 | 2021-11-23 | Palantir Technologies Inc. | System and method for batch evaluation programs |
US20160078044A1 (en) * | 2012-12-19 | 2016-03-17 | Microsoft Technology Licensing, Llc | Main-memory database checkpointing |
US10318648B2 (en) * | 2012-12-19 | 2019-06-11 | Microsoft Technology Licensing, Llc | Main-memory database checkpointing |
US20140172803A1 (en) * | 2012-12-19 | 2014-06-19 | Microsoft Corporation | Main-memory database checkpointing |
US9304998B2 (en) * | 2012-12-19 | 2016-04-05 | Microsoft Technology Licensing, Llc | Main-memory database checkpointing |
US9251008B2 (en) | 2013-03-14 | 2016-02-02 | International Business Machines Corporation | Client object replication between a first backup server and a second backup server |
US9852205B2 (en) | 2013-03-15 | 2017-12-26 | Palantir Technologies Inc. | Time-sensitive cube |
US10452678B2 (en) | 2013-03-15 | 2019-10-22 | Palantir Technologies Inc. | Filter chains for exploring large data sets |
US10977279B2 (en) | 2013-03-15 | 2021-04-13 | Palantir Technologies Inc. | Time-sensitive cube |
US11138279B1 (en) | 2013-12-10 | 2021-10-05 | Palantir Technologies Inc. | System and method for aggregating data from a plurality of data sources |
US10198515B1 (en) | 2013-12-10 | 2019-02-05 | Palantir Technologies Inc. | System and method for aggregating data from a plurality of data sources |
US20150234910A1 (en) * | 2014-02-17 | 2015-08-20 | Unify Square, Inc. | Lifecycle management and provisioning system for unified communications |
US9449074B1 (en) | 2014-03-18 | 2016-09-20 | Palantir Technologies Inc. | Determining and extracting changed data from a data source |
US10180977B2 (en) | 2014-03-18 | 2019-01-15 | Palantir Technologies Inc. | Determining and extracting changed data from a data source |
US9292388B2 (en) * | 2014-03-18 | 2016-03-22 | Palantir Technologies Inc. | Determining and extracting changed data from a data source |
US20150331755A1 (en) * | 2014-05-15 | 2015-11-19 | Carbonite, Inc. | Systems and methods for time-based folder restore |
US10452484B2 (en) * | 2014-05-15 | 2019-10-22 | Carbonite, Inc. | Systems and methods for time-based folder restore |
US11531658B2 (en) * | 2014-05-19 | 2022-12-20 | Amazon Technologies, Inc. | Criterion-based retention of data object versions |
US10198452B2 (en) | 2014-05-30 | 2019-02-05 | Apple Inc. | Document tracking for safe save operations |
US11347933B1 (en) | 2015-12-30 | 2022-05-31 | Google Llc | Distributed collaborative storage with operational transformation |
US20170192856A1 (en) * | 2015-12-30 | 2017-07-06 | Dropbox, Inc. | Techniques for providing user interface enhancements for online content management system version histories |
US11144514B2 (en) | 2015-12-30 | 2021-10-12 | Dropbox, Inc. | Techniques for providing user interface enhancements for online content management system version histories |
US10902185B1 (en) * | 2015-12-30 | 2021-01-26 | Google Llc | Distributed collaborative storage with operational transformation |
US10289693B2 (en) * | 2015-12-30 | 2019-05-14 | Dropbox, Inc. | Techniques for providing user interface enhancements for online content management system version histories |
US10554664B2 (en) | 2016-05-02 | 2020-02-04 | Microsoft Technology Licensing, Llc | Activity feed for hosted files |
WO2018009710A1 (en) * | 2016-07-07 | 2018-01-11 | Tuxera Inc | Systems and methods for performing data object renaming operations |
US10614044B2 (en) | 2016-07-07 | 2020-04-07 | Tuxera, Inc. | Systems and methods for performing data object renaming operations |
US10528440B2 (en) * | 2016-11-28 | 2020-01-07 | Sap Se | Metadata cataloging framework |
US20190296937A1 (en) * | 2017-01-10 | 2019-09-26 | Bayerische Motoren Werke Aktiengesellschaft | Central Data Store in Vehicle Electrical System |
US10545913B1 (en) * | 2017-04-30 | 2020-01-28 | EMC IP Holding Company LLC | Data storage system with on-demand recovery of file import metadata during file system migration |
US10803093B2 (en) * | 2017-09-22 | 2020-10-13 | Microsoft Technology Licensing, Llc | Systems and methods for enabling a file management label to persist on a data file |
CN110569318A (en) * | 2018-05-16 | 2019-12-13 | 杭州海康威视数字技术股份有限公司 | space-time data storage method, query method, storage device and query device |
US11620186B1 (en) * | 2020-06-17 | 2023-04-04 | Egnyte, Inc. | System and method for resolving transient and localized errors in a hybrid cloud cache |
Also Published As
Publication number | Publication date |
---|---|
WO2005111788A3 (en) | 2008-04-03 |
US8108429B2 (en) | 2012-01-31 |
WO2005111788A2 (en) | 2005-11-24 |
EP1745362A4 (en) | 2010-02-17 |
US20050262097A1 (en) | 2005-11-24 |
EP1745362A2 (en) | 2007-01-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8131723B2 (en) | Recovering a file system to any point-in-time in the past with guaranteed structure, content consistency and integrity | |
US20070094312A1 (en) | Method for managing real-time data history of a file system | |
US7979441B2 (en) | Method of creating hierarchical indices for a distributed object system | |
US11740974B2 (en) | Restoring a database using a fully hydrated backup | |
JP4336129B2 (en) | System and method for managing multiple snapshots | |
US9384207B2 (en) | System and method for creating deduplicated copies of data by tracking temporal relationships among copies using higher-level hash structures | |
US10275474B2 (en) | System and method for managing deduplicated copies of data using temporal relationships among copies | |
US9372866B2 (en) | System and method for creating deduplicated copies of data by sending difference data between near-neighbor temporal states | |
US8299944B2 (en) | System and method for creating deduplicated copies of data storing non-lossy encodings of data directly in a content addressable store | |
US8712970B1 (en) | Recovering a database to any point-in-time in the past with guaranteed data consistency | |
US8788769B2 (en) | System and method for performing backup or restore operations utilizing difference information and timeline state information | |
US8396905B2 (en) | System and method for improved garbage collection operations in a deduplicated store by tracking temporal relationships among copies | |
US8904126B2 (en) | System and method for performing a plurality of prescribed data management functions in a manner that reduces redundant access operations to primary storage | |
KR20140051107A (en) | Systems and methods for data management virtualization |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: BAKBONE SOFTWARE, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SIM-TANG, SIEW YONG;REEL/FRAME:022994/0627 Effective date: 20090721 Owner name: BAKBONE SOFTWARE, INC.,CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SIM-TANG, SIEW YONG;REEL/FRAME:022994/0627 Effective date: 20090721 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |