Systems and methods for performing discrete data replication

Abstract

Systems and methods for performing intelligent replication of production data on a source storage device. In certain examples, a full backup of the production data is first performed and stored on a destination system. A journal module on the storage device (e.g., a shared storage device), or on at least one source system, tracks files on the storage device that change during a particular period of time. Following this period, a snapshot is taken of the production data. Upon mounting the snapshot, the replication system uses the journal information to identify modified files, conduct a block-level comparison of only the modified files with corresponding files on the destination system, and identify the particular data blocks that changed. The replication system then replicates only the changed blocks to the destination system. Certain systems further store information indicating a source system time of a known good state of the production data.

Description

BACKGROUND

Field

The present disclosure relates to performing copy and/or data management operations in a computer network and, in particular, to systems and methods for performing data replication in a storage management system.

Description of the Related Art

Computers have become an integral part of business operations such that many banks, insurance companies, brokerage firms, financial service providers, and a variety of other businesses rely on computer networks to store, manipulate, and display information that is constantly subject to change. Oftentimes, the success or failure of an important transaction may turn on the availability of information that is both accurate and current. Accordingly, businesses worldwide recognize the commercial value of their data and seek reliable, cost-effective ways to protect the information stored on their computer networks.

Many approaches to protecting data involve creating a copy of the data, such as backing up and/or replicating data on one or more storage devices. Data shadowing and mirroring, or duplexing, provide for copying but can require substantial amounts of time, processing power and/or storage space, especially for large databases. Moreover, such storage management systems can have a significant adverse impact on the performance of the source or primary system.

To address these drawbacks, certain systems perform backup operations that copy less than an entire volume of data to a desired location. For example, differential backup operations are used to copy all files that have changed since a last full backup of the data. Moreover, incremental backup operations can be used to copy all files that have changed since the most recent full, differential or incremental backup. These techniques, however, can require a significant amount of processing power or network bandwidth, especially when dealing with changes to relatively large files or databases.

SUMMARY

In view of the foregoing, a need exists for improved systems and methods for copying and/or replicating data in computing systems. In particular, a need exists for intelligent systems and methods that reduce the amount of data replicated from a source volume to a destination volume, including replication of a shared storage volume. Such intelligent and focused data replication can advantageously reduce network loads, expedite copy operations and/or decrease consumption of valuable processing resources.

In certain embodiments of the invention, systems and methods are disclosed for performing discrete data replication of data (e.g., application-specific data) in a computer network environment. For instance, in certain embodiments only the changed blocks of a source file are replicated to a destination file. The time intervals of such replication can advantageously be selected and/or varied to balance the need to maintain current the replication data and to reduce network and processing loads.

Accordingly, certain embodiments of the invention can recognize one or more points within application data that represent known good state(s) of the application. This information is then used by the replication system to intelligently and/or timely replicate sections of application data that represent a recoverable state rather than the rote copying of certain blocks of data based on hardware capacity and/or criteria that are unrelated to application recoverability.

In certain embodiments, a method is disclosed for replicating data in a computer network. The method includes performing a full backup of source data comprising a plurality of source files on a source storage device to copy replication data to a destination storage device, the replication data comprising a plurality of destination files corresponding to the plurality of source files. Following the full backup, the method includes identifying changed source files by tracking at a logical level which of the plurality of source files changes between the full backup and a second time and performing a snapshot of the source data to capture a state, or point-in-time image, of the source data at the second time. The method further includes mounting the snapshot and, based on the mounted snapshot, comparing blocks of the changed source files with blocks of the corresponding destination files to detect changed blocks between the changed source files and the corresponding destination files. The method then includes replicating only the changed blocks to the replication data of the destination storage device.

In certain embodiments, a system is disclosed for performing data replication in a computer network environment. The system comprises a shared storage device for storing source data as a plurality of source files, a first source computing device having a first application operative to write data to the plurality of source files, a second source computing device having a second application operative to write data to the plurality of source files, and a journal module configured to identify changed source files by tracking logical changes to the plurality of source files on the shared storage device between a first time and a second time. The system further comprises a data agent module configured to: instruct a creation of a snapshot of the source data to capture a state of the source data at the second time; instruct a mounting of the snapshot; based on the mounted snapshot, compare blocks of the changed source files with blocks of corresponding replication files on a replication storage device to detect inconsistent blocks between the changed source files and the corresponding replication files, and transmit the detected inconsistent blocks to the replication storage device. In certain embodiments, the transmission is made without copying other (consistent) blocks of the source data.

In certain embodiments, a replication system is disclosed that includes means for storing source data accessible to both a first source computing device and a second source computing device, the source data being stored as a plurality of source files. The system further includes: means for performing a full backup of the source data at a first time, the full backup resulting in replication data being stored on a destination storage device, the replication data comprising a plurality of destination files corresponding to the plurality of source files; and means for tracking logical changes to the plurality of source files between the first time and a second time to identify changed source files. The method also includes means for mounting a snapshot capturing a state of the source data at the second time; means for comparing blocks of the changed source files with blocks of the corresponding destination files to detect changed blocks; and means for replicating only the changed blocks to the destination storage device.

For purposes of summarizing the disclosure, certain aspects, advantages and novel features of the inventions have been described herein. It is to be understood that not necessarily all such advantages may be achieved in accordance with any particular embodiment of the invention. Thus, the invention may be embodied or carried out in a manner that achieves or optimizes one advantage or group of advantages as taught herein without necessarily achieving other advantages as may be taught or suggested herein.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a block diagram of a data replication system, according to certain embodiments of the invention.

FIG. 2 illustrates a block diagram of an embodiment of the data replication system of FIG. 1.

FIG. 3 illustrates a flowchart of an exemplary embodiment of a data replication process usable by the data replication system of FIG. 2.

FIG. 4 illustrates a diagram of block level changes replicated from a single file, according to certain embodiments of the invention.

FIG. 5 illustrates a flowchart of an exemplary embodiment of another data replication process usable by the data replication system of FIG. 2.

FIG. 6 illustrates a block diagram of a data replication system having a single source system, according to certain embodiments of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

As will be seen from the disclosure herein, certain systems and methods are provided for intelligent data replication. In particular, embodiments of the invention are capable of performing discrete replication of data from a source system to a destination system.

In certain embodiments, one or more modules executing on a shared storage device and/or at least one source system can monitor data modification operations to determine which files on the storage device change during a period of time. Using a mounted snapshot of the source data, the replication system can then detect which blocks of data were modified within the changed files and replicate these particular blocks to a destination volume.

In certain embodiments, the snapshot of the source volume reflects a known good, or recoverable, state of the application. For instance, replication systems and methods may determine appropriate points within the application data at which enough information is collected to reliably restore the application as of a particular point in time. At certain known good states, the replication system quiesces the application and/or generates a snapshot of the source data in order to perform the replication operations. Time information, such as, for example, a time stamp, can also be recorded to indicate the source system time of the application's known good state.

The destination system is further capable of performing one or more data management operations, such as, for example, storage operations (e.g., snapshot, backup), search operations, data classification, combinations of the same or the like, on the replicated data when it represents a known good state. Performing data management operations on the replicated data allows for the processing of copies of application data without significantly impacting the resources of the source system.

Moreover, using the time information, the destination system is further capable of logically associating the copied data (e.g., a snapshot of the replicated data) with the source system time of the known good state of the application. That is, even though the copy of the replicated data occurs at some point after the replication of the production (source system) data, the copied data is logically associated with the (earlier) source system time of the known good state of the application. As a result, the copy of the replicated data appears as if it was directly performed on the production data. In certain embodiments, this method advantageously allows for further processing of the copied data (e.g., processing of snapshots of the replicated data) without touching the production data.

The features of the systems and methods will now be described with reference to the drawings summarized above. Throughout the drawings, reference numbers are re-used to indicate correspondence between referenced elements. The drawings, associated descriptions, and specific implementation are provided to illustrate embodiments of the invention and not to limit the scope of the disclosure.

In addition, methods and processes described herein are not limited to any particular sequence, and the blocks or states relating thereto can be performed in other sequences that are appropriate. For example, described blocks or states may be performed in an order other than that specifically disclosed, or multiple blocks or states may be combined in a single block or state.

FIG. 1 illustrates a block diagram of a data replication system 100, according to certain embodiments of the invention. In general, embodiments of the data replication system 100 perform discrete data replication by copying changed blocks of data from within one or more files on a primary storage device. Such intelligent and focused data replication can advantageously reduce network loads, expedite copy operation and/or decrease valuable consumption of processing resources.

As shown, the data replication system 100 comprises a source (or primary) system 102 capable of communicating with a destination system 104 by sending and/or receiving data over a network 106. For instance, in certain embodiments, the destination system 104 receives and/or stores a replicated copy of at least a portion of data, such as application-specific data, associated with the source system 102.

The illustrated network 106 advantageously comprises any means for communicating data between two or more systems or components. In certain embodiments, the network 106 comprises a computer network. For example, the network 106 can comprise a public network such as the Internet, virtual private network (VPN), a token ring or TCP/IP based network, wide area network (WAN), local area network (LAN), an intranet network, point-to-point link, a wireless network, cellular network, wireless data transmission system, two-way cable system, interactive kiosk network, satellite network, broadband network, baseband network, combinations of the same or the like. In embodiments wherein the source system 102 and destination system 104 are part of the same computing device, the network 106 may represent a communications socket or other suitable internal data transfer path or mechanism.

As shown, the source system 102 comprises a shared file system configuration in which multiple source devices have shared access to data (e.g., production data) on the same storage volume(s). In particular, a source device A 110 and a source device B 112 both communicate with source (or primary) storage volume(s) 114 through a switch 124 to have read/write access to the production data. For example, in certain embodiments, the source system 102 comprises a clustered file system, a storage area network (SAN) system, combinations of the same or the like.

The source devices 110 and 112 can comprise any computing device capable of accessing and/or processing data on a storage volume. In certain embodiments, either or both of the source devices 110 and 112 comprises a server computer. In yet other embodiments, the source storage devices 110, 112 can comprise a workstation, a personal computer, a cell phone, a portable computing device, a handheld computing device, a personal digital assistant (PDA), combinations of the same or the like.

The source storage volume 114 can include any type of media capable of storing data. For example, the source storage volume 114 can comprise magnetic storage (such as a disk or a tape drive) or other type of mass storage. In certain embodiments, the source storage volume(s) 114 can comprise one or more storage volumes that include physical storage disks defining an overall logical arrangement of storage space. For instance, disks within a particular volume may be organized as one or more groups of redundant array of independent (or inexpensive) disks (RAID). In certain embodiments, the source storage volume(s) 114 can include multiple storage devices of the same or different media.

Although the source storage volume 114 is illustrated separate from both source devices 110, 112, it will be understood that at least a portion of the source storage volume(s) 114 can be internal and/or external (e.g., remote) to the source device A 110 and/or the source device B 112.

FIG. 1 further illustrates an application 120 residing and/or executing on the source device 110 and an application 122 residing and/or executing on the source device 112. In certain embodiments, either or both of the applications 120, 122 can comprise software applications that interact with a user to process data on the source storage volume 114 and may include, for example, database applications (e.g., SQL applications), word processors, spreadsheets, financial applications, management applications, e-commerce applications, browsers, combinations of the same or the like. For example, in certain embodiments, the applications 120, 122 can comprise one or more of the following: MICROSOFT EXCHANGE, MICROSOFT SHAREPOINT, MICROSOFT SQL SERVER, ORACLE, MICROSOFT WORD and LOTUS NOTES.

The switch 124 comprises software and/or hardware usable by multiple computing devices to access a shared storage device. For instance, the switch 124 can comprise a Fibre Channel switch or other type of network switch. In yet other embodiments, the shared storage can be arranged in a network file system, a network attached storage (NAS) system, combinations of the same or the like.

As further illustrated in FIG. 1, the destination system 104 comprises a replication module 130 and destination storage volume(s) 132. In certain embodiments, the replication module 130 is configured to monitor and/or manage the copying of data from the source system 102 to the destination system 104. In yet other embodiments, the replication module 130 comprises a “dumb” server or terminal that receives and executes instructions from the source system 102 and/or a storage management module (not shown).

The destination storage volume 132 may include any type of media capable of storing data, such as replication data sent from the source system 102. For example, the destination storage volume 132 may comprise magnetic storage or other type of mass storage. In certain embodiments, the destination storage volume 132 may be internal and/or external to the computing device(s) executing the replication module 130.

Although FIG. 1 illustrates the data replication system 100 having a shared storage configuration, other embodiments of the invention can include a single source device and/or each of multiple source devices can have separate, associated storage volumes.

FIG. 2 illustrates a block diagram of a data replication system 200, according to certain embodiments of the invention. In particular, the data replication system 200 illustrates further details of an embodiment of the replication system 100 of FIG. 1. Thus, to simplify the description, components will not be redescribed in detail if they were described above. Rather, the components in the embodiments of FIG. 2 will be given a reference numeral that retains the same last two digits as the reference numeral used in the embodiment of FIG. 1 and will be preceded with a numeral “2.”

In general, the system 200 is configured to perform intelligent data replication of data on a shared storage volume. In certain embodiments, the data replication is performed at discrete points in time and comprises copying only changed blocks of data to a destination system. This process can be performed, for example, by comparing, on a block-by-block basis, modified files with corresponding files on a destination system. Moreover, the frequency of such replication can be adjusted to meet the needs of the user(s) and/or system.

As shown, the data replication system 200 comprises a source device A 210 and a source device B 212 that communicate with a destination system 204 over a network 206. In general, the data replication system 200 is configured to perform discrete data replication with respect to data stored on a shared source storage volume(s) 214, which is accessible by both source devices 210, 212.

Each of the source devices 210, 212 comprises application(s) 220 and application(s) 222, respectively, executing thereon. As illustrated, the application(s) 220, 222 are configured for shared access to the data on the source storage volume 214 through a switch 224.

The source device A 210 further comprises a data agent 226. In certain embodiments, the data agent 226 comprises a module responsible for performing data and/or storage tasks related to the source device A 210 and/or the source storage volume 214. For example, the data agent 226 can manage and/or coordinate the compilation and/or transferring of replication data from the source storage volume 214. In other embodiments, the data agent 226 may provide archiving, migrating, and/or recovery of client computer data.

In certain embodiments, the source device A 210 comprises a plurality of data agents 226, each of which performs data management operations related to data associated with each application. In yet other embodiments, the data agent 226 can work with data from multiple applications 220.

In certain embodiments, the data agent 226 is configured to perform data management operations in accordance with one or more “storage policies” or other preferences. For example, a storage policy can include a data structure or other information having a set of preferences and/or other storage criteria for performing a storage operation. The preferences and storage criteria may include, but are not limited to, information regarding storage locations, relationships between system components, network pathways, retention policies, data characteristics, compression or encryption requirements, preferred system components, combinations of the same or the like.

Although only a single data agent is illustrated with respect to the data replication system 200, other embodiments of the invention can utilize a data agent on each of a plurality of source devices (e.g., source device 212).

As further illustrated in FIG. 2, the source storage volume 214 further comprises a journal file 227. For instance, the journal file 227 can track data changes on a logical level, such as when a particular file has been changed or modified. In certain embodiments, the journal file 227 comprises a new technology file system (NTFS) change journal or other like file system change journal capable of detecting modifications made to files and/or data stored on the source storage volume 214.

In yet other embodiments, the journal file 227 can store copies or portions of some or all the data operations output from applications 220, 222 to the source storage volume 214. In yet other embodiments, the journal file entries can include other system information, such as time stamp information. In still other embodiments, the journal file entries may be enriched with other useful system or application information available on source devices 210, 212. For example, the journal file entries can include metadata and/or data classification information that has been obtained from the application data.

In certain embodiments of the invention, the journal file 227 can comprise a customized change journal that tracks in real-time the block-level changes made to data files stored on the source storage volume 214. Such embodiments could obviate the need for later performing comparison algorithms to detect which blocks of a modified file were affected by one or more data modification operations.

The source storage volume 214 also comprises one or more snapshots 228 that provide a static image of data on the source storage volume 214. In certain embodiments, the snapshot 228 captures a point-in-time, read-only image of the volume to detect changed files and/or blocks and to facilitate replication of data on the source storage volume 214.

Snapshots may be implemented by several different methods. For example, in certain embodiments, a “copy-on-write” process can be used. In yet other embodiments, the snapshot 228 can be generated using another process, such as, for example, direct-on-write, split mirror, copy-on-write with background copy, continuous data protection copies, combinations of the same or the like.

The destination system 204 further comprises a replication agent 230 in communication with a replication volume 232. In certain embodiments, the replication agent 230 comprises any computing device and/or software module that coordinates the transfer of data to the replication volume 232.

For instance, in certain embodiments, the replication agent 230 instantiates an appropriate number of threads, processes, or routines, for replicating data received from the source storage volume 214 to the replication volume 232. In certain embodiments, the replication agent 230 further includes mapping or correlation information that determines when and to where the data from the source storage volume 214 is copied by the threads. In certain embodiments, such mapping information may be based on system- or user-defined parameters and/or may be automatically generated, such as based on the status of the replication volume 232.

In certain embodiments, the replication agent 230 communicates with the data agent 226 to coordinate data replication. For example, the data agent 226 can open a socket and communicate to the replication agent 230 regarding the transfer of data. For instance, the data agent 226 may request from the replication agent 230 and/or other network management components information that may affect, or be related to, the correlation or mapping of network storage paths for replication data.

The illustrated data replication system 200 further comprises an optional preference database 234 in communication with the network 206. In certain embodiments, the preference database 234 includes storage policies and/or other preferences usable by the replication system 200 in managing data. For instance, the stored preferences may indicate the desired frequency at which data is to be replicated from the source storage volume 214 to the replication volume 232. The preference database 234 may also store path information for detailing to which location(s) on the replication volume 232 data should be copied. In yet other embodiments, the preference database 234 may include storage policies that dictate particular criteria for performing one or more data management operations on the data stored on the replication volume 232.

The replication system 200 advantageously provides for data management operations to be performed on replicated data in order to avoid burdening the source systems. For example, one or more storage operations may be performed on replicated data that represents a recoverable state, or “known good state” of a particular application(s) running on the source system(s).

For instance, in certain embodiments, known good replication copies may be viewed as copies of production volume data. This feature allows a management component in the computing system to directly access, copy, restore, backup or otherwise manipulate the replication copies of production data as if the data was the production data of the source storage volume 214. Such can advantageously improve various system performance characteristics such as access time, reducing memory requirements and reducing impact on source, or client, applications.

In certain embodiments, the replication copies of the production data include time information (such as one or more time stamps) that indicates the source system time when the production data was modified and/or when the subject application was in a known good state. Such time stamps are then associated with copies of the replicated data, thereby allowing for the synchronization of time references between the production data and copies of the replicated data.

For example, FIG. 2 illustrates one or more snapshots 236 associated with the replication volume 232. In certain embodiments, the snapshots 236 comprise point-in-time images of data stored on the replication volume 232. As a result, such snapshots 236 provide copies of the production data on the source system without affecting the performance thereof.

FIG. 3 illustrates a flowchart of a data replication process 300, according to certain embodiments of the invention. In general, the replication process 300 is executed by embodiments of the data replication systems described herein to perform intelligent replication of data in a storage management environment. For exemplary purposes, the replication process 300 will be described hereinafter with reference to the components of the data replication system 200 of FIG. 2.

The replication process 300 begins with Block 305, during which the replication system 200 performs a full backup of data stored on the source storage volume 214. For instance, the full backup operation can comprise the copying of the entire file system on the source storage volume 214 to the replication volume 232. In other embodiments, the full backup can be directed to application-specific data or one or more particular files on the source storage volume 214.

In certain embodiments, the destination system 204 communicates with at least one of the source devices 210, 222 (e.g., with data agent 226) to verify that the source storage volume 214 and the replication volume 232 are synchronized following the full backup or related copy operation.

At Block 310, the journal file 227 tracks logical changes to data on the source storage volume 214. For instance, such changes can comprise modification of the data itself, attribute changes, security changes, combinations of the same or the like. In certain embodiments, the journal file 227 does not maintain a record of the actual change, but only which files were changed without storing additional information. Such embodiments can advantageously conserve memory and/or resources by maintaining relatively small amounts of data in the journal file 227.

At Block 315, the replication system 200 performs a snapshot of the source storage volume 214. In certain embodiments, this process is advantageously performed at a determined replication point, when synchronization of the source storage volume 214 and the replication volume 232 is desired. For example, in certain embodiments, the snapshot is performed in response to instructions received from the data agent 226. In yet other embodiments, the snapshot is performed in response to a call made by one of the source devices 210, 212 to a Microsoft Volume Shadow Copy Service (VSS) driver, a QSNAP driver, or other software-based snapshot implementation.

In certain embodiments, the snapshot of Block 315 can be triggered according to one or more storage policies, such as stored in the preference database 234, that dictate the timing of storage operations between the source storage volume 214 and the replication volume 232. For instance, replication points can be determined by preset copying intervals, time lapsed since the last copy/replication operation, thresholds reached in the journal file 227, replication agent 230 requests for a copy operation, user input, specific parameters or requirements associated with a particular application 220, 222, monitored and/or predicted health of the servers, combinations of the same or the like.

For instance, in certain embodiments, replication can be performed every eight hours, once a day, or the like. In yet other embodiments, certain data-sensitive application data may be copied more frequently than other applications in order to reduce the amount of potential data loss due to a failure occurring between copy operations.

In certain embodiments, during Block 315, writes to the source storage volume 214 are temporarily quiesced, buffered, or otherwise halted during the performance of the snapshot. Once the snapshot is complete, the writes to the source storage volume 214 can immediately resume.

At Block 320, the replication system 200 mounts the snapshot to present a full logical file system to the source devices 210, 212. In certain embodiments, this process comprises mounting or mapping a prepared disk volume onto a standard mount point or mount location, but with a special option that specifies the original file system. For instance, in certain embodiments of the invention, a data agent on either of the source devices 210, 212 can instruct the mounting of the snapshot of the source volume.

At Block 325, the replication process 300 accesses the journal file 227 in view of the mounted snapshot to determine which source files have changed between the time of the full backup (Block 300), or last re-sync, and the capturing of the snapshot (Block 315). In certain embodiments, the data agent on either of the source devices 210, 212 can access the journal file 227 to determine the changed files.

Moreover, in certain embodiments of the invention, the replication process 300 can utilize customized change journal filter drivers executing on each of the source devices 210, 212 to track writes to a given set of files. A list of all changed files can then be consolidated between the devices to determine which extents and/or files have changed during the select period of time. Such a consolidated list can be maintained on one or more source devices, the source storage volume, a storage management module, the replication agent 230 or the like.

Based on the changed files and the mounted snapshot, the replication process 300 then determines the particular blocks that were modified within the changed files (Block 330). In certain embodiments, the replication system 200 compares each modified file on the source storage volume 214 with the corresponding file on the replication volume 232. For instance, the replication system 200 can parse each modified file into chunks (e.g., 64 KB chunks) and compare the chunks with the corresponding destination file via a message-digest algorithm (e.g., MD5) or secure hash algorithm (e.g., SHA-1). In yet other embodiments, other types of checksum algorithms or means for comparison can be used.

At Block 335, the replication system 200 replicates only the changed blocks from the source storage volume 214 to the replication volume 232. Because only changed blocks of the file are replicated, as opposed to the entire file, the replication process 300 advantageously reduces the use of valuable processing power, replication time, and/or network bandwidth.

Following Block 335, the replication process 300 returns to Block 310 to track additional logical changes to files on the source storage volume 214.

Although the replication process 300 has been described with respect to particular arrangements, it will be understood that blocks of the replication process 300 can be combined, divided and/or executed in parallel. For instance, in certain embodiments, the replication system 200 continues to track logical changes to the source storage volume(s) (Block 310) during one or more of the Blocks 320-335.

FIG. 4 illustrates a diagram of block level changes replicated from a single file, according to certain embodiments of the invention. As shown, at time T₀, File A is stored on a storage volume 440. In particular, File A comprises four blocks stored in non-contiguous memory locations on the storage volume 440. At this point, the storage volume 440 and a replication volume are preferably synchronized such that a corresponding copy of File A also exists on the replication volume.

Between time T₀ and T₁, changes are made to the data on the storage volume 440, thereby resulting in a storage volume 440′ with, among other data, File A′. At this point, the journal file (e.g., NTFS change journal) of the particular storage volume indicates that File A′ has been modified twice between time T₀ and T₁. In order to determine the specific changed blocks, File A′ is compared with the file corresponding to File A on the replication volume, such as via Blocks 315-330 of the replication process 300 of FIG. 3. From this comparison, the replication system determines that block 4 has been modified to block 4′ and that block 5 has been added to File A′.

Based on this comparison, only changed blocks 444 (i.e., blocks 4′ and 5) are sent to the destination system to update the replication volume. Other unchanged blocks of File A′, or other files, are not replicated.

FIG. 5 illustrates a flowchart of another data replication process 500, according to certain embodiments of the invention. In general, the replication process 500 is executed by embodiments of the data replication systems described herein to perform one or more storage operations on replicated data. For exemplary purposes, the replication process 500 will be described hereinafter with reference to the components of the data replication system 200 of FIG. 2.

At Block 505, the replication process 500 determines if application data on the source storage volume 214 is in a consistent or recoverable state. In certain embodiments, such a state may be defined as when particular computing operations of the respective application(s) 220, 222 are complete to a point such that further operation, recovery and/or rolling back of the application data may occur, based on the recorded data, without the loss of critical information or computing operations needed for operation of the application(s) 220, 222.

In certain embodiments, data agents residing on the source devices 210, 212 can determine if the particular application(s) associated with the data are in a known good state. At the known good state, write requests to the source storage volume 214 are quiesced (Block 510) and a snapshot is taken of the source storage volume 214 (Block 515). In yet other embodiments, the data agents can instruct the applications 220, 222 to place themselves in the known good state and to temporarily suspend data management operations to the source storage volume 214 in order to prepare for replication. For instance, in certain embodiments, the data agent utilizes the VSS driver or QSNAP driver to quiesce the applications 220, 222.

In certain embodiments, the data agent instructs the quiescing of the applications 220, 222 through an application programming interface (API). For instance, the data agent 226 may execute a command or process (e.g., FLRSNAP.TOOL) that causes the application 220 to quiesce. When the application 220 has placed itself in a known good state, the application 220 may send an acknowledgment to the data agent 226.

The frequency of known good states can vary and may depend on one or more system factors or user-selectable parameters. For instance, storage policies stored in one or more databases of the replication system 200 (e.g., the preference database 234) can dictate the frequency at which the discrete data replication process is performed. Moreover, it should be recognized that each point of data replication need not be performed at a known good state of the application. Rather, discrete data replication (including the taking of snapshots of the source storage volume 214) can also be performed when the source data is not in a known good state.

In certain embodiments, once the data management operations are suspended, the I/O buffers in the data path of the applications 220, 222 are flushed (and/or the writes in the queues are flushed). For example, some or all of the pending data management operations (e.g., as of the time of the quiescing of the application) may be allowed to complete and/or percolate through the data paths. In certain embodiments, this ensures that the snapshot 228 of the source storage volume 214 captures the application data in a known good state.

Notwithstanding the foregoing, it will be understood that, in certain embodiments, although applications 220, 222 are quiesced, they need not actually pause or suspend operation during the quiescent period. Rather, the applications 220, 222 may continue to operate substantially normally but may queue internally, or otherwise buffer, data management operations intended for the source storage volume 214. After the quiescent period, the buffered modification operations may be allowed to complete (i.e., be sent to the source storage volume 214).

In yet other embodiments, quiescing of the application 220 may be performed based on an automatic reporting procedure. For instance, a module of the replication system 200 may be configured to gather, receive and/or analyze information associated with a failure rate and/or health of applicable servers. Additional details of such status monitoring are provided in U.S. patent application Ser. No. 11/120,619, filed May 2, 2005, now U.S. Pat. No. 7,343,453, issued Mar. 11, 2008, which is hereby incorporated herein by reference in its entirety.

For example, the frequency of replication points may be selected or adjusted to mitigate risks detected in a storage network. In certain embodiments, one or more management components of the replication system 200 may identify a storage-related characteristic and may modify the frequency of replication points if the storage-related characteristic satisfies one or more particular risk criteria. For instance, risk criteria may be indicated by storage policies, storage definitions, a service level agreement (“SLA”) or other information located in a management component database or other component of the replication system 200. In certain further embodiments, the frequency of replication points may be based at least in part on a level of data protection or data availability in the replication system 200.

The process 500 then replicates the blocks of data that have changed since the previous known good state (Block 520). For instance, in certain embodiments, the process 500 can follow Blocks 310-335 of the replication process 300 of FIG. 3. In certain embodiments, such replication further includes the transmission of time information indicative of the source system time of the known good state of the application data (e.g., time of replication point at which snapshot is taken of source storage volume 214). Such time information can be in the form of a time stamp, a log entry, or like information associated with a clock of the source system and/or source storage volume 214.

Because replication of the changed blocks can advantageously be performed at a time at which the source storage volume data is in a consistent state, Block 520 results in the data on the replication volume 232 also being in a consistent state. At Block 525, one or more storage operations can then be performed on the replicated data. For instance, the replication agent 230 or other module can cause a snapshot operation to be performed on the data of the replication volume 232.

At Block 530, the snapshot of the replicated data is associated with a time stamp representing the time of the known good state of the application(s). In certain preferred embodiments, when the snapshot, or other storage operation, is performed, the time of the snapshot is logically associated with the source system time of the known good state of the application data. For instance, a time stamp generated by the source system can be used to logically assign a “time” to the snapshot of the replicated data. In such a process, the snapshot of the replicated data then appears as if the snapshot was directly taken of the data in the source system.

In certain embodiments, the logical associations of time with respect to the snapshot 236 may be stored jointly with the snapshot and/or in a separate database. For instance, the logical time associations may be stored in an index on one or more replication volumes, on the replication agent 230, in the preference database 234, in a storage manager database index, by the data agent 226, combinations of the same or the like. In certain embodiments, stored jointly with the “updated” time data may also be the actual location of the snapshot 236 on the replication volume 232 or other storage device(s).

The process 500 also resumes writes to the source storage volume 214 (Block 535). In certain embodiments, Block 535 can be performed at any time after the snapshot is taken of the source storage volume 214 (Block 515). Thus, because the storage operations of Blocks 525 and 530 are performed on the replicated data of the replication volume 232, the production or primary data on the source storage volume 214 is not needed or affected by such operations. This also advantageously allows for writes to resume from the applications 220, 222 without needing to wait for performance of the one or more storage operations.

Although the replication process 500 has been described with reference to particular arrangements, various alternative embodiments can also be used. For instance, a wide variety of other storage operations other than, or in addition to snapshots, can be performed on the replication data, such as, but not limited to, creation, storage, retrieval, backup, migration, deletion, auxiliary copies, incremental copies, differential copies, hierarchical storage management (“HSM”) copies, archive copies, information lifecycle management (“ILM”) copies, other types of copies and versions of electronic data or the like.

In yet other embodiments, the replication system 200 may use the replication data to create a shadow version of the data on the source storage volume 214. In such embodiments, if there is a failure and/or overload of the source storage volume 214, the source devices 210, 212 can be redirected to the shadowed version of the data.

In yet other embodiments, different types of data management operations may be performed on the replication data depending on one or more schedule policies. For example, a snapshot storage operation may be scheduled to be performed on the replication data every five minutes, while a differential backup may be performed on the replication data every hour. Furthermore, a full backup may be scheduled to be performed once a day. Such scheduling policies may be advantageously determined to satisfy the needs of the user while reducing the impact on system resources.

FIG. 6 illustrates a block diagram of a data replication system 600 having a single source system, according to certain embodiments of the invention. In certain embodiments, the data replication system 600 can perform similar data replication processes as those described herein with reference to FIGS. 1-5, except that the system 600 does not comprise a clustered file system arrangement. Thus, to simplify the description, components of the replication system 600 will not be redescribed in detail if they were described above. Moreover, the components will be given a reference numeral that retains the same last two digits as the reference numeral used to describe the replication system 200 of FIG. 2 and will be preceded with a numeral “6.”

As illustrated, the replication system 600 comprises a source system 602 that communicates with a destination system 604 over a network 606. In general, the data replication system 600 is configured to perform discrete data replication with respect to data stored on a source storage device 614.

The source system 602 further comprises application(s) 620 that access data stored on the source storage device 614. In certain embodiments, such access is via a file system that organizes files and directories accessible by the source system 602. The file system may include, for example, a local file system, a network file system, a file server, a management program or the like, or may include multiple file systems accessible by an operating system. For instance, in embodiments wherein the source storage device 614 is associated with multiple volumes, each volume may be associated with its own file system, or a single file system may span across the multiple volumes.

The source system 602 further comprises a data agent 626 responsible for performing data and/or storage tasks related to the source system 602. For example, the data agent 626 can manage and/or coordinate replication, archiving, migrating, and/or recovery of the source system data.

In certain embodiments, the source system 602 comprises a plurality of data agents 626, each of which performs data management operations related to data associated with each application. In such embodiments, each data agent 626 can monitor various files, folders, registry files and/or system resources that are impacted by a particular application. For instance, the data agent 626 can be programmed to detect data management requests by a particular application and determine which files, folders and/or system resources are associated with the data management requests. In yet other embodiments, the data agent 626 can work with data from multiple applications 620.

The source storage device 614 further comprises a journal file 627 that tracks when a particular file on the storage device has been changed or modified. In certain embodiments, the journal file 627 comprises a change journal or other journaling module as disclosed herein. In yet other embodiments, such tracking can be performed by the source system 602, such as through the data agent 626 and/or a filter driver on the source system 602. Examples of such tracking are described in more detail in U.S. patent application Ser. No. 11/640,829, filed Dec. 18, 2006, now U.S. Pat. No. 7,617,262, issued Nov. 10, 2009, which is hereby incorporated herein by reference in its entirety.

As further illustrated, the source storage device 614 also comprises one or more snapshots 628 or other means for providing a point-in-time image of the data on the source storage device 614.

The destination system 604 comprises a replication agent 630 in communication with a replication volume 632. In certain embodiments, the replication agent 630 comprises any computing device and/or software modules that coordinate the transfer of data to the replication volume 632. The illustrated data replication system 600 further comprises an optional preference database 634 in communication with the network 606.

Like certain replication systems disclosed herein, the replication system 600 is configured to perform intelligent data replication of data on a storage volume. In certain embodiments, the data replication is performed at discrete points in time and comprises copying only changed blocks of data to a destination system. This process can be performed, for example, by comparing, on a block-by-block basis, modified files with corresponding files on a destination system (e.g., via the replication processes 300, 500).

Although data replication systems have been disclosed herein with reference to certain embodiments, other embodiments can take on different arrangements or include more or fewer components without departing from the scope of the disclosure. For example, any of the replication systems 100, 200 or 600 can further include a storage manager that communicates with source and replication systems (e.g., through a network).

In certain embodiments, the storage manager is a software module or application configured to direct the performance of one or more storage operations and, in particular, the replication of data from the source system(s) to the replication system(s). In further embodiments, the storage manager may perform one or more of the operations or functions described above with respect to the data agents and/or the replication agents. For instance, the storage manager may direct and/or coordinate the performance of one or more storage operations on replicated data (e.g., snapshots of the replicated data).

In certain embodiments, the storage manager maintains an index, such as in a cache, for storing information relating to: logical relationships and associations between components of the replication systems, user preferences, management tasks, and/or other useful data. For example, the storage manager may use its index to track the location and timestamps of one or more snapshots of the replicated data.

The storage manager may also use its index to track the status of data management operations to be performed, storage patterns associated with the system components such as media use, storage growth, network bandwidth, Service Level Agreement (“SLA”) compliance levels, data protection levels, storage policy information, storage criteria associated with user preferences, retention criteria, storage operation preferences, and other storage-related information. The index may typically reside on the storage manager's hard disk and/or other database.

In other embodiments, the storage manager may alert the user or system when a particular resource of the replication system is unavailable or congested or when components are unavailable due to hardware failure, software problems, or other reasons. In certain embodiments, the storage manager may utilize replication system data to suggest solutions to such problems when they occur or even before they occur. For example, the storage manager might alert the user that a storage device in the replication system was full or otherwise congested, and then suggest, based on job and data storage information contained in its index cache, an alternate storage device. In yet further embodiments, the storage manager or other system component may take action to remedy the problem at issue. For example, the storage manager may perform load balancing, error correction, or the like, based on information received regarding the replication system.

Moreover, the storage manager may include an interface agent module (not shown). In certain embodiments, the interface agent module may provide presentation logic, such as a graphical user interface (“GUI”), an API, or other interface by which users and system processes may be able to retrieve information about the status of storage operations and issue instructions to the replication systems regarding the performance of storage operations. For example, a user may modify the schedule of a number of pending snapshot copies or other types of copies. As another example, a user may use the GUI to view the status of all storage operations currently pending in the replication system or the status of particular components in the replication system.

Additional details of storage manager modules useful with embodiments of the replication systems disclosed herein are described in U.S. Pat. No. 7,389,311, issued Jun. 17, 2008, which is hereby incorporated herein by reference in its entirety.

Moreover, in certain embodiments of the invention, data replication systems and methods may be used in a modular storage management system, embodiments of which are described in more detail in U.S. Pat. No. 7,035,880, issued Apr. 5, 2006, which is hereby incorporated herein by reference in its entirety. For example, the data replication system may be part of a storage operation cell that includes combinations of hardware and software components directed to performing storage operations on electronic data. Exemplary storage operation cells usable with embodiments of the invention include CommCells as embodied in the SIMPANA, QNET, and/or QINETIX storage management systems by. CommVault Systems, Inc. (Oceanport, N.J.), and as further described in U.S. Pat. No. 7,454,569, issued Nov. 18, 2008, which is hereby incorporated herein by reference in its entirety.

Systems and modules described herein may comprise software, firmware, hardware, or any combination(s) of software, firmware, or hardware suitable for the purposes described herein. Software and other modules may reside on servers, workstations, personal computers, computerized tablets, PDAs, and other devices suitable for the purposes described herein. Software and other modules may be accessible via local memory, via a network, via a browser, or via other means suitable for the purposes described herein. Data structures described herein may comprise computer files, variables, programming arrays, programming structures, or any electronic information storage schemes or methods, or any combinations thereof, suitable for the purposes described herein. User interface elements described herein may comprise elements from graphical user interfaces, command line interfaces, and other interfaces suitable for the purposes described herein.

Embodiments of the invention are also described above with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, may be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the acts specified in the flowchart and/or block diagram block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operations to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions that execute on the computer or other programmable apparatus provide steps for implementing the acts specified in the flowchart and/or block diagram block or blocks.

While certain embodiments of the inventions have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the disclosure. Indeed, the novel methods and systems described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions and changes in the form of the methods and systems described herein may be made without departing from the spirit of the disclosure. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of the disclosure.

Claims

1. A method for replicating data in a computer network from a source storage device to a destination storage device, the method comprising: replicating at a first time source data by copying the source data to create replication data, wherein the source data is stored on at least one source storage device associated with a source system, the source system comprising one or more source computer devices, the source data comprising a plurality of source files generated by one or more applications executing on the source system, andwherein the replication data is stored on at least one destination storage device associated with a replication system comprising one or more replication computer devices, wherein the one or more replication computer devices are different than the one or more source computer devices, the replication data comprising a plurality of destination files corresponding to the plurality of source files;following the replicating, identifying, by the source system, changed source files by tracking at a logical file level which of the plurality of source files changed between the first time and a second time after the first time, wherein said tracking comprises maintaining a journal file on the source storage device with entries identifying the changed source files at the logical file level;providing from the source system to the replication system, the changed source files at the logical file level by mounting the changed source files on the replication system wherein the replication system uses the mounting to obtain the logical file level associated with the changed source files;using the one or more replication computer devices associated with the replication system to identify, based on the changed source files at the logical file level, previously replicated destination files that are related to the changed source files;performing with one or more of the source computer devices associated with the source system, a source snapshot of the source data to capture a point-in-time copy of the source data on a block-by-block basis at the second time;accessing, with the one or more replication computer devices associated with the replication system, data blocks in the source snapshot with the mounting;comparing, with the one or more replication computer devices associated with the replication system, the data blocks in the source snapshot with data blocks in the previously replicated destination files stored on the at least one destination storage device on a block-by-block basis to identify changed blocks in the changed source files in the source data;replicating, with the one or more replication computer devices associated with the replication system, the changed blocks of the changed source files by determining with the one or more replication computer devices which copies of the changed data blocks to replicate from the source system to the at least one destination storage device; andnot replicating unchanged blocks associated with the changed source files.

2. The method of claim 1, additionally comprising, prior to performing the snapshot, quiescing one or more applications having access to the source data on the source storage device.

3. The method of claim 2, wherein said quiescing is performed at a known good state of the one or more applications.

4. The method of claim 2, additionally comprising instructing the one or more applications to assume a known good state.

5. The method of claim 1, wherein the source storage device comprises a shared storage device.

6. The method of claim 1, additionally comprising transmitting with the changed blocks time information indicative of the second time, wherein the time information is relative to a clock associated with the source storage device.

7. The method of claim 6, additionally comprising, following said replicating the changed blocks: performing a storage operation on the replication data to generate copied data; andlogically associating the copied data with the time information indicative of the second time.

8. The method of claim 1, wherein the duration between the first time and the second time is based on a storage policy stored in a preference database.

9. A system for performing data replication in a computer network environment, the data replication from a first storage device to a replication storage device, the system comprising: a source system comprising one or more source computer devices and at least a first storage device configured to store source data as a plurality of source files, the source system having one or more applications executing thereon and operative to write data to the plurality of source files stored on the first storage device;a replication system comprising one or more replication computer devices, wherein the one or more replication computer devices are different than the one or more source computer devices, the replication system configured to store replication data that is a replication of the source data at a first time, the replication data stored on at least one replication storage device associated with the replication system, the replication data comprising a plurality of destination files corresponding to the plurality of source filesa journal module configured to identify changed source files at a logical file level by tracking changes at the logical file level to the plurality of source files on the first storage device between a first time and a second time after the first time, the journal module tracking the changes at least partly by maintaining a journal file with entries identifying changed source files at the logical file level; andwherein the replication system receives a copy of the changed source files at the logical file level by mounting the changed source files on the replication system wherein the replication system uses the mounting to obtain the logical file level associated with the changed source files;a data agent module configured to execute on one or more of the first plurality of computer devices, the data agent module further configured to: instruct a creation of a source snapshot of the source data with the one or more source computer devcies to capture a point-in-time copy of the source data on a block-by-block basis at the second time;wherein the one or more replication computer devices associated with the replication system identify, based on the changed source files at the logical file level, the replication system identifies previously replicated destination files that are related to the changed source files;the one or more replication computers devices associated with the replication system accesses data blocks in the source snapshot with the mounting;the one or more replication computer devices associated with the replication system compares the data blocks in the source snapshot with data blocks in the replicated destination files stored on the at least one destination storage device on a block-by-block basis to identify changed blocks in the changed source files in the source data; andthe one or more replication computer devices associated with the replication system replicates the changed blocks of the changed source files to the replication copy on the replication storage device by determining with the one or more replication computer devices which copies of the changed data blocks to replicate from the source system to the at least one destination storage device and which unchanged blocks associated with the changed source files are not replicated.

10. The system of claim 9, wherein the first storage device is a shared storage device.

11. The system of claim 10, wherein the journal module comprises a new technology file system (NTFS) change journal.

12. The system of claim 9, wherein the changed blocks are identified using a secure hash algorithm.

13. The system of claim 9, wherein the source data consists essentially of application-specific data.

14. The system of claim 9, wherein the replication system further comprises a replication module in communication with the replication storage device, the replication module being in network communication with the data agent.

15. The system of claim 14, wherein the replication module is further configured to direct a storage operation to be performed on at least a portion of the replication files to generate copied data.

16. The system of claim 15, wherein the replication module is further configured to logically associate the copied data with a time stamp indicative of the second time.

17. The system of claim 16, wherein the second time identifies a time at which the source data is in a known good state.