Patent Publication Number: US-6038379-A

Title: Data backup and restore system for a computer network having generic remote file system agents for providing backup and restore operations

Description:
This application is a continuation of application Ser. No. 08/150,488, filed on Nov. 9, 1993, now abandoned. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates to a system for protecting data through backup and restore operations, and more particularly to backup and restore software for protecting data which is processed on a computer network 
     2. Description of the Related Art 
     In order to ensure that original data stored on a medium such as a disk is not lost or damaged, a copy of that data is stored on another medium. Should the original data be lost or damaged, then the copy may be accessed to reproduce the original data. This process of copying and reproducing is generally known as backup and restore. Typically, original data are stored on a hard or floppy disk of a computer disk drive and are backed up to and restored from tape media of a tape drive. 
     Backup and restore of the data are simple in a system that has a single standalone computer, having a given operating system and one or more disk drives, that interfaces with a tape drive system. A relatively simple backup and restore program can be used that interfaces with the computer operating system to backup data including files and directories stored on a hard disk to the tape drive and to restore such data from the tape drive onto the hard disk. 
     Computer networks have evolved and this has placed greater demands on backup and restore systems. A computer network may include a number of computers each with its own hard and/or floppy disk drive, all of which are networked together on a common bus. For example, the computers on the network may include one or more workstations and one or more file servers, each with its own hard disk drive. The file server may also have a tape drive upon which to backup and restore its own data as well as data stored on the disk drives of the workstations on the network. Backup and restore operations are still relatively simple for a computer network in which each workstation is running the same operating system or environment, such as that known as DOS. However, computer networks exist in which workstations and file servers on the network may be running disparate operating systems. For example, a computer network may have, or may be expanded to have, workstations running different operating systems including those known as DOS, Windows, OS/2, Macintosh, and UNIX. The computer network also may have, or may be expanded to have, file servers running networking operating systems software, including those known as NetWare, Lotus Notes, and LAN Manager. 
     In one particular example, a computer network having workstations and a file server running disparate operating systems may be supported by NetWare, which is an operating system made and sold by Novell, Inc. of Provo, Utah. NetWare is designed to manage the programs and data among several computers on a network, unlike, for example, DOS, which is an operating system for standalone personal computers. Novell also provides, for example, SBACKUP software, which is a NetWare Loadable Module (NLM) that can be loaded onto a NetWare file server to backup data to and restore data from a tape storage device attached to the NetWare server. SBACKUP has limited capabilities; for example, it is designed to backup and restore only NetWare server data and workstations running DOS, OS/2, and Windows. 
     The difficulty in providing backup and restore operations to protect data on a computer network obviously increases as more and more disparate operating systems are added to the network via the computers on which they run. 
     In general, prior backup and restore systems for computer networks are limited to the number of different types of operating systems that can be supported. This places expansion limitations on the network in terms of adding computers running additional types of operating systems. Also, these backup and restore systems do not have the capability of interchanging data between different operating systems. Furthermore, bottlenecks occur and productivity is limited with prior backup and restore operations since multiple users cannot simultaneously request these operations. 
     SUMMARY OF THE INVENTION 
     The present invention provides a backup and restore system for use on a computer network having computers running disparate operating systems. Backup and restore software has modules including a backup engine containing, among other components, a generic remote file system (GRFS file system) and GRFS agents, being loadable on a computer network having a plurality of computers including, for example, at least one file server and at least one workstation. The GRFS file system may run on one computer, e.g., the file server of the network, and each GRFS agent may run on another computer, e.g., a workstation, on the network. The GRFS file system running on the one computer, i.e., the file server in this example, is allowed to access a file system of the other computer via the GRFS agent on that other computer to backup and restore data on that computer. 
     The GRFS file system and each GRFS agent interface with one another over the computer network by a set of defined messages. This messaging system is based on a command/response paradigm, such that the GRFS file system will send a given GRFS command message to a given GRFS agent and wait for a GRFS response message from the GRFS agent in order to backup or restore data. These messages are defined structurally in a manner that enables (1) backup and restore of data for a wide variety of disparate operating systems, (2) data to be interchanged between the different operating systems, and (3) simultaneous request for backup or restore by independent multiple users of the computer network. 
     Consequently, with the present invention, a computer network can be expanded to support computers running the major operating systems including DOS, Windows, OS/2, UNIX, and Macintosh. Also, data can be backed up from one computer, e.g., a Macintosh workstation, and restored to another, e.g., a DOS workstation, and multiple users working on the various computers in the network can simultaneously request backup and restore operations. 
    
    
     BRIEF DESCRIPTION OF THE FIGURES 
     FIG. 1 is a block diagram of a prior art computer network. 
     FIG. 2 illustrates backup and restore software of the present invention. 
     FIG. 3 is a block diagram of the computer network of FIG. 1, but having installed the backup and restore software of the present invention. 
     FIG. 4 is a simplified message command/response sequence diagram used to explain the backup of a given amount of data. 
     FIG. 5 is a simplified message command/response sequence diagram used to explain the restoration of backed up data. 
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     FIG. 1 illustrates one example of a computer network 10 which stores, manipulates, and otherwise processes data. The network 10 has a number of computers 12 which can communicate with one another over a network bus 14. In the example of FIG. 1, the computers 12 include a file server FS and a plurality of workstations WS 1 , WS 2 , WS 3 , WS 4 , . . . WS n . Each of the workstations WS 1  -WS n  has a display monitor M and the workstations WS 1  -WS n  include hard disk drives HDD 1  -HDD n . The file server FS has its own large file server disk drive FSDD and a tape drive TD upon which to backup to and restore from data on the network 10. 
     Every workstation WS 1  -WS n  may be running the same operating system OS, or each workstation WS 1  through WS n  may be running a disparate operating system, or there may be disparate groups of workstations with each group running the same operating system. For example, workstation WS 1  and workstation WS 2  may both be running the operating system known as DOS, workstation WS 3  may be running the operating system known as OS/2, workstation WS 4  may be running the operating system known as UNIX, workstation WS n  may be running the operating system known as Macintosh, and other workstations, not shown, or which may be added to the network 10, may run the operating system known as Windows. Furthermore, the computers 12 in the network 10 may be utilizing user interfaces such as those known as the DOS user interface, Windows graphical user interface, and a server-based NLM (NetWare Loadable Module) interface. 
     The computer network 10 may be, for example, running the operating system software known as NetWare 3.X or 4.X which is produced by Novell, Inc., of Provo, Utah. NetWare is designed to manage programs and data among the several computers 12 of the network 10. FIG. 1 also illustrates a portion of the NetWare software including individual network protocols SPX, TCP, and ADSP. As shown, these three protocols are associated with the file server FS, while the respective protocols are associated with each respective type of workstation. For example, NetWare supports the protocol SPX for DOS, Windows, and OS/2 workstations, and the protocol TCP for UNIX workstations. Also shown is a network resource layer (NRL) which is an interface module which provides for accessing network messages and advertising resources available on the network 10. 
     The general operation of a computer network 10 including one that is running NetWare is well-known. As one brief example of the operation, a user who is using a workstation WS 1  -WS n  may want to access data that is currently stored on the disk drive of the file server FS. Upon request by the user of, for example, DOS workstation WS 1 , the file server FS will set up a connection and protocol via the network resource layer NRL 30, the network protocol SPX 21, and the network protocol SPX 21 and network resource layer NRL 31 of the workstation WS 1 . Via this connection and protocol, data can then be transferred over the network 14 between the file server disk drive FSDD and the workstation WS 1  disk drive HDD 1  for processing by that user. 
     FIG. 2 illustrates a software package 16 of the present invention. In the specific embodiment, the package 16 is a NetWare Loadable Module (NLM), which, therefore, can be loaded onto NetWare. The package 16 includes multiple user interfaces 18, including a Windows graphical user interface, a DOS interface, and a server-based NLM interface. The package 16 also include GRFS agents 20 including, respectively, DOS, OS/2, UNIX, Macintosh, and Windows agents. Each agent 20 is a respective program designed to run on a computer 12 having the corresponding operating system in order to access the file system of that given computer. Thus, for example, the DOS GRFS agent 20 will run on a DOS workstation WS 1 , the OS/2 GRFS agent will run on the OS/2 workstation WS 2 , etc. The package 16 also has a backup engine 22 running on the file server FS and includes a tape controller device driver and tape positioner to control the mechanical operation of the tape drive TD, a common file system, and at least one device specific file system. The latter is a GRFS file system which interfaces with GRFS agents 20 via messages described in more detail below. 
     FIG. 3 illustrates the network 10, but modified to include the software 16. As shown, the backup engine 22 is installed at the file server FS, while the DOS, OS/2, UNIX, and Macintosh GRFS agents are installed on the respective workstations WS 1  -WS 2 , WS 3 , WS 4 , and WS n . In this example, the computer network 10 does not have a computer 12 running a Windows operating system. Should the network 10 be expanded to include a Windows workstation, then the Windows GRFS agent of the software 16 would be installed at that workstation. While not specifically illustrated, a workstation user also can opt to have installed one of the user interfaces 18 for tape backup and restore purposes, that is the same as that already on a workstation for other purposes. 
     As indicated above, a GRFS agent is a program which runs on a network computer such as the given workstation WS, and which allows the GRFS file system running on another computer, such as the file server FS, to access the file system within the given GRFS agent&#39;s computer. This access is accomplished by use of an interface between the GRFS file system and the given GRFS agent over the network bus 14. Specifically, the interface is defined by a set of GRFS messages which are documented in detail as described more fully below. The GRFS messages include GRFS command messages that are produced by the GRFS file system and GRFS response messages produced by the given GRFS agent. 
     The GRFS messages are based upon a simple command/response paradigm. For backup or restore, the GRFS file system of the file server FS sends a command message over bus 14 to a given GRFS agent of the workstation WS and then waits for that agent to respond over bus 14 with a GRFS response message. A GRFS agent does not send a GRFS response message without first receiving the corresponding GRFS command message from the GRFS file system. 
     There are several characteristics of the GRFS messages that allow independent multiple users on the network 10 to simultaneously request backup and restore of data, allow for backup and restore of almost all types of disparate workstation and file server operating systems, and allow data to be backed up from a GRFS agent running on one operating system and be restored to a GRFS agent running on a different operating system. However, before these message characteristics are further described, an overview of the message structures will first be given. Reference should be made below under the heading &#34;Specific Description of Command/Response Messages&#34; for a detailed description of the message structures. 
     All GRFS messages (command and response) are structured to begin with the same four fields. These four fields of the common structure are as follows: 
     msg --  type: This UINT8 field contains the command or status id number. 
     reserved: This UINT8 field is not currently used. 
     retcode: This UINT16 field is used by GRFS status messages to hold the return code of the GRFS command. 
     request --  id: This UINT32 field contains a value which is generated by the GRFS file system for GRFS command messages and must be returned unchanged in the corresponding GRFS response message. 
     In the detailed description of the specific GRFS messages below under the heading &#34;Specific Description of Command/Response Messages&#34;, the number of parameters associated with a given GRFS agent is assumed not to include the above GRFS common message header. The messages use two major structures to define GRFS objects. These two major GRFS object types are a drive list element (DLE) objects, which are logical devices, and file system objects, which are files and directories. The GRFS messages use DLE structures to reference drive list element objects and DBLK (descriptor block) structures to reference file system objects. 
     A DLE is a structure that contains information about individual data storage devices which can be accessed for backup and restore. The DLE structure contains the following types of information: logical device name, access password, file system delimiter, etc. 
     A DLE structure also supports a hierarchical structure. A DLE can be a &#34;parent&#34; DLE and can have &#34;children&#34; DLEs associated with it. For example, this is the case for a Novell server file system. For a Novell server, a DLE structure is created which is associated with the server and then DLEs for each volume on the server are created. The same situation can occur with a GRFS agent should that agent advertise or publish on the network 10 the workstation name as a DLE and then use children DLEs to advertise individual areas which can be accessed as logical units. 
     Security considerations such as passwords and user names may be enforced at each DLE level within a hierarchical structure. This means that a single GRFS agent can advertise on the network 10 a workstation name with multiple children DLEs and each child DLE would have a unique password. 
     While DLEs contain information about individual storage devices, a DBLK structure contains information about specific file system objects, which are the things in the file systems that are actually backed up and restored. As already mentioned, these objects include files and directories. The contents of a DBLK structure include items such as: the object&#39;s type, the object&#39;s name, and the object&#39;s attributes. A DBLK structure can also contain operating software specific information. 
     There are several other aspects of a DLE structure and a DBLK structure to discuss. A DLE does not have both children DLEs and file system objects associated with it. In other words, if a GRFS agent advertised itself over the network 10 as a &#34;workstation&#34;, as will be described further below, and had a child DLE for each disk drive at the workstation, then the workstation DLE will have no file system objects associated with it. This is because the backup application descends to the bottom of DLE trees before attempting to find any objects. Most GRFS agents will support multiple levels of DLEs, but if the file system of the agent platform is very flat, i.e., there are no sub-devices and all objects can be enumerated with a single handle, then a single level DLE structure will suffice. 
     A DBLK structure has a common structure area followed immediately by the variable length DBLK data area. The DBLKs are limited to a maximum of 1,024 bytes in the specific embodiment, which means that the sum of the space required for the DBLK common structure and the data area is at most 1,024 bytes. Furthermore, there are several fields within the DBLK structure, which are actually pointers to information within the DBLK data area. These pointers are generated as offsets from the beginning of the DBLK structure. For example, if the DBLK common area is 80 bytes long and the first item within the data area is the object&#39;s name, then the object name field would be set to 80 in order to point to the first byte following the DBLK common structure. The individual fields within the common DBLK structure that are manipulated by the GRFS agent programs are described in detail below under the heading &#34;DBLK Fields&#34;. 
     In order to implement a backup and restore function for a given computer 12, that computer 12 should advertise its capability for this purpose. Not every computer 12 in the network 10 is necessarily running a GRFS agent program so as to be able to have its data backed up. Consequently, the GRFS agent programs will &#34;advertise&#34; their capability as a GRFS agent over the network 10. This may be accomplished using the NRL resource advertisement function. The GRFS agent resource advertisement publishes the logical name of the particular agent&#39;s root DLE, as well as various flags which are used by the GRFS file system to control access to the GRFS agent. The format of the GRFS agent advertisement structure is as follows: 
     
         ______________________________________                                    
struct grfs.sub.-- ws.sub.-- adver.sub.-- struct                          
CHAR major.sub.-- ver;                                                    
CHAR minor.sub.-- ver;                                                    
CHAR agent.sub.-- type;                                                   
CHAR flags;                                                               
CHAR name [MAX.sub.-- WORKSTATION.sub.-- NAME.sub.-- LEN];                
}                                                                         
______________________________________                                    
 
    
     GRFS agents use character representations of the values in the version and flags fields. For example, the major.minor version of a particular GRFS agent might be 1.3, so that agent would advertise the version numbers as &#34;1&#34; and &#34;3&#34;, respectively. 
     The GRFS major version number is used to control which GRFS agents can be accessed by the GRFS file system. The GRFS major version number of the GRFS file system and the GRFS agent must match exactly or no information of the existence of that GRFS agent will be given. The GRFS minor version number may be used for informational purposes only. 
     The agent --  type field is used to define the type of GRFS agent. For example, the following values may be defined for this field: 
     
         ______________________________________                                    
        DOS             1                                                 
        OS2             2                                                 
        MACINTOSH       3                                                 
        UNIX            4                                                 
______________________________________                                    
 
    
     The GRFS flags field is a bit-mapped value with the following flags currently defined: 
     GRFS --  WS --  PASSWORD --  REQ 0x01 
     GRFS --  WS --  USER --  REQ 0x02 
     Combining all the GRFS resource advertisement fields leads to the following examples of GRFS agent advertisements: 
     
         ______________________________________                                    
NRL Resource    Decoded As                                                
______________________________________                                    
&#34;1211RATBOY.sub.-- 486&#34;                                                   
                major version = 1                                         
                minor version = 2                                         
                DOS agent                                                 
                no user name required                                     
                password required                                         
                DLE name = &#34;RATBOY.sub.-- 486&#34;                            
&#34;1020SLEDGEHAMMER&#34;                                                        
                major version = 1                                         
                minor version = 2                                         
                OS/2 agent                                                
                no user name required                                     
                password required                                         
                DLE name = &#34;SLEDGEHAMMER&#34;                                 
&#34;0043ONE.sub.-- WOLF&#34;                                                     
                major version = 1                                         
                minor version = 2                                         
                Unix agent                                                
                user name required                                        
                password required                                         
                DLE name = &#34;ONE.sub.-- WOLF&#34;                              
______________________________________                                    
 
    
     FIG. 4 illustrates a sequence of GRFS command and response messages in simplified form to backup data on the tape drive TD of the file server FS. This FIG. 4 gives the example of backing up a 5000 byte file named COMMAND.COM which is stored on a &#34;DRIVEC&#34; of a given workstation named &#34;DougCompaq&#34;. It is assumed that the given workstation WS has advertised over the network 10 sufficient information so that the GRFS file system can create the first command message shown in FIG. 4 as ATTACH --  DLE(. 
     To begin the 5000 byte backup, the workstation user will, via a given user interface 18, cause a display on a monitor M of devices and subdevices. The user will then select a given subdevice (e.g., DRIVEC in the example of FIG. 4), resulting in the user interface displaying on monitor M names of various files and directories. The user will then select the file name to be backed up (COMMAND.COM in the example) resulting in the submission of a tape backup job for the file server FS in the network 10. 
     Next, the sequence of GRFS file system command messages and GRFS agent response messages will occur as shown in order in the simplified FIG. 4. The sequence, as illustrated, commences with the GRFS command message ATTACH --  DLE (naming &#34;DougCompaq&#34; (dle.id=01) and completes with the final GRFS agent response message DETACH --  DLE --  STAT() by which DougCompaq (dle.id=01) is detached. Thus, the file COMMAND.COM will be read from DRIVEC and written onto the tape drive TD of the file server FS for network 10. 
     FIG. 5 shows a sequence of GRFS command/response messages to restore information backed up on the file server FS of the network 10. In this example, it is assumed that a 5000 byte file named CONFIG.SYS has been backed up from a given workstation and is to be restored to DRIVEC of the workstation DougCompaq. After the workstation user has selected the file CONFIG.SYS using the user interface to select the file CONFIG.SYS for restore, the sequence of GRFS command/response messages will proceed as shown in FIG. 5. The sequence begins with the GRFS command message ATTACH --  DLE (and completes with the GRFS response message DETACH --  DLE --  STAT(). The file CONFIG.SYS will be read from the tape drive TD and restored onto DRIVEC. 
     As mentioned previously, the command/response messages are structured such that objects such as files and directories may be backed up from a GRFS agent running one operating system, e.g., OS/2, and restored to a GRFS agent running another operating system, e.g., DOS. This is accomplished by the messages containing a structure GRFS --  STREAM --  INFO. This structure has the following definition: 
     
         ______________________________________                                    
        struct GRFS.sub.-- STREAM.sub.-- INFO {                           
        UNET32   id;                                                      
        UNET16   fs.sub.-- attrib;                                        
        UNET16   tf.sub.-- attrib;                                        
        UNET64   size;                                                    
        }                                                                 
______________________________________                                    
 
    
     When the backup application is reading an object, the GRFS --  READ --  OBJ --  STAT response message contains a GRFS --  STREAM --  INFO structure. The GRFS agent program must set the id field of the first GRFS --  READ --  OBJ --  STAT response message of each individual data stream to the appropriated value for the agent&#39;s particular operating system. Succeeding GRFS --  READ --  OBJ --  STAT messages for the stream must have the stream header id field set to 0 (STREAM --  INVALID). The data in the stream info structure is used by the backup application&#39;s tape format module and is written to the backup media of tape device TD. A well-known Microsoft Tape Format Version 1.0 Specification describes stream header structures and also contains a list of pre-defined stream header id values. The size field must be set to the number of bytes contained in the succeeding data stream and should only be set in the first stream header structure for a particular data stream, i.e., if the stream header id value is 0, then the size field does not need to be set. 
     An example is presented below of what a Macintosh GRFS agent would return in the GRFS --  READ --  OBJ --  STAT messages when a file with a 2000 byte resource fork and a 4000 byte data fork is being backed up. This example also assumes that a GRFS data buffer limit is 1000 bytes. 
     
         ______________________________________                                    
strm.sub.-- header.id=STRM.sub.-- MAC.sub.-- RESOURCE                     
                       (returns 1st 1000                                  
                       bytes of resource                                  
                       fork)                                              
strm.sub.-- header.size=2000                                              
                       (returns last 1000                                 
strm.sub.-- header.id=STREAM.sub.-- INVALID                               
                       bytes of resource                                  
                       fork)                                              
strm.sub.-- header.size=0                                                 
                       (returns 1st 1000                                  
strm.sub.-- header.id=STRM.sub.-- NORMAL.sub.-- DATA                      
                       bytes of data fork)                                
strm.sub.-- header.size=2000                                              
                       (returns next 1000                                 
strm.sub.-- header.id=STREAM.sub.-- INVALID                               
                       bytes of data fork)                                
strm.sub.-- header.size=0                                                 
                       (returns next 1000                                 
strm.sub.-- header.id=STREAM.sub.-- INVALID                               
                       bytes of data fork)                                
strm.sub.-- header.size=0                                                 
                       (returns last 1000                                 
strm.sub.-- header.id=STREAM.sub.-- INVALID                               
                       bytes of data fork)                                
strm.sub.-- header.size=0                                                 
______________________________________                                    
 
    
     When the backup application is restoring an object, the GRFS commands (GRFS --  WRITE --  OBJ, GRFS --  VERIFY --  OBJ) will also contain a GRFS --  STREAM --  INFO structure. The GRFS agent must examine the stream header id value to determine whether the data stream type is supported on the agent&#39;s operating system platform. If the data stream type is not supported the GRFS agent should set the response message retcode to FS --  DONT --  WANT --  STREAM. This will cause the backup application to skip to the next data stream or the next object if at the last data stream for a particular object. For instance, if an object was backed up from an OS/2 agent which supports a normal data stream, an extended attribute (EA) data stream, and an access control list (ACL) data stream, then if the object is restored to a DOS agent, the DOS agent will return FS --  DONT --  WANT --  STREAM when it receives GRFS --  WRITE --  OBJ commands with stream header id values that indicate either EA or ACL data streams are being restored since this data is not supported by DOS. The DOS agent will accept the normal data stream which it does support. Thus, this functionality allows objects to be backed up from an agent running on one operating system and restored to an agent running on another operating system. 
     As also mentioned above, the message structure is defined as well, such that backup and restore can be supported with respect to most operating systems, including the current major operating systems which are DOS, OS/2, Macintosh, Windows, and UNIX. Each operating system will have its own data structures aligned differently from one another. For example, one operating system may have a 1-byte alignment where a data byte may be placed anywhere, whereas another operating system may have a 2-byte alignment where a data byte may be placed in either an even or odd byte location. Other operating systems, for example, may have what is known as a 4-byte alignment. The GRFS messages are defined with a &#34;least common denominator&#34; alignment that would apply to the above-noted major operating systems. Thus, for example, a given network 10 which may include workstations running only DOS, OS/2, and Macintosh, may be expanded to include a workstations running UNIX and/or Windows. In other words, the present invention supports a scalable network for backup and restore purposes from a small or departmental local area network (LAN) to a large or enterprise wide area network (WAN). 
     Furthermore, the message structure enables multiple users working at multiple computers 12 on the network 10 to request simultaneously backup and restore of objects. This structure enables the GRFS file system to create a unique request id for every GRFS command message. Consequently, the GRFS file system can communicate simultaneously with multiple GRFS agents and, therefore, multiple users of the network 10 who at the same time want to have backup and/or restore operations performed. The present invention will manage these requests such that they are placed in a job queue in the file server FS, thereby allowing each user to operate independently from any other user on the network 10 and without waiting access to the backup and restore system. 
     While each user can independently manage his/her own data on a given workstation, backup and restore of data on the entire network 10 can be centrally managed at a single location by, for example, a network administrator, from a given workstation or file server, or a system console. 
     The remaining portion of this specification describes in much more detail the structure of the command/response messages, followed by a detailed description of the individual fields of the GRFS common DBLK structure which may be manipulated by GRFS agent programs.