WO2007017857A1

WO2007017857A1 - Accelerated computer recovery

Info

Publication number: WO2007017857A1
Application number: PCT/IL2006/000475
Authority: WO
Inventors: Zak Dechovich
Original assignee: Zak Dechovich
Priority date: 2005-04-15
Filing date: 2006-04-20
Publication date: 2007-02-15

Abstract

A method and system for essentially instantly recovering a computer and making it speedily available for work, by connecting it to a data source containing information necessary to perform recovery, and utilizing the information in that data source selectively in a preferred order according to the immediate tasks requested of the computer (figure 2). This is in contrast to prior art method of installing, configuring and copying all of the applications, files and resources necessary to perform the intended tasks on the computer. The computer does not need to have a complete set of resources in their correct locations in order to start working immediately, but can begin operation with a limited number of files and resources, sufficient to make the computer, application, or user feel as if a state of a desired recovery exists. The standard recovery process continues to run in the background until complete.

Description

ACCELERATED COMPUTER RECOVERY

FIELD OF THE INVENTION

The present invention relates to the field of computer operation recovery, especially for implementation after system crashing or for recreating a full working state computer from a previous working configuration.

BACKGROUND OF THE INVENTION

The ability to restore full hard-drive imaging and back-up is not new, but it involves much time spent on backup, snapshots, reinstallation, configuration, etc. For example, to recover a computing system after crashing, or to recreate a full working state computer, one has to install the operating system, install the appropriate drivers, install the applications, set-up the applications (e.g. Outlook mail address, signature, etc.), defining the computer settings, define network settings, copy all the files, validate passwords, and similar routine set-up tasks.

Normal imaging or snapshots can restore the computer to a previous state rapidly, but generally needs to have exactly the same hardware in order to operate immediately. Otherwise, it takes time is needed to perform the necessary re- installation.

There does not exist in the prior art, a simple and speedy method to enable a complete working environment to run on a new computer without a full installation procedure, including file moving, and other routine chores.

Furthermore, when the need arises to move a complete installation with its programs and data files from one computer to a new one, it is generally necessary to reinstall everything from scratch and reconfigure the complete installation, making this a long and arduous procedure, with the added danger of missing files, thus resulting also in data loss.

There therefore exists a need for a method to rapidly recreate a full working state computer from a previous system, either after crashing or on new hardware. SUMMARY OF THE INVENTION

The present invention seeks to provide a system and method for essentially instantly recovering a computer and making it speedily available for work, by connecting it to a data source containing information necessary to perform recovery, and utilizing the information in that data source selectively in a preferred order according to the immediate tasks requested of the computer. This method is in contrast to prior art methods of having to execute the arduous procedure of installing, configuring and copying all of the applications, files and resources necessary to perform the intended tasks on the computer. This procedure is called "Instant Recovery" in this application, where the term "instant" is understood to mean a time significantly shorter than the time generally taken to perform a recovery according to prior art methods.

The method can be preferably used for performing multi-platform, instant recovery to a full working environment when connected to any predetermined data source, whether by network, direct, indirect, or a flash-memory, hard-disk, different partition, PXE (Pre-boot execution Environment), hardware or any other manner known in the art for storing data.

The method and system utilize the fact that a computer, an application, or a user, does not need to have a complete set of resources all in their correct locations in order to start working immediately. It is sufficient to begin operation with a very limited number of files and resources, sufficient to make the computer, application, or user feel as if a state of a desired recovery exists. The computer, application or user, retrieves the necessary resources as soon as they are needed. In this manner, just the files needed for the immediate task in hand would be copied initially and immediately, while the standard recovery process still runs in the background.

At the initial connection, the system and the preferred methods of the present invention operate such that the whole computer, bios, operating system and applications perceive what they would see if the whole recovery process were completed, this perception depending on the computer state. However, the files and resources, etc which the computer "perceives" are only apparently present, but are not necessarily present. Such states are defined in the preferred examples below as being "only visible".

To perform a multi-platform instant recovery, the system needs to constantly backup all the files, and preferably separate those that are not the operating system or local computer drivers.

For this purpose, the computer may be described as a 3 layer concept:

The Hardware

The Operating System + Drivers Applications and Files

Because of the variation of hardware from one machine to another, the operating system with its drivers exists to create a common execution platform for the applications and files.

There are generally two recovery processes that may be performed separated or in unison:

(i) Recovery of the operating system to a working condition, preferably including the required drivers, (ii) Recovery of the applications, settings, files, suitable resources, etc.

To perform a successful multi-platform, multi-machine recovery (due to changes in the o/s and drivers), the operating system and machine-specific files have preferably to be separated from the applications and their files. Otherwise, all need to be installed from scratch.

Separation can be performed preferably using one or more of the following methods: i) Using a preset file list expected to be a part of the operating system, e.g. Windows^® 2000, Windows xp^® sp1 , Windows xp^® sp2, etc. ii) Manual selection iii) Using a file's version and manufacturer i.e. DLLs, EXEs, etc. iv) By the time-stamp, e.g. files created or modified after initial installation, etc. v) Scanning a computer's configuration (e.g. windows registry, etc) to determine which files belongs to a specific hardware, vi) Determining "Exclude areas" and/or parts. vii) Comparing the files between all the backed up machines and concluding which files are the o/s. Comparing between all the machines may create a problem when a common application will be skipped (such as MS-Office^®), but together with the other methods given here (i-vi and viii-x) it will work. viii) Examining installed applications or parts and extrapolating their files, i.e. through normal uninstall programs, registry's class entry, etc. ix) Keeping a log of every file that is being used by the application. x) Assuming the recovery is being performed on a newly installed machine, the method should not overwrite any existing files which are obviously part of the o/s.

Retrieving files, resources, etc. from a data source during the recovery process can be performed by one of the following methods: (i) Retrieving a full or partial file, or a resource directly from the data source; (ii) Obtaining information which identifies a file or a resource from the data source such as by their name, location, unique checksum, or the like, and retrieving the full or partial file or resource from another machine having that file or resource, if uniquely identified, thereby saving bandwidth to the server (peer to peer)

Storing files, resources can preferably be performed by: (i) Calculating a unique checksum.

(ii) Ensuring that the server has no copy of the file or resource with the same name and unique checksum.

(iii) If none is found, then sending and registering

(iv) If there is - linking the file in the data source without actually sending the file or resource, to save bandwidth and storage space. For instance, if there are 10,000 installations of MS-Office^®, it will be sent only once, and for the other 9,999 times, only the unique checksums will be sent.

During normal work, the client will send modified files, registry, resource, etc. that are not part of the O/S or the current machine platform, to the data source, and will create the latest snapshot.

There is therefore provided according to a preferred embodiment of the present invention, a method of instant recovery of a computer having at least one existing resource, input, output and processing capabilities, comprising the steps of: (i) defining a desired state of recovery of the computer, (ii) connecting the computer to a data source, the data source comprising at least one of the at least one existing resource and at least one external resource, necessary for recovery to the desired state of recovery,

(iii) handling desired input/output requests of the computer to use the data source such that the results of the requests are perceived as if the requests were performed at the desired state of recovery,

(iv) retrieving a desired part of the data source necessary for recovery to the desired state of recovery, and

(v) prioritizing the retrieved parts necessary for recovery and not yet retrieved from the data source, as required by the requests, according to the desired state of recovery.

In the above-described method, that least one external resource may preferably be accessed by a peer-to-peer process. In such a case, the peer-to- peer process is preferably performed by obtaining information which identifies the desired part from the data source, and retrieving the desired part from another data source having that desired part. The identifying step preferably comprises at least one of the name, location and unique checksum of at least part of a file in the desired part.

There is further provided in accordance with yet another preferred embodiment of the present invention, any of the methods described above, wherein any of the resources preferably comprises any one of information on any item that the computer is constructed of, uses, utilizes, enhances, is enhanced by, is used by, is utilized by, executes, inputs, outputs or stores. Such information preferably resides in at least one of a logical object, hardware and software.

In accordance with still another preferred embodiment of the present invention, in any of the above methods, the retrieving is preferably performed as a background process.

In accordance with a further preferred embodiment of the present invention, there is also provided a computing system which runs software utilizing any of the above-described methods, such that it can be recovered more speedily than by installing, configuring and copying of the applications, files and resources necessary to perform the intended tasks on the computer. An Application is defined, for the purposes of this application, as any code that is executed by a computer. The application's input, output and processing are a logical group within the computer's input, output and processing, respectively.

A Resource is defined, for the purposes of this application, as the information on anything that the computer is constructed of, uses, utilizes, enhances, is enhanced by, is being used by, is being utilized by, executes, inputs, outputs, stores, or logical objects, hardware or software in their different possible embodiments.

A data source is defined, for the purposes of this application, as any one of a database, a storage, a file, a resource, a part of a resource or a computer.

A Requestor is defined, for the purposes of this application, as a computer, a process, a user, an application, hardware or any other entity that requests to perform an operation.

A Serving Layer is defined, for the purposes of this application, as a direct or indirect element that executes, receives and responds to the requestor's requests, actions, etc. and may be a computer, server, hardware, bios, operating system, application, network, etc.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be understood and appreciated more fully from the following detailed description, taken in conjunction with the drawings in which:

Fig.1 is a flow chart illustrating schematically the operation of a computer, as is known in the art;

Fig. 2 is a flow chart which illustrates schematically how the methods of a preferred embodiment of the present invention are incorporated within the operation of a typical computer installation;

Fig. 3 is a flow chart which illustrates schematically how the get view step of Fig. 2 is performed;

Fig. 4 is a flow chart which illustrates schematically how the handle open step of Fig. 2 is performed;

Fig. 5 is a flow chart which illustrates schematically how the handle read step of Fig. 2 is performed; Fig. 6 is a flow chart which illustrates schematically how the handle write step of Fig. 2 is performed;

Fig. 7 is a flow chart which illustrates schematically how the Background/update step of Fig. 6 is performed; and

Fig. 8 is a flow chart which illustrates schematically how the Background pre/fetch operations are performed.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Reference is now made to Table I which illustrates schematically the progress of the various steps of a preferred method of the present invention, for the preferred example of a newly installed computer about to be recovered. The example may be for an empty computer or for a computer with an operating system installed. For each step of the instant recovery process, there is shown the content of the machine compared to the content of the data source from which the machine will acquire the content to recover.

In step 1, there is shown the initial condition of a new computer with a minimal number of files, namely file 1 and file 2, needed to boot.

In step 2, the computer is connected to the data source. The files and resources in the data source become "visible" at the computer, but are not yet physically there.

In step 3, the computer in still in an unusable state, without any applications being called. Registry, file3 and file4 have already been retrieved. The next step is for the copying of all the remaining files and resources.

In step 4, as an example of a user-generated step, the user double clicks on file728, for instance, which may preferably be an application. File728 is therefore prioritized and the file or its relevant parts are retrieved from the data source, such that they are now available to the user.

However, execution of file728 requires fileδOO, file121 and file998, for example. Consequently, in step 5, these files and resources that are not yet retrieved, are now fully or partially retrieved, depending on the request made by the user. In step 6, according to another preferred outcome of the user's actions, a running application has created a new file - file1001. This file is stored at the data source, preferably immediately, or asynchronously or marked for storage.

In step 7, according to another possible scenario, file728 was modified and has become file728 version 1.001. It is then stored in the data source as a new version, preferably not overwriting the previous file.

Finally, in step 8, after some time has elapsed, during which the user continues to work transparently on the computer, all the files and resources necessary for the full operation of the computer have been copied, and the machine is running with its complete installation and configuration.

Thus, by means of the method of the present invention, during the entire process described, the user is virtually unaware that the computer is not fully installed and configured, and except for the initial stage, performance is very little affected.

TABLE 1

Reference is now made to Figs. 1 to 7, which illustrate schematically how the methods of the present invention are technically implemented, according to various preferred embodiments.

The figures show an exemplary implementation. For the purpose of this example, this embodiment uses Microsoft Windows NT^® terminology and technology, but may also represent a boot using PXE when the requestor's requests are direct disk access. The concept described in the given examples is the same, e.g. Read File or Read Sector or Read any other resource are the same. Reference is now made to Fig. 1 , which is a flow chart illustrating schematically the typical operation of a computer, as is known in the art. A Requestor, which is normally an application, requests an operation or data from or through the serving layer, which is usually the O/S bios and the like, which performs an operation on the data source. The data source returns the requested data or status if accessible or if it exists, and the serving layer thus satisfies the requestor's request, if possible.

Reference is now made to Fig. 2, which is a flow chart which illustrates schematically how the methods of a preferred embodiment of the present invention are incorporated within the operation of a typical computer installation, such as that of Fig. 1. When the system is not in a recovery mode, and no objects are created or modified in the data source, for example, "create file" and "write file", the requests are passed through unchanged.

When the system is in the recovery mode, the serving layer requests are handled so that the system will make the serving layer perceive a different desired view than on the local data source. The system creates the desired view, and if unavailable, it asks for an image of the desired view. This desired view is used to handle and satisfy the requests of the serving layer. If any of "view Enumeration" (traverse), view open, view read, view write, or any other view request, are requested, the system returns the serving layer with the appropriate current view, so that the serving layer is able to complete its function. In addition, when handling a write request, the system keeps track of the new or modified data view, as shown in Fig. 6 below.

If however, the system is in the non-recovery mode, but objects are created or modified, the system keeps track of the new or modified data view. All of these handled requests are expounded further in Figs. 3 to 8 below.

Reference is now made to Fig. 3, which is a flow chart which illustrates schematically how the get view step of Fig. 2 is performed. The system first checks whether the requested view exists. If not, an error "no image' is returned. If the image does exist, the supposed view is retrieved from a data source holding the desired view. This supposed view is then merged with the current system's local view. For example, an empty local C drive would be merged with how the C drive should look after full recovery. Reference is now made to Fig. 4, which is a flow chart which illustrates schematically how the handle open step of Fig. 2 is performed. The system first checks whether the requested desired object exists locally, meaning that it is on the local disc. If it does, then no handling is required. If not, the file data is retrieved. If access is not permitted, the serving layer is notified that access is denied. If access is permitted, then the system pre/fetches the object or object parts needed for a minimal open operation to succeed, and predicts what object or object parts is next needed, as shown hereinbelow in Fig. 8. For example, opening a file that does not yet exist in the local storage will cause just its minimal parameters to be retrieved, such as file size, file name, security attributes, and the prediction is that its content will be soon needed. When a new file is created, it is handled as a part of a write/modify operation.

Reference is now made to Fig. 5, which is a flow chart which illustrates schematically how the handle read step of Fig. 2 is performed. If the desired object or object parts exist locally, then no handling is required. If it does not, then the system pre/fetches the object or object parts needed for a minimal open operation to succeed, and predicts what object or object parts is next needed, as shown hereinbelow in Fig. 9. There is no delete handling since the delete request is performed by a write operation.

Reference is now made to Fig. 6, which is a flow chart which illustrates schematically how the handle write step of Fig. 2 is performed. If the desired object or object parts exist locally, then no handling is required. If it does not, then the system pre/fetches the object or object parts needed for a minimal open operation to succeed, and predicts what object or object parts is next needed, as shown hereinbelow in Fig. 8. The system also keeps track of the new or modified data view, as will now be explained in Fig. 7.

Reference is now made to Fig. 7, which is a flow chart which illustrates schematically how the Background/update step of Fig. 6 is performed. The system keeps track of the modified view so that the system is able to perform changes on files which have not yet been restored, and to allow an incremental back-up during recovery.

Reference is now made to Fig. 8, which is a flow chart which illustrates schematically how the Background pre/fetch operations are performed. The system retrieves the minimal immediately needed objects, or object parts, from the data source. Then it stores the retrieved data in the local storage and prioritizes or predicts the remainder of the files needed according to standard caching mechanisms or logical assumptions. Examples of such operations are that if a file is opened, it is clear that at least some of its contents will be needed soon, or if a file is being read sequentially and is currently, for instance, 40% read, it is clear that the application will soon request the following sequential bytes of the file, taking into account the transfer rate, allocation size, time taken, and other similar factors, as is known in prior art operating system caching methods. The standard background recovery process then continues normally and retrieves the remaining needed objects.

As an example of the power of the methods of the present invention, a recovery using these methods was made of a computer with 25GB connected to a data source over a IOOmbps (12.5mb/sec) network. The recovery was measured from power-on to a full recovery state, including O/S, applications and files, and assuming the bandwidth to be free. A normal boot takes about 2 minutes, uses 1 ,000 files, which total 100Mb, and not all of the operations are performed on the disk. It is sufficient to copy only the requested resources, on average, 833kb out of 12,500kb per second to make a normal boot as if all of the necessary resources were installed. The rest of the bandwidth is used to recover the rest of the files. During the boot time there was 11 ,667kb per second of free bandwidth which recovered an additional 1.4GB from the data source. The full recovery is completed only after 30 minutes, but the computer is usable from the start.

According to further example, a computer with a clear operating system installed, and without applications, has to be recovered to a full working state. When connected to a data source the computer, the applications and the user using the computer, all perceive the computer and all the resources as if they were restored to a desired state. In the above example, the user starts an application, assuming the application has to be installed in the registry, having 1 ,000 files, which are 1GB installed in various places in the disk and checks that all the installation is valid. In fact, the operations when started comprise only the opening of 10 files (10mb). The resources to be recovered are merged with the existing resources, for example, the applications registry entry is merged with the existing registry. The application would access the registry resource and will get the expected results, will check if all the files are there, and will get expected results. It will open the desired 10 files that will be retrieved from the data source if not retrieved yet. The application would start normally as if it was already installed. The remaining resources will be completed later.

It is appreciated by persons skilled in the art that the present invention is not limited by what has been particularly shown and described hereinabove. Rather the scope of the present invention includes both combinations and subcombinations of various features described hereinabove as well as variations and modifications thereto which would occur to a person of skill in the art upon reading the above description and which are not in the prior art.

Claims

1. A method of instant recovery of a computer having at least one existing resource, input, output and processing capabilities, comprising the steps of: defining a desired state of recovery of said computer; connecting said computer to a data source, said data source comprising at least one of said at least one existing resource and at least one external resource, necessary for recovery to said desired state of recovery; handling desired input/output requests of said computer to use said data source such that the results of said requests are perceived as if said requests were performed at said desired state of recovery; retrieving a desired part of said data source necessary for recovery to said desired state of recovery; and prioritizing said retrieved parts necessary for recovery and not yet retrieved from said data source, as required by said requests, according to said desired state of recovery.

2. A method according to claim 1 wherein said at least one external resource Is accessed through a peer-to-peer process.

3. A method according to claim 2 wherein said peer-to-peer process is performed by obtaining information which identifies said desired part from the data source, and retrieving said desired part from another data source having that desired part.

4. A method according to claim 3 wherein said identifying comprises at least one of the name, location and unique checksum of at least part of a file in said desired part.

5. A method according to any of the previous claims wherein any of said resources comprises any one of information on any item that the computer is constructed of, uses, utilizes, enhances, is enhanced by, is used by, is utilized by, executes, inputs, outputs or stores.

6. A method according to claim 5 wherein said information resides in at least one of a logical object, hardware and software.

7. A method according to any of the previous claims wherein said retrieving is performed as a background process.