GB2365154A

GB2365154A - Remote backup of a client computer system by attaching files to messages

Info

Publication number: GB2365154A
Application number: GB0017865A
Authority: GB
Inventors: James Garr Black; Raymond Carl Hughes; Barrie Lewis; Mark William Purnell
Original assignee: Individual
Current assignee: Individual
Priority date: 2000-07-20
Filing date: 2000-07-20
Publication date: 2002-02-13
Also published as: GB0017865D0

Abstract

A system and method for backing up a client computer system to a remote host comprises the steps of identifying files for backup, creating a message with the file to be backed up as an attachment and sending it to a remote host where it is stored. In use the client computer runs a local software agent which scans and identifies the files for backup. A message is created for each file and the file attached. Preferably the message has a header which is configured by the local agent to specify a subscriber ID, a file identifier and a backup location. The file identifier may also specify the file name and an originating path. The attachment may be compressed and/or encrypted. A backup service is configured to receive the files and uses a message processor to read the message header and stores the file according to the subscriber ID and file identifier. The message reader will decompress or decrypt an attachment where necessary. In a second embodiment multiple backup locations may be used either specified by the user or by the backup service forwarding the message to another location.

Description

<Desc/Clms Page number 1> TITLE OF THE INVENTION NETWORK BACKUP METHOD AND SYSTEM BACKGROUND OF THE INVENTION The invention relates to a system for and method of backing up data over a computer network, which may be private or public. An example of a private network is a local area network (LAN). An example of a public network is the Internet.

Disaster recovery is essential to most personal computer (PC) users; and other computer users. Traditionally, important data has been copied to some form of removable data carrier to create a backup, which may then be taken to another location for safe keeping. This backup process is normally done after the end of a business day, when users are not active. The removable data carrier may not be taken offsite for several hours after creation, meaning that in the event of a disaster affecting a computer system, recovery of a whole business day could be lost.

Typical backup application software for a PC or LAN will prepare a number of files for back up in a single compressed file, which is then transmitted ("streamed") to the backup data carrier.

One common solution is installation of completely mirrored systems, linked by dedicated communication links. This can produce highly reliable backup, but is usually extremely costly.

More recently, another solution has become common, namely backup services over the Internet. Some current Internet backup service providers are: Connected Online Backup 3.0 BackupMyStuff DataSaver Remote Backup System System Safe Safeguard @Backup EVault

Filetron Saf-T-Net I-drive Driveway Freeback Backup services of this kind are offered commercially, generally at low cost.

A typical prior art service will involve an end user installing backup software that automatically backs up files over the Internet at a convenient time. The software is able to recognise which files have been changed and which have not, using Delta technology or binary patching. In that way, only the changes are sent over the Internet, thus saving time and bandwidth. Normally, the files to be backed up are compressed into a single file known as a backup set, which is then copied to the remote backup server. Users can set up the software to execute the backup when they are about to log off for the day, or they can program the PC to transfer the backup set at any other time, for example at night, when the PC would dial in to the backup website.

Another kind of prior art backup service are browser based, in which the end user manually selects files to be backed up.

Most of these prior art services offer some kind of encryption, RAID storage, redundant servers and other tools.

SUMMARY OF THE INVENTION According to the invention messaging' technology is exploited by automatically backing up data from a PC or other computer as attachments to messages, the messages being automatically created and dispatched to a backup service provider for any files which have been flagged as containing data needing backup. The message is configured to allow the backup service provider to receive, process and store the backup data in a systematic way.

In one embodiment of the invention, the backup service provider is specified in the header of the message as the destination. In addition, the message header contains information sufficient to identify the sender, and to identify a file name associated with the data to be backed up, i.e. the data contained in the message attachment.

In use, files are continually scanned in the user's computer, with those files needing backup being flagged. Each flagged file is then prepared for back up, as an attachment to a specially prepared message that specifies in its header the relevant backup criteria for the backup service provider, as explained above.

In alternative embodiments, instead of using the message header, the information necessary for the backup service provider to systematically process and store the data to be backed up is contained in an attachment to the message, either as a further attachment separate from the data carrying attachment, or incorporated in the data carrying attachment.

The invention thus allows a computer user's local files to be backed up to an extent that provides almost complete mirroring, but without the need for expensive hardware, communications links, or central management. This is achieved by moving away from the concept of creating large backup sets for occasional dispatch to a remote backup location, and instead exploiting messaging technology to back up data in incremental amounts as individual files are created and modified.

A system for exploiting the above-described backup method requires only some form of asynchronous messaging technology, a local application agent running on the user's computer, and an active network connection. A common form of

asynchronous messaging technology is email. The backup method is designed to run on open or closed networks. The backup service provider may be an in-house facility, or an externally provided facility, as desired.

The service will typically benefit from the use of standard compression and encryption techniques, although either or both may be omitted in some embodiments, if not required.

BRIEF DESCRIPTION OF THE DRAWINGS For a better understanding of the invention and to show how the same may be carried into effect reference is now made by way of example to the accompanying drawings in which: Figure 1 shows backup of data according to a first embodiment of the invention; Figure 2 shows retrieval of backed up data according to a first embodiment of the invention; Figure 3 is a schematic overview of the first embodiment of the invention; Figure 4 is a schematic overview of a second embodiment of the invention; and Figure 5 is a diagram for a geographically based franchise organisation implementable with embodiments of the invention.

DETAILED DESCRIPTION First Embodiment: Technical Summary Figure 1 shows a network-based backup system and method according to a first embodiment of the invention.

A computer system in the form of a personal computer (PC) 10 is shown, being operated by a user 14 who is a subscriber to a back up service provided by a backup service provider 16. The PC 10 includes some form or forms of data carrier 12 such as a hard disk drive or whatever. The PC 10 will typically be running some kind of application software which involves file creation and/or manipulation. Files are thus continually generated and/or updated (Step P 1).

The PC 10 has a network connection 24 connecting the PC 10 to a network 20. One typical example would be that the connection 24 is to a private company network (e.g. LAN) with connection through to the Internet. Another typical example would be that the PC 10 is connected directly to the Internet. The form of the network is largely inconsequential to the operation of the invention.

Also connected to the network 20 is the backup service provider 16 comprising a file server including a mass storage facility 18. For example, the mass storage facility may be a highly reliable file server (HRFS) employing mirrored hardware.

Software in the form of a PC agent 22 runs at regular intervals on the PC 10 (Step P2). It will be understood that the agent will most usually be software, but may alternatively be embedded as firmware or hardware. Running the PC agent 22 scans to identify new or updated files (Step P3). Any such identified files are then flagged to indicate that they require backup.

Up to this point, the backup process has followed typical backup procedures. But, from this point, the process changes from the normal backup routine. Instead of the flagged files being prepared in a single backup set, each flagged file is prepared separately for backup. The backup procedure for one file is now described further.

The file is compressed (Step P4). This step is optional but desirable for obvious reasons. Compression may also include encryption, again for obvious reasons. A compression utility such as DynaZIP may be used.

A backup message is created in the form of an email message comprising a message header. The compressed backup file is attached to the message as an attachment thereto (Step PS).

The message header is configured to provide all the information necessary to achieve successful receipt, processing and storage of the file to be backed up by the backup service provider. This is achieved as follows, entirely by exploiting normal message properties. The destination field of the message header is set to the address of the backup service provider. Optionally, mirror sites of the backup service provider may also be specified. The sender field of the message header is set to provide identification of the subscriber, i.e. an identifier specific to the PC 10 or user 14. This allows the backup service provider (message recipient) to establish to which backup data set the data attached to the message should be added. If encryption has been used, the subscriber identifier also allows selection of an appropriate decryption key by the backup service provider 16. The subject field of the message header details the file name and path from which the data to be backed up originated. The message will also preferably carry time stamps of transmission and reception, and an acknowledgement of reception will be requested.

The message, with attached file, is then placed in a queue for transmission to the backup service provider by placing it in the messaging system's outbox (Step P6). As long as the network connection 24 is active, the message is sent to the backup service provider 16 over the network 20 (Step P7).

Although email messaging is used in the present embodiment, it will be understood that any other form of asynchronous messaging could be employed. The choice of messaging technology will depend largely on the type of applications run by the user 14 on the PC 10 or other computer. Further, it will be generally convenient to exploit messaging software that is already installed by the user for other reasons.

This whole backup process runs at regular intervals while the computer system 10 is active. Importantly, this results in the number of backup messages sent at any one time being small. Loading on the computer system 10 and network 20 will also be balanced. As a consequence of the continual asynchronous transmission of files to be backed up, performed as individual files are created and modified, the system 10 will be almost completely backed up at all times.

The backup process will also run as part of the shutdown sequence, so the subscriber will not need to consider allowing extra time at the end of the day to run a backup process. Lengthy backup processes, such as overnight backing up, is thus completely avoided.

The backup service provider is provided with a message processor for processing incoming backup messages.

Upon receipt of each message at the backup service provider, the message processor verifies that its sender is a subscriber to the backup service (Step P8).

A set of storage rules are then applied to the message header properties to determine how and where the backup message is stored by the backup service provider (Step P9). Storage may be to a disk or tape, or a combination, or to other types of media. The storage rules can be directly defined in terms of the rules available as standard in most email packages, such as Outlook, MS-Exchange, Lotus Notes. The rules are thus automatically applied to each incoming message, as the messages arrive.

The location of the backup message along with its header details is written to a database such as Oracle or DB2 (Step P10).

Logs of the status of all transactions are held on both the subscriber's and backup service provider's systems. Successful reception of a message is acknowledged (provided that this is requested in the message header) so that the history log of the subscriber can be updated (Step PI 1). Error status's are automatically notified by email to the subscriber and the backup service provider administrator, and message transmission is retried.

Figure 2 shows how backed up data can be retrieved by the subscriber following a loss of data. To recover data, the user 14 first logs onto the recovery service by executing a query on the backup service provider's database (Step R1), from which an `explorer' type file structure is created by retrieving the backup.. message location details from the database (Step R2) and presenting a corresponding list of files held on that users behalf by the backup service provider (Step R3). Files are then selected by the subscriber for restoration. This communication can all take place over the network 20 using normal messaging.

The database will then issue requests to retrieve the requested files, according to location, from the archive storage. These files will be sent to the subscriber over a FTP or similar transmission protocol (Step R4).

In the case of requests to retrieve large volumes of data, restored files may be dispatched on CD, DVD or other portable storage medium (Step R4').

Individual features of the system and method described above are now described in more detail.

Local Application Agent 22 The agent 22 regularly checks the personal computers files for new or updated files which need backing up. This may use the archive bit in the files attributes, or could use a more intelligent table for checking the files' status. The table method would enable notification of deletions, and eliminate the effect of any other application making spurious changes to the file attributes.

Data Collection If a file is found it is compressed and copied into the message queue. To reduce file size further only the changed portion of updated files can be sent. Delta technology and/or binary patching may be used to select changed parts of files only.

Internet Header and Transmission An Internet header record is added to the message. This includes the usual `to' `from' `date' `time' and `subject' fields. The subject field provides the file name and its path on the sending personal computer. The message can then be sent. If the transmission is broken, it is possible to start transmission from the point of interruption, to avoid retransmission time.

Network Connection 24 The network connection can, for example, be an open Internet connection, a dial-up, or restricted to a closed LAN.

Frequency The agent 22 is configured to run at regular intervals while the computer 10 is switched on. It will run during the start-up of the machine, and then regularly until system shutdown, when an attempt to run will be made again. The agent process can be designed to balance the frequency with which it runs, with processing load on the computer and/or traffic on the network.

Security If required, encryption and authentication properties may be added for security purposes.

Platform Independence

By using a standard format for the message headers and identification, the communications protocols are not an issue, and the process can be platform and vendor independent.

Open Files Applications which have files open for long periods of time may have plug-ins developed, or the applications developers may design embedded processes, to generate `do files', or `log files', containing a list of updates. These can be transferred at regular intervals, and used to apply to the original files. Many applications already generate these `logs', for example databases. Some already have the ability to interface with common application programming interfaces, such as email.

No Administration Due to the asynchronous nature of common messaging systems there is no direct link between the user's personal computer and the backup service provider. So the user does not need to stop and wait for acknowledgement that the backup process has completed.

Audit Trail and Logging All transactions are preferably logged both on the computer 10, and at the backup service provider 16. As with email messaging, the process will return an acknowledgement to the subscriber's system. This provides the necessary information for synchronisation, data integrity and an audit trail for inspection by the subscriber.

If unsuccessful attempts are made to send files, or if there is a longer than usual delay in receiving acknowledgements, alerts will be generated and sent to the subscriber and backup service provider, advising of the nature of the problem.

Storage The compressed backup file is received by the backup service provider to which it is addressed. At the backup service provider facility, the message header provides the information required for storage, such as rules which can be applied to an email inbox.

A disk buffer provides temporary storage for the first generation of files. After a set period of time, the files may be archived to tape. Storage rules are determined by the class of service requested by the subscriber.

Each backup service provider maintains a database of the locations of all files received, for retrieval by the subscriber.

Recovery In the event of a user needing to recover files, the user may logon to the recovery service, and, after authentication, will be presented with the current file structure according to the backup service provider's database.

The user can request recovery of files via an FTP or similar transmission protocol service, or, if a large volume of files are requested, these could be sent on CD or DVD, via express courier. Recovery rules may be determined by the class of service requested by the user.

Backup Service Provider Contingency The backup service provider should be able to demonstrate to subscribers full contingency for its facilities with its own backup site, and full hardware and network redundancy. This full contingency can be demonstrated by employing known backup systems with suitable levels of reliability, such as mirrored hardware and highly reliable file servers.

Summary of Complete Process Figure 3 shows a summary of the complete process of the first embodiment. In summary, an agent hosted on a computer system, such as a PC, is triggered intermittently at regular or irregular intervals to log files needing backup. The agent compresses each file needing backup, e.g. using ZIP technology. The ZIP file is encrypted and transferred over a network (Internet/intranet/dial-up) as an attachment to a message created using messaging technology. The ZIP file is received by the backup service provider and merged into existing files (or stored as a new file) after suitable decryption and decompression. The backup service provider may have disks mirrored at a second location to provide the required reliability. Offline backups can then be made conventionally by the service provider to robotic tape or other mass storage media. Logs are maintained at both the subscriber and service provider ends to maintain a full audit trail of all transactions.

Second Embodiment: Maximising the Advantages of Messaging Figure 4 shows a second embodiment of the invention. In the second embodiment, the user-end is unchanged, but the backup service provider is redesigned to further take advantage of the use of messaging.

In the second embodiment, there is no conventional high specification backup server. Instead, messaging is used to copy the data to be backed up to multiple locations, thereby automatically providing the required integrity of service through redundancy. Figure 4 shows how messages are sent from the user over the network 20, which may be the Internet as illustrated, to multiple servers 26, 28 etc. Each server may also use conventional offline backups to robotic tape or other storage media, this offline backup being illustrated in Figure 4 as also taking place over the network.

Because of the use of messaging, all the facilities of message queues and addressing may be used. This includes sending copies to as many alternative addresses as deemed appropriate. In Figure 4, the copying is sourced at the subscriber by specifying multiple destinations in the message header. Copying could be instigated by the backup service provider by applying a forwarding rule to incoming messages. If desired, both possibilities for copying could be used together. The multiple copying of the messages adds almost no complexity to the backup process, but provides two key benefits.

First, the backup service provider can provide a service of high integrity, without having to invest in either expensive mirrored hardware facilities or the associated high performance network connections or other communications links needed to achieve mirroring.

Second, consideration of geographic location is no longer an issue, since high- cost dedicated network connections between mirrored sites is not required. Almost any geographic location of backup server can be chosen without affecting the service quality. The backup sites may be in a different country or continent to each other and the subscriber sites. For example, the backup services may be sited in countries with favourable tax or information technology laws.

Since the second embodiment effectively removes any requirement for specialist hardware or communications links for the backup service, almost any computer may be used to host the backup data. For example, in an intranet embodiment of the invention with a company network, reciprocal arrangements can be made between buildings or sites of the same company or other organisation. A company can thus provide itself with its own highly reliable in-house backup service at minimal cost and management overhead.

Perhaps the simplest, lowest cost implementation of the second embodiment would be a closed group of two or more PC's with Internet access which provide backup services to each other by Internet messaging. Backup services could then be provided on a mutual basis between private users. A11 that would be needed would be for a private individual to purchase and install the agent software and agree to form a

mutual backup fraternity with one or more other private individuals in a similar position, perhaps friends or family. If data recovery was needed, this could be even performed in an informal manner without the systems described with reference to Figure 2. In this way, effective backup services could be provided at low cost and with almost no complication to a class of computer users who might not otherwise have access to backup services.

These benefits of the second embodiment are considered to be a significant enhancement to the backup service, over and above the benefits provided by a backup service according to the first embodiment.

Licensing and Franchising Structure A further commercial benefit of the messaging technology is the ability to license or franchise backup service technology according to the invention by software application or by geographic location. This can all controlled by the properties of the header record. The license or franchise agreement can be worded to contractually restrict the franchisee in terms of the properties of the message header that are permitted. A franchisee may for example be restricted to only having subscribers with certain web addresses, and/or to having locations with certain web addresses. Another example is an organisation with an intranet wishing to license the technology in order to provide its own backup services according to the invention. In that case, the licensee may be restricted to only using sender and destination addresses having a specific domain name or names owned by the licensee.

Figure 5 shows how a geographically based franchise organisation can be organised. These may be further subdivided into states within federal countries. For example, in the United States, this may be according to zip code, or service provider. Likewise, application developers may subdivide their structure according to class of product or service.

These additional licensing and franchising opportunities may be exploited in both the first and second embodiments of the invention, but are considered to be even

more useful for the second embodiment in which all the conventional technological constraints on geographical location of the backup service have been removed.

Claims

CLAIMS 1. A method of backing up data from a host computer over a network, comprising: (i) continually scanning for and flagging files in the host computer that require back up; and (ii) sending at least a part of each flagged file to a remote location for backup as an attachment to a message. 2. A method according to claim 1, wherein the message has a header and the header specifies sufficient information to allow systematic handling of the flagged file at the remote location. 3. A method according to claim 1 or 2, wherein a message is created for each flagged file, the message having the flagged file attached thereto and specifying: (i) a subscriber i.d.; (ii) a file identifier; and (iii) a back-up location. 4. A method according to claim 3, wherein the file identifier specifies a file name. 5. A method according to claim 3 or 4, wherein the file identifier additionally specifies an originating path. 6. A method according to claims 3, 4 or 5, wherein the subscriber i.d., file identifier and backup location are specified in the header to the message. 7. A method according to any one of the preceding claims, wherein the host computer maintains a log of the flagged files sent for backup.

<Desc/Clms Page number 18>

8. A method according to any one of the preceding claims, wherein the attachment is a compressed version of the flagged data file. 9. A method according to any one of the preceding claims, wherein the attachment is an encrypted version of the flagged data file. 10. A method according to any one of the preceding claims, wherein each message is sent to a plurality of remote locations for backup. 11. A method of providing a backup service for storing back-up data, comprising: receiving a stream of messages through a network connection; processing each message to identify the message sender, and the data to be backed up attached thereto; and storing the data to be backed up. 12. A method according to claim 11, wherein the processing of each message is performed by analysing a header to that message. 13. A method according to claim 11 or 12, wherein: the processing includes analysing each message to identify (i) a subscriber i.d., (ii) a file identifier, and (iii) an attachment containing data to be backed up; and the storing includes saving the data contained in the attachment according to the subscriber i.d. and file identifier. 14. A method according to claim 13, wherein the file identifier specifies a file name. 15. A method according to claim 13 or 14, wherein the file identifier additionally specifies an originating path.

<Desc/Clms Page number 19>

16. A method according to claim 13, 14 or 15, wherein, prior to the saving, the attachment is decrypted according to a key specific to the subscriber i.d. IT# A method according to any one of claims 13 to 16, wherein, prior to saving, the attachment is decompressed. 18. A method according to any one of claims 11 to 17, wherein the processing of each message comprises forwarding the message to another location for further backup. 19. A computer program product comprising agent software configured to: identify flagged files; and send at least a part of each flagged file to a remote location for backup as an attachment to a message. 20. A computer program product according to claim 19, wherein the agent software is configured to set up a header for each message such that the header specifies sufficient information to allow systematic handling of the flagged file at the remote location. 21. A computer program product according to claim 20, wherein the agent software is configured to set up the header with (i) a subscriber i.d.; (ii) a file identifier; and (iii) a back-up location. 22. A host computer having an agent for backing up data from the host computer over a network, the host computer being operable to continually scan for and flag files that require back up, wherein the agent is configured to send at least a part of each flagged file to a remote location for backup as an attachment to a message.

<Desc/Clms Page number 20>

23. The host computer of claim 22, wherein the agent is configured to set up a header for each message such that the header specifies sufficient information to allow systematic handling of the flagged file at the remote location. 24. The host computer of claim 23, wherein the agent is configured to set up the header with (i) a subscriber i.d.; (ii) a file identifier; and (iii) a back-up location. 25. A backup service computer for storing backup data, comprising: a network connection for receiving a stream of messages through a network connection; and a message processor operable to process each message to identify the message sender, to identify the data to be backed up attached to the message; and to store the data to be backed up. 26. The backup service computer of claim 25, wherein the message processor is operable to analyse a header of each message. 27. The backup service computer of claim 25 or 26, wherein the message processor is operable to analyse each message to identify (i) a subscriber i.d., (ii) a file identifier, and (iii) an attachment containing data to be backed up; and to save the data contained in the attachment according to the subscriber i.d. and file identifier. 28. The backup service computer of claim 27, wherein the message processor is operable to decrypt each message according to a key specific to the subscriber i.d. identified in that message. 29. The backup service computer of claim 25, wherein the message processor is operable to forward each message to another location for further backup.