fig1 is a diagram illustrating the hardware components and interconnections among components according to one embodiment of the invention . as shown by the diagram , the system is generally divided into two parts , a host 10 and a storage subsystem 20 . host 10 typically is a commercially available conventional computer system , for example , a server . in the depicted embodiment , host 10 includes a central processing unit ( cpu ) 12 , memory 14 , and storage 15 . storage 15 typically will provide storage for an operating system , application software , and storage subsystem management software . the storage subsystem 20 includes a control processor 22 and a series of storage volumes 25 for storing data . storage volumes 25 typically are provided by hard disk drives or arrays of hard disk drives , for example , configured as a raid system . like the host 10 , the control processor 22 typically will include a central processing unit , and preferably includes non - volatile random access memory ( nvram ). the control processor can store data to the nvram and protect it , e . g . from a power failure . storage volumes 25 are typically arranged as a series of primary and secondary volumes . typically the primary volumes are used for the storage of data used by the computer system , while the secondary storage volumes often are providing redundant storage to assure higher data reliability . the storage volumes may be configured in a variety of known configurations , for example , raid 0 , raid 5 or other technology . in fig1 the host and storage system are illustrated as coupled together using an ethernet based network . other well known connections may also be used , for example , fibre channel , scsi , and iscsi , token ring , etc . for the control of the storage subsystem , the block input / output operations can be provided over an in - band connection . if the storage subsystem supports a file server such as nfs or cifs , the controller module may also provide a file server feature to export data stored as a file into the primary and secondary volumes . the hardware shown in fig1 is all conventional and commercially available computer system components . fig2 is a diagram illustrating the software components and virtual interconnections among them for the hardware system illustrated in fig1 . in fig2 , a solid line is used to indicate the direction of data access , while a dashed line indicates the direction of control . as shown in fig2 , the host cpu runs application programs ( app ), a file system ( fs ), and a recovery tool for the application data and the file system . in addition , the host may also run a scheduling module , a manager module , and a cli / gui interface for management of the overall system . a part of the memory on the host is used for these various modules . typically the application and file system components have features like “ journal ” to recover data whenever the application fails . such tools are usually provided by the operating system vendor or the application vendor as a technique for enhancing the likelihood of recovery of information that might otherwise be lost when a program crashes . for example , at a file system level , netapp provides such technology in its data ontap ™ products and veritas also provides it in its veritas filesystem ™. in addition , the operating system vendor often provides a file system recovery tool similar to “ fsck .” as example of data recovery tools provided by application vendors see , oracle &# 39 ; s version 9i “ fast start checkpointing ” or microsoft &# 39 ; s office tools document recovery . in the preferred embodiment depicted in fig1 and 2 , these recovery tools are employed to enhance the reliability of data storage and retrieval from the system . in large storage systems , the taking of “ snapshots ” is a well - known technique for providing backup information . see , e . g . hitachi data systems software solutions guide , page 38 . in effect , a snapshot consists of a record of the state of all the data on the volume at a given time . such a record enables restoration of the storage volume to at least an earlier condition known as of a fixed time . the handling of snapshots for the system depicted in fig2 is the responsibility of the scheduler module . it maintains a schedule for the taking of snapshots , and stores that schedule as a file on the disk 15 in the host ( fig1 ). fig3 is an illustration of such a file for scheduling snapshots . as shown , the file includes a duration , a process , and an owner for each record . in the example depicted in fig3 , a snapshot , taken every one minute , is shown as the first line entry , and a backup operation scheduled to occur every hour is shown as the second line entry . the manager module 32 in fig2 processes two different kinds of events . the first process is the creation of snapshots . this is typically achieved using an applications program interface ( api ) “ create_snapshot ” which is invoked by the scheduler module 31 . the second process is the restoration of data , for example as requested by the administrator , using a command line interface ( cli ) or a graphical user interface ( gui ) interface . fig4 is a chart which illustrates a summary of the snapshots as might be used in conjunction with a restoration operation . as shown in fig4 , the summary includes the name of the targeted restored data , the time the snapshot was taken , the status of the data , the restore time from the perspective of an application ( referred to as the application time ) assuming the application provides a recovery tool . frequently an additional column is provided , designated snapshot id , to identify a snapshot from among several different snapshots on the storage system . the fields for the summary of snapshots are name to provide a name for the snapshot , application time to indicate when the snapshot was taken from the point of view of the application , an arbitrary snapshot id , and a field designated “ status of data .” this last field is explained below . for the particular application of restoration of data , as described here in the preferred embodiment , there are two main parts . the first part is the creation of the snapshot , as invoked by the scheduler module 31 by calling the appropriate api ( create_snapshot ). the second part is the restore operation itself , typically triggered by the administrator wishing to restore data from a selected snapshot . fig5 is a flow chart illustrating the creation of the snapshot . after the process starts at step 40 , the snapshot is taken under control of the manager module 32 in the host 10 ( fig1 ). this is shown in step 41 in fig5 . in step 42 the file system and the data in the snapshot are recovered . this is typically performed by the manager module 32 requesting a recovery tool to make a consistent state for the file system and the applications data . for the file system , a typical recovery tool is fsck , while for the application , the tool is typically one provided by the vendor of the application . if the system employs primary and secondary volumes in a file system level , for example as in an nfs server or a cifs server , then the recovery tool will execute the application &# 39 ; s recovery tool . on the other hand , if the implementation uses these in block level , then the recovery tool will execute the file system &# 39 ; s fsck and the application &# 39 ; s recovery tool . during the recovery the manager module inserts into the snapshot summary table of fig4 , under the heading status of data , a status of “ confirming .” as shown in fig5 , the next step is to insert the result of the snapshot . this result will be “ recovered ” if the recovery is successful . if successful , the manager inserts the result into the status of data field as “ consistent ( recovered )”. on the other hand , if the recovery fails , then the result will be “ inconsistent ( un - recovered )” ( see line 3 of fig4 ). fig6 is a diagram illustrating operations relating to the restore process . the restore operation provides the data selected by the administrator from a summary of the consistent snapshots . as shown in fig6 , the flow chart begins with step 50 and proceeds to request a summary of snapshots at step 51 . in response , the manager module returns the summary 52 shown in fig4 . a snapshot 53 is then requested . as shown by step 54 , the requested snapshot is then exported to the host . at step 55 , the snapshot is mounted onto the host , then at step 56 , assuming the administrator has so requested , the manager module begins to run the application using the recovered data . as a result of the operation and the interface , the administrator is able to distinguish which snapshots are consistent and which are not . this enables easier access to the snapshot and restoration . fig7 is a diagram of an alternate implementation for the software components previously shown in fig2 . note that in fig7 , the scheduler module , rather than being located in the host , is located in the storage subsystem control processor . in this implementation the scheduler is able to execute creation of a snapshot by itself . furthermore , the schedule file ( corresponding to fig3 ) will now also be located in the control module in the storage subsystem . fig8 is a diagram illustrating the creation of a snapshot in the implementation depicted in fig7 . as shown in fig8 , the snapshot is created at step 80 by use of the macrocode of the controller . next , the file system and data in the snapshot are recovered as shown by step 81 . the recovery tool for the file system is the fsck operation , while the recovery tool for the application is the tool provided by the application vendor . if primary and secondary volumes are employed , for example in the manner of an nfs server or a cifs server , then the recovery tool for the file system will execute a recovery tool for the application . on the other hand , they can be executed separately and controlled separately . as discussed above , during the recovery operation , the manager module will insert the status “ confirming ” into the summary . at step 82 , the results of the snapshot are inserted . this is accomplished by the manager module inserting the results of the recovery . if the recovery failed , the manager inserts the result “ inconsistent ( un - recovered ).” if the operation is successful , then the manager inserts the result as “ consistent ( recovered ).” fig9 is a diagram illustrating a different hardware configuration than in fig1 . in this implementation , the recovery module of the application after the creation of a snapshot is changed . the components shown in fig9 are generally similar to those shown in fig1 , however , two hosts are now provided — an on - line host 90 and a snapshot management host 100 . storage subsystem 20 remains the same as that described in conjunction with fig1 . there are , however , two channel interfaces provided to the storage system designated “ fc .” each of the two hosts 90 and 100 can see and share volumes on the storage subsystem 20 . if necessary , the storage subsystem 20 may be enabled to control access to its volumes from the host when the administrator assigns a worldwide name ( wwn ) that is a unique number for the host bus adaptor . this capability is often referred to as logical unit number ( lun ) mapping . additional communications among the hosts and storage subsystem are provided an ethernet connection , however , other well - known interfaces may also be employed . fig1 is a diagram illustrating the software components for the hardware implementation of fig9 . as shown in the upper portion of the figure , a significant difference between the arrangement shown in fig1 and that depicted in fig2 is that the functionality is separated between the two hosts , depending upon the particular task involved . in fig1 , the online host includes the file system ( fs ), the application server portion , and an agent . the snapshot management host includes the remaining components from fig2 . the online host 90 runs the application and file system , while the snapshot management host performs snapshot management based on the defined schedule , and maintains data recovery tools as installed . each of the modules shown in fig1 operates in the same manner as previously described above . because the manager module cannot control the application and file system operations directly , an agent is inserted into the online host to provide capability of controlling the application startup and shutdown . fig1 is a diagram illustrating the operational sequence for the module shown in fig1 . as shown in fig1 , the steps of mount the snapshot 110 and start the application using the recovered data 120 have been moved to the agent . all other steps are carried out in the same manner as with respect to fig6 . fig1 is a diagram illustrating another implementation of the invention in which the scheduler 125 is implemented in the control processor of the storage subsystem 20 , in the same manner as shown in fig7 . this enables the scheduler to execute the snapshot by itself from within the control processor in the storage subsystem 20 . the foregoing has been a description of the preferred embodiments of the invention . it will be appreciated that various modifications may be made to the implementation of the invention without departing from its scope , as defined by the following claims .