Patent Application
20060018505
The present disclosure relates generally to information handling systems and, more particularly, to data management in information handling systems.
As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
Attempting to minimize backup windows, system administrators often prefer to backup data incrementally by backing-up only new or modified files. Current technology, such as “copy-on-write” snapshot backup utilities, is a preferred choice for data protection due to its speed, efficiency and ease of restoring a base or source volume to substantially any “point-in-time”. However, one problem with “copy-on-write” snapshot solutions is the inability of ordinary backup software applications to recognize the data structure of snapshots residing on a data volume. Due to the architecture of the snapshot's cache and pointer based system, it is generally not possible to successfully backup and restore, via an operating system's file system, the contents of a snapshot. Normally, backing up a snapshot via the file system will result in irrelevant data (pointers) being backed up, thus, resulting in invalid data when the snapshot is restored.
In accordance with teachings of the present disclosure, a method for providing enhanced data protection is provided. In an exemplary embodiment, the method preferably includes obtaining a first image of a data file, storing the first image of the data file in a first data storage area and storing data indicative of the first image in a second data storage area. The exemplary method preferably also includes obtaining one or more images of the data file subsequent to the first image in response to one or more monitored events. The exemplary method preferably further includes storing one or more of the subsequent images of the data file in the first data storage area and data indicative of one or more of the subsequent images of the data file in a second data storage area.
Further in accordance with teachings of the present disclosure, software for providing enhanced data backup is described. In an exemplary embodiment, the software is embodied in computer readable media. The software of an exemplary embodiment is preferably operable to copy, in an unprocessed data format, a first backup image of a data array residing in a first data storage area, the backup image residing in a second data storage area. The exemplary software is preferably also operable to store the copied first backup image in a third data storage area as unprocessed data. Further, the exemplary software is preferably operable to copy, in an unprocessed data format, one or more subsequent backup images created from the data array residing in the first data storage area, the subsequent backup images residing in the second data storage area. In addition, the exemplary software is preferably operable to store the one or more subsequent backup images as unprocessed data in the third data storage area.
In another aspect, teachings of the present disclosure describe an information handling system providing enhanced data backup and protection. An exemplary information handling system preferably includes memory, at least one processor operably coupled to the memory and a program of instructions storable in the memory and executable in the processor. In the exemplary information handling system, the program of instructions is preferably operable to perform copy-on-write snapshots of data residing on a first data storage device, store the snapshots on a snapshot data storage device and copy the snapshots as raw data to a raw data storage device.
In one aspect, teachings of the present disclosure provide a technical advantage in enabling the backup of existing copy-on-write and/or point-in-time snapshot volumes.
In another aspect, teachings of the present disclosure provide a technical advantage in the ability to further restore a system volume with granularity to substantially any point-in-time image.
In a further aspect, teachings of the present disclosure provide a technical advantage in the ability to resume backup operations from the point of failure or restoration.
A more complete understanding of the present embodiments and advantages thereof may be acquired by referring to the following description taken in conjunction with the accompanying drawings, in which like reference numbers indicate like features, and wherein:
Preferred embodiments and their advantages are best understood by reference to
For purposes of this disclosure, an information handling system may include any instrumentality or aggregate of instrumentalities operable to compute, classify, process, transmit, receive, retrieve, originate, switch, store, display, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, or other purposes. For example, an information handling system may be a personal computer, a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price. The information handling system may include random access memory (RAM), one or more processing resources such as a central processing unit (CPU) or hardware or software control logic, ROM, and/or other types of nonvolatile memory. Additional components of the information handling system may include one or more disk drives, one or more network ports for communicating with external devices as well as various input and output (I/O) devices, such as a keyboard, a mouse, and a video display. The information handling system may also include one or more buses operable to transmit communications between the various hardware components.
In many existing data centers, data may be backed up by taking a copy-on-write snapshot at defined or chosen intervals or in response to one or more monitored events. By taking data snapshots in such instances, a point-in-time image may be captured at that moment providing an administrator with an exact copy of volume data at the point the snapshot was taken.
Preferably, snapshot images are saved to a storage system such as one or more hard drive devices, tape drives, optical drives, storage area networks, etc. One problem with saving snapshots images to storage, however, is that all snapshots are typically collocated on a storage device which creates the risk that if the storage device fails, all snapshot images may be lost.
To overcome these and other shortcomings, teachings of the present disclosure, in general, describe technologies that grant data center administrators the ability to backup and restore existing copy-on-write and/or point-in-time snapshot volumes. In addition, with processes defining an ability to restore a failing or failed snapshot volume, teachings of the present disclosure also grant administrators the capability to further restore a system volume, with granularity, to substantially any point in time.
In an exemplary embodiment, teachings of the present disclosure address limitations in current technology by backing up all data blocks on a snapshot volume that contains snapshot images. Preferably, (remove perferrably) all data is backed up at a block level using a raw data enabled device, not via an operating system file system.
In one aspect, by backing up the entire data at the block data level, all data on a volume may be easily copied. In accordance with teachings of the present disclosure, the data blocks backed up preferably include all point-in-time images. According to teachings of the present disclosure, if a snapshot volume is lost due to one or more disasters or other storage failures, the volume may be recovered by restoring all block-based backups to a repaired or replaced snapshot volume storage device. Once a snapshot volume has been restored, an administrator is able to restore a system, base or source volume to any point-in-time image from the restored snapshot volume, should such restoration needs arise, e.g., from a failure of the base or source volume storage device.
Upon restoring a snapshot volume, linkages between the snapshot backup program and the restored snapshot volume must be reestablished, recreated or linked back together. In one aspect, this may be necessary because typical snapshot programs generally keep track of all point-in-time images that reside on the snapshot volume, and, if a snapshot volume is lost, linkages between the snapshot program and snapshot volume are typically also lost. Consequently, if a snapshot volume is lost and subsequently restored, the point-in-time images on the snapshot volume generally must be linked back to the snapshot backup utility or program.
In addition, both as added functionality to the teachings above as well as to the benefit of data center administration, this concept can be extended forward. Specifically, once a base or source volume is backed up, it may only be necessary to backup future snapshot cache files that reference the original volume. In one aspect, this may further optimize the backup process by reducing, for example, disk, tape, or other storage management costs. Any individual snapshot may be restored to disk, allowing full volume and/or file recovery.
Referring now to
At 14 of exemplary method 10, one or more enhanced data protection software applications incorporating teachings of the present disclosure are preferably activated or initiated. Operations preferably performed by one or more software applications operable to implement one or more portions of the enhanced data protection teachings of the present disclosure will be discussed in greater detail below and with respect to
A user preferred backup application, program, utility or methodology is preferably initiated at 16. According to an exemplary embodiment of teachings of the present disclosure, the backup methodology preferably initiated at 16 is a copy-on-write, point-in-time or other snapshot-based backup utility.
In general, a snapshot-based backup utility may be defined as backup utility operable to obtain an image or copy of a defined collection of data created substantially instantly at the point in time of imaging or copying. Snapshot copies may be made substantially immediately within a disk subsystem, regardless of the size of the source or base volume.
Further, copy-on-write snapshots may be generally defined as logical copies of data created by saving original, base or source data to a snapshot index whenever data in an original, or source base volume is updated. Essentially, the copy-on-write snapshot process creates an empty snapshot index holding the original values that later change in the base volume after the time of snapshot creation. As such, with copy-on-write snapshots, two writes occur when original, base or source data gets updated. The original, base or source value is first written in the snapshot index and the change to the base volume is then made.
Snapshot creation typically takes only as long as is needed to build a snapshot index. It is recommended that the source or base volume of data be quiesced or quieted during snapshot creation to enable capture of a stable image of the moment in time. A snapshot may be viewed by combining base volume data with the snapshot index containing original data changed in the base volume. There are various implementations of snapshot data backup and copy-on-write snapshot data backup that may be utilized with teachings of the present disclosure.
Following initiation of a preferred snapshot backup utility or application at 16, exemplary method 10 preferably proceeds to 18. At 18, normal processing of the preferred backup utility or application is preferably permitted and/or performed. As described in
In one aspect, raw devices may be defined as character oriented disk device files as opposed to block oriented disk files. Further, raw devices may be defined as unformatted disks or disk partitions that applications can use to bypass normal operating system procedures for reading and writing data to and from the disk. As such, by using raw devices, the file system of an operating system running on an information handling system may be bypassed allowing I/O operations to be efficiently performed.
According to teachings of the present disclosure, once I/O operations on the raw device have been quiesced at 22, exemplary method 10 preferably proceeds to 24. At 24, the original, base or source volume snapshot obtained 18 and stored in a snapshot volume at 20 is preferably backed up to a raw device using block level, raw data transfer. In one embodiment of teachings of the present disclosure, block level data backup may be described as data backup in which blocks of data, as opposed to character by character data movement, are placed into storage. As processed in accordance with teachings of the present disclosure, the blocks of data are preferably backed up as unprocessed or raw data.
Following the acquisition and storage of a base image of the source or base volume at 18 and 20, respectively, and/or following I/O quiesceing and block level backup of the base snapshot image at 22 and 24, respectively, exemplary method 10 preferably proceeds to 26. At 26, exemplary method 10 preferably performs one or more backup snapshots of all data at chosen intervals or in response to selected events in accordance with the normal operation of the preferred snapshot-based backup utility initiated at 16, e.g., copy-on-write, snapshots at defined time intervals, etc.
Following the acquisition of one or more backup snapshots at 26, exemplary method 10 preferably proceeds to 28 where the backup snapshot images are stored in a snapshot volume. Similar to the data snapshots taken at 18 and stored at 20, backup snapshots obtained at 22 are preferably stored in a snapshot volume data storage device maintained separate and apart from the original, base or source data volume at least for purposes of data availability and in accordance with preferred data backup practices.
Following storage of the backup snapshots to a snapshot volume at 28, exemplary method 10 preferably proceeds to 30. At 30, exemplary method 10 preferably provides for the quieting or quiescing of input/output (I/O) operations on a snapshot volume backup raw device operably coupled to the snapshot volume and/or base volume data storage devices.
According to teachings of the present disclosure, once I/O operations on the raw device have been quiesced at 30, exemplary method 10 preferably proceeds to 32. At 32, one or more backup snapshot images are preferably transferred to the raw device using block level, raw data transfer.
At 32, teachings of the present disclosure provide for at least two differing methodologies for backing-up a snapshot volume. In one embodiment, method 10 at 32 may provide for the entire source volume, i.e., the base snapshot image and any copy-on-write snapshot images, to be backed-up to a RAW device at each instance the snapshot volume is backed-up. In an alternate embodiment, method 10 may provide for the base snapshot image to be backed-up to the RAW device at 24 and provide for only copy-on-write snapshots to be backed-up to the RAW device at 32. In addition, modifications to and/or combinations of these two methodologies may also be implemented in accordance with teachings of the present disclosure.
As illustrated in
Referring now to
After beginning at 36, exemplary method 34 preferably proceeds to 38. At 38, exemplary method 34 preferably provides for monitoring the viability of the one or more maintained snapshot volumes and associated data storage devices. Recall that one embodiment of a snapshot volume may be defined as the one or more snapshot volumes to which one or more backup snapshots are stored during the operation of exemplary method 10 at 20 and 28.
If at 38 it is determined that the one or more snapshots volume being monitored remain viable, exemplary method 34 preferably loops at 38 to continue monitoring the one or more snapshot volume data storage devices. A delay following a snapshot volume data storage device viability inquiry may be included such that snapshot volume viability is periodically checked as opposed to continuously monitored.
Alternatively, if at 38 it is determined that one or more monitored snapshot volume data storage devices has failed or may be described as failing according to one or more operational parameters, exemplary method 34 preferably proceeds to 40. At 40, exemplary method 34 preferably provides for initiation of a rebuild process for the failed or failing snapshot volume data storage device. As a part of the snapshot volume rebuild process preferably initiated at 40, exemplary method 34 preferably provides for the restoration of the snapshot volume to a repaired or replaced snapshot volume data storage device using the block data stored in the snapshot backup raw device.
Following the restoration of a snapshot volume via transfer of the snapshot backup block copied data from the raw device at 40, exemplary method 34 preferably proceeds to 42. At 42, linkages between the restored snapshot volume and the preferred snapshot-based backup application controlling snapshot backup operations on the base or source volume and the snapshot volume are re-connected. In at least one aspect, as described above, this recreation preferably enables linkages between the snapshot volume and the snapshot index to be reestablished.
Following restoration of the snapshot volume from the block data copied snapshot backup information at 40 and the recreation or reestablishment of linkages between the snapshot backup program and the restored snapshot volume at 42, exemplary method 34 preferably proceeds to 44. At 44, the source volume may be restored to any desired point in time image from the data available in the associated snapshot volume or a restored snapshot volume. At 45, exemplary method 30 provides for the resumption of normal or standard snapshot backup procedures, such as those typically managed by the preferred snapshot backup utility initiated at 16.
In one aspect of teachings of the present disclosure, normal or standard snapshot backup procedures may be continued from the point of restoration forward. In other words, the snapshot program need not capture an image of the restored system and then begin backing up snapshots in accordance with copy-on-write or other snapshot utility settings. Instead, the preferred snapshot utility may continue backing up data with snapshots triggered by copy-on-write or other triggers. In this manner, time, effort and data storage space may be conserved as the snapshot backup utility may proceed as if a failure had not occurred. Following the operations preferably performed at 44, exemplary method 34 preferably returns to 38 where the restored and other snapshot volumes may be monitored for their viability.
Referring now to
As illustrated in
In addition, information handling system 48 may also include one or more communication interfaces 56. Communication interface 56 preferably enables information handling system 48 to communicate with one or more internal or external data handling components. For example, communication interface 56 may enable information handling system 48 to communicate with one or more external storage devices 58, 60 and 62, a storage area network, and internal or external optical drive, as well as numerous other information handling system components.
As illustrated in
Also illustrated in
Referring now to
Following the capture of an image of data 64 and storage of the base snapshot image data 66, a block copy process may be initiated to place a block level copy 68 of base snapshot data image 66 on raw data-enabled device 62. Preferably, prior to block level, raw data copying of base snapshot data image 66, all I/O on raw device 62 will be quiesced.
Having created base, source or original data 64, exemplary method 10 preferably enters a copy-on-write or other triggered snapshot backup mode at 26, as described above. Also as described above, exemplary method 34, after establishing snapshot volume 60, preferably enters a snapshot monitoring mode at 38.
Base data 70 reflects a change in original data 64. In accordance with exemplary method 10, a copy-on-write event has occurred which results in the preferred copy-on-write snapshot backup utility, at 26, performing a snapshot of the changes to data 64. Following acquisition of the snapshot of the changes to data 64, exemplary method 10 provides for storage of the data change as backup snapshot image 72 on snapshot volume 60.
As described above, copy-on-write snapshot utilities typically maintain an index or other linkage reference (not expressly shown) which tracks and/or associates stored base or source data images with copy-on-write or other subsequently stored snapshot images. Accordingly, in conjunction with placing data change backup snapshot image 72 on snapshot volume 60, a pointer or other reference is noted indicating that changed data backup snapshot image 72 replaces, supplements or otherwise affects data subset 74 of base snapshot image 66. As mentioned above, such linkages or indices enable the copy-on-write program to reconstruct a source or base volume upon failure. Recall that a variety of triggers may be utilized with a preferred snapshot backup utility including, without limitation, data alterations, new data being written, or one or more other triggers.
As with base, source or original data snapshot image 66, changed data backup snapshot image 72 is preferably copied to raw device 62 using a block level, raw data transfer mechanism at 32 of exemplary method 10 creating block data 76. Similar operations preferably occur in response to base data 78 resulting in changed data backup snapshot image 80 associated with base data subset 82 and raw device block level data copy 84.
In an alternate to backing-up a single copy of base snapshot image 66 and any subsequent copy-on-write snapshot images, such as copy-on-write snapshot images 72 and 80, as mentioned above, teachings of the present disclosure may also provide for back-up of entire snapshot volume 60 at regular intervals, such as in response to placement of copy-on-write snapshot 72 or 80 thereon. In such an embodiment, following the creation of snapshot image 72, base snapshot image 66 and copy-on-write snapshot image 72 would be added to RAW device 62 where a back-up copy of base image 66 preferably already exists. Continuing, in response to the creation of copy-on-write snapshot image 80, such an embodiment would preferably provide for base snapshot image 66 as well as copy-on-write snapshot images 72 and 80 to be backed-up to RAW device 62 thereby creating on RAW device 62 a back-up copy of base snapshot image 66, a second back-up copy of base snapshot image 66 plus copy-on-write snapshot image 72 and a third back-up copy of base snapshot image 66 plus copy-on-write snapshot images 72 and 80.
Prior to teachings of the present disclosure, if snapshot volume 60 were to fail, all data maintained thereon would be lost and source volume 58 would be without a backup copy. With the benefit of teachings of the present disclosure, a failed snapshot volume may be restored or replaced from the block-level, raw data maintained on raw device 62.
As described above with respect to exemplary method 34, a failed or failing snapshot volume may be restored from the block-level, raw data maintained on raw device 62. Upon detecting a failed or failing snapshot volume, and upon the replacement of any necessary hardware, data from raw device 62 may be placed on the replacement or repaired snapshot volume such that all relevant data is restored. In addition to returning all relevant data to the replaced or restored snapshot volume, linkages base between the base or source data images, such as backup snapshot 66, and copy-on-write or other subsequent snapshots, such as changed data backup snapshot images 72 and 80, are restored. In this manner, snapshot volume 60 may be restored to the point at which the failure occurred. In an alternate or enhanced implementation, a snapshot volume may restored to virtually any point in time, such as to the point of change in base or source snapshot image occurring in backup snapshot image 72, prior to the change reflected at changed data backup snapshot image 80. From this, the preferred snapshot backup utility need not restart the backup process from the point of capturing a base or source snapshot, but instead may proceed from the chosen restoration point, which, in some instances, permits the snapshot backup utility to continue as if there had never been a snapshot volume failure.
Although the disclosed embodiments have been described in detail, it should be understood that various changes, substitutions and alterations can be made to the embodiments without departing from their spirit and scope.
