Entering content frame

Background documentation Restore Function (restore) Locate the document in the library structure

The restore function is used to send a request to Backint for MaxDB to restore backups. This request consists of the user ID (see also Variables) and a list of the files and/or pipes that need to be restored.

For files, the information consists of the Structure linkbackup ID, its name, and the directory to which the file is to be restored. For pipes, the information consists of the backup ID, its name, and the name of the current pipe to which the content of the backup pipe is to be restored. The name of the directory for the new file and the name of the current pipe are optional pieces of information. If no backup ID is specified, then the last Structure linkbackup of the file or pipe is restored. Information is returned that indicates which files or pipes have been restored successfully and which backups have been used.

The order in which the files in the list are restored is freely determined by Backint for MaxDB.

Type of Data Carrier

For the restore function, Backint for MaxDB uses its own information or information from the backup tool to decide whether an object is a file or a pipe. Files and pipes can be combined in the input list.

Data Transfer

If the input list contains files, these are restored in the file system.

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. It restores the data in a pipe in the order in which it was read from the original pipe backup. 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 write 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 written, 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 written to 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 write to 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 a maximum number of these pipes in parallel. This minimizes restore times. Interdependencies between the pipes or the processes/threads that process these pipes do not need to be avoided while data is being restored, since the database itself processes the pipes independently of each other.

Max DB can support parallel restoring of pipes, although this is not mandatory. It is also possible to design MaxDB for 7.4.03 database versions only or for all the database versions to which this documentation applies. However, the supported type of parallel restore must match the parallel backup type.

 

Leaving content frame