WO2000019337A1

WO2000019337A1 - Backing up microsoft clustered database

Info

Publication number: WO2000019337A1
Application number: PCT/US1998/020355
Authority: WO
Inventors: Michael Ott
Original assignee: Harris Corporation
Priority date: 1998-09-30
Filing date: 1998-09-30
Publication date: 2000-04-06
Also published as: AU9511598A

Abstract

Backup of the virtual SQL server (32) in a cluster configuration is performed using Microsoft SQL Server 6.5 Enterprise Edition's backup utility and is targeted to another server (34) through the network (20). Once the backup is completed to the network shared disk (36) on the non-clustered server (34) it is then backed up to tape (28) from the non-clustered server (34) using NT Backup that comes with Microsoft NT Server 4.0.

Description

BACKING UP MICROSOFT CLUSTERED DATABASE

BACKGROUND OF THE INVENTION A cluster group is a set of services, disks, IP addresses, network names, and files shares that depend on each other for proper operation. Figure 1 shows a prior art database cluster 32 in which two servers 10 are connected to a. shared database 24 (e.g., RAID array external disk drive assembly) through SCSI connections 26. A special cluster server disk driver allows only one server to be in control of the shared database 24 at a time. The two servers 22 form a virtual server with each server monitoring the activity of the other server. If any failures are detected within one of the servers, the other server will take control of the database as well as any services or file shares assigned to the cluster group .

Backing up the shared databases in such a cluster system is difficult to accomplish due to restore and backup synchronization problems. To back up a database to a tape drive requires associating the tape drive with a particular server. In the cluster configuration of Figure 1, however, it is difficult to determine which server is in control of the shared database 24 at any particular point in time. Setting a tape device up on one or both cluster nodes makes managing the database tape backup like trying to hit a moving target. The disadvantage with this scheme is that the backup images exist on two different tapes.

For example, Figure 2 illustrates a prior art cluster system in which both servers have tape backups. If server #1 is "down" /inactive between times Tl and T2 , server #2 will continue to back up data during this time period. Then should server #2 go "down" /become inactive between times T2 and T3 , server #1 will continue to back up the system. The disadvantage of such a system is that although all the information updates between times Tl and T4 are maintained by the system, the information is spread across the tape drives and must be reconciled for practical use.

Accordingly, it is an object of the present invention to provide a novel system and method for backing up a database cluster to tape without reconciling data spread across tape drives .

It is yet another object of the present invention to provide a novel method and system which provides multiple levels of redundancy for a database cluster.

These and many other objects and advantages of the present invention will be readily apparent to one skilled in the art to which the invention pertains from a perusal of the claims, the appended drawings, and the following detailed description of the preferred embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a functional block diagram illustrating a prior art database cluster system.

Figure 2 is a functional block diagram illustrating tape backup in a prior art database cluster system. Figure 3 is a functional block diagram showing the basic organization of the enhanced services system of the present invention in the embodiment of a prepaid telephone system.

Figure 4 is a functional block diagram of an embodiment of the present invention showing the voice response unit (VRU) embedded within the switching platform.

Figure 5 is a functional block diagram showing the basic . organization of the database cluster backup environment for one embodiment of the present invention.

Figure 6 is a table showing a schedule for backing up the clustered database for one embodiment of the present invention.

DESCRIPTION OF PREFERRED EMBODIMENTS Figure 3, illustrating an enhanced services platform in the embodiment of a prepaid telephone system, shows a suitable conventional telephone switch 10 such as the Harris Corporation 20/20 switch in a conventional public switched telephone network (PSTN) connected to large numbers of subscriber telephones such as the caller telephones 12 and the called party telephones 14. Also connected to the switch 10 may be a bank of voice response units (VRUs) 15 on which the prepaid call processing application 18 resides.

Alternatively as shown in Figure 4, the VRUs 15 may be embedded within the architecture of an integrated network server (IN Server) 16 which is physically mounted on the back plane of the telephone switch 10. The embedding of the VRU in the switch platform effects seamless transfer of information and may be accomplished by means of an adaptor card with the elimination of the Tl and El circuits.

The management of a prepaid system is generally under the control of a call processing application resident within the VRU. The call processing application, in association with peripheral equipment, determines the action to be taken (e.g., determining the correctness of a PIN entry, the prompting of users for destination numbers or desired services, outdialing to a requested telephone number, etc.) during the processing of a call request.

Information obtained and used during the call processing is maintained by the database cluster 20. Figure 5 illustrates the database cluster 20 for one embodiment of the present invention. In this embodiment, the prepaid system uses a cluster server 22 such as the MS Cluster Server or DEC Cluster Server to handle database redundancy. MS SQL Server 6.5 is used to back up the shared database 24 to a network file share location 36 on another server ("backup server") 34 having an installed tape drive 28. The network file share 36 is then backed up to tape using NT Backup or similar software.

The backing up of the shared database 24 and that of the network file share 36 may be coordinated by schedule as illustrated in Figure 6. The schedule of Figure 6 incorporates five types of backup: full database backup of the shared database to the network file share with and without initialization of the file share (i.e., FullDB With Init and FullDB No Init respectively) ; transaction log backup to the network file share of the incremental changes to the shared database, with and without initialization of the file share (i.e., TransDB With Init and TransDB No Init respectively); and, the backup of the network file share to the tape drive 28 (NT Backup) . Incremental changes to the shared database 24 are backed up to the network file share 36 every three hours (without initializing the network file share) . On Wednesdays and Sundays the network file share is backed up to tape. Accordingly, on Thursdays and Mondays the network file share is initialized and a full backup of the shared database is performed.

The database redundancy inherent within the present system is extremely reliable due to the three levels of backup: RAID-5 technology in the main database 24, scheduled disk backup on the offline server 34, and the scheduled tape backup 28. The redundancy prevents the integrity of the data maintained from being disjointed by the cluster itself (i.e., not subject to failure or fallback conditions) .

Further advantages stem from the use of MS SQL Server 6.5 Enterprise Edition which has components specifically designed to work with a cluster server, ensuring high availability for the shared database at a hardware and software level . After installing MS SQL Server 6.5 on a cluster, control of the database can be moved from one server to the other with little effort providing the capability to do maintenance on either server without down time to the users. MS SQL Server 6.5 also provides an automatic emergency fall over mechanism that is transparent to the users. Finally, by removing the backup task to the backup server 34, the present invention does not overtax the main/booking servers 22 with backup functions.

While preferred embodiments of the present invention have been described, it is to be understood that the embodiments described are illustrative only and the scope of the invention is to be defined solely by the appended claims when accorded a full range of equivalence, many variations and modifications naturally occurring to those of skill in the art from a perusal hereof .

Claims

WHAT IS CLAIMED IS:

1. A method of backing up a database cluster comprising:

(a) providing backup server having database and tape drive ;

(b) backing up cluster server to backup server; and,

(c) backing up backup server database to tape drive;

2. A database cluster having multiple servers operatively. connected to a shared database the improvement wherein a tape drive is operatively connected to the database cluster for backing up information maintained by the shared database.

3. The database cluster of Claim 2 wherein the tape drive is connected to the shared database via a backup server.

4. The database cluster of Claim 3 wherein the shared database is backed up to a network file share on the backup server and then the network file share is backed up to the tape drive .

5. A method of providing a tape drive backup for a database cluster comprising:

(a) providing a backup server having a database and a tape drive;

(b) periodically backing up a shared database of the database cluster to the database of the backup server; and,

(c) periodically backing up the database of the backup server to the tape drive .

6. The method of Claim 5 wherein the backing up of the shared database and the backing up of the backup server database are coordinated to avoid overlapping time periods .

7. A method of providing redundancy in a database cluster environment comprising:

(a) providing a backup server having a network file share and tape drive backup;

(b) backing up a shared database of the database cluster to the network file share; and,

(d) backing up the network file share to the tape drive. .

8. In a prepaid telephone system including a telephone switch and a voice response unit having a prepaid call processing application resident thereon, and a remote data base, where the remote data base includes a database cluster having a plurality of cluster servers for managing accesses to a shared database necessitated by the prepaid application, the method of backing up the data in the shared database comprising the steps of:

(a) providing database management software, resident on the cluster servers, having a backup utility for facilitating the backup of the shared database;

(b) providing a backup server, separate from and operably connected to the database cluster, having a network file share, a tape drive backup, and a software backup utility for backing up the network file share to the tape drive;

(c) using the database management server to back up the shared database to the network file share of the backup server; and, (d) using the software backup utility to backup the network file share to the tape drive.