Browse Prior Art Database

Incremental backup to provide fast media recovery for a message queueing system

IP.com Disclosure Number: IPCOM000015838D
Original Publication Date: 2002-May-16
Included in the Prior Art Database: 2003-Jun-21
Document File: 3 page(s) / 52K

Publishing Venue

IBM

Abstract

Disclosed is a system that allows fast media recovery for a message queueing system by using incremental backup of the messages within the queing system. Incremental backups are common in disk backup systems backing up all files that have changed since the last backup time however they tend to be general purpose programs that backup and restore entire files without knowledge of the internal database structure. Therefore to restore a database the entire file has to be restored from the backup system and then susbsequent changes reapplied from the data base managers log. By using a product specific backup and restore system it is possible to take advantage of knowledge of the internal structure of the database to only backup those parts within a database that have changed since the last backup and during restore only recover those parts that are still required. Background

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 45% of the total text.

Page 1 of 3

  Incremental backup to provide fast media recovery for a message queueing system

Disclosed is a system that allows fast media recovery for a message queueing system by using incremental backup of the messages within the queing system.

     Incremental backups are common in disk backup systems backing up all files that have changed since the last backup time however they tend to be general purpose programs that backup and restore entire files without knowledge of the internal database structure. Therefore to restore a database the entire file has to be restored from the backup system and then susbsequent changes reapplied from the data base managers log.

     By using a product specific backup and restore system it is possible to take advantage of knowledge of the internal structure of the database to only backup those parts within a database that have changed since the last backup and during restore only recover those parts that are still required.

Background

IBM MQSeries* queue managers and similar programs provide facilities for storing messages on queues. For certain classes of message, queue managers provide recovery facilities. These recovery facilities can re-create a queue when the primary storage used to hold its messages fails and then restore the messages so that the final state of the queue is the same as at the time of the storage failure.

     Typically the recovery facility restores messages from a back-up copy of the queue (possibly a "fuzzy" back-up) and then replays the queue manager's log to reapply changes to the queue.

Problem Description

     To minimize the time that applications are unavailable following a primary storage media failure it is desirable that the recovery process be as fast as possible. Performance analysis has indicated that the factor which most influences the recovery time is the amount of data that has to be read from the queue managers' logs so to minimise recovery time backups should be taken as frequently as possible (every few minutes as opposed to daily or weekly).

     In a normal message queing system messages should remain on the system for only a short time before being processed and so each backup will be quite small and there will be little overlap with messages appearing on more than one backup. However due to application design or error (application or communication link unavailabilty) there may be occasions when a large number of messages build up and remain on the queues for a considerable time. The cost of running frequent backups that each backs up the same set of old messages could easily become too expensive an insurance policy against the, hopefully, rare event of a storage failure. Also if the backups are stored on the queue manager's log the cost of reading past backups for storage devices unaffected by the failure could slow down the log replay phase of the recovery process.

     What is needed is a means to take incremental backups so that each backup is cheaper to run because it doesn't need to i...