Backup Function 

General Function Description

The backup function defines a backup request for a list of files or pipes, and sends this request to Backint for MaxDB. Backint for MaxDB backs up these files or pipes, and generates a backup ID for each backup object as a response. Here, the combination of user ID, backup ID and backup object name is guaranteed as being unique for each backup object.

Backint for MaxDB informs the user which files or pipes have been backed up successfully and which have not, which backup ID was assigned to each file and to each pipe, and how many bytes were saved for each pipe.

The order in which the files and/or pipes in the list are backed up is freely determined by the external backup tool.

Type of Backup Objects

The input list for the backup function indicates whether an object is a file or a pipe. You can combine files and pipes in the input list.

Backint for MaxDB and BACKINT (for Oracle) differ in the objects they allow to be backed up:

BACKINT (for Oracle) allows files, directories, and raw devices.

Backint for MaxDB allows only files and pipes.

Data Transfer

If the input list contains files, then they are backed up by the external backup tool, however, the backup can be made in a random order and degree of parallelism.

The following rules apply when pipes are restored:

The software (DBM server) or user that called Backint for MaxDB, ensures that every pipe in the list is opened and closed at least once. Backint for MaxDB returns an error for every pipe that has not been opened. To enable a data transfer, both sides of a pipe must be opened; one side by the database software or user, and the other side by Backint for MaxDB. If pipes listed in the input file do not exist, Backint for MaxDB either creates them or checks periodically to see whether they exist.

The pipes are opened for read access only. The data transfer through a pipe ends when one side of the pipe is closed.

If a database version lower than 7.4.03 is used and more than one pipe is specified in the input file, they must all be processed in parallel and in real time to avoid deadlocks. This means that Backint for MaxDB must process all pipes simultaneously, but independently of each other.

When one pipe is opened or read, this action must not block any other pipes listed in the input file from being opened, or any data from being transferred. This is why Backint for MaxDB checks every pipe periodically to make sure that it can be opened or that data can be read from the pipe. This can be achieved by starting one child process or thread for each pipe and by avoiding any synchronization between these processes and/or threads. In this way, the processes or threads can open and read the pipes with normal blocking operations, since the operating system switches periodically to the processes or threads of the other pipes.

If a database version from 7.4.03 is being used, and multiple pipes are specified in the input file, then Backint for MaxDB processes at least some of these pipes in parallel. Otherwise, there would be no advantage in being able to make parallel backups. Interdependencies between the pipes or the processes/threads that process these pipes do not need to be avoided during the backup, since the database itself processes the pipes independently of each other.

MaxDB can support parallel backups with pipes, but this is not mandatory. You can also configure MaxDB for database version 7.4.03 only, or for all database versions covered by this documentation.