Gbak improvements and multi-file backup (gsplit).

For both backup and restore operations, it takes less time than its 4.X version.

In UNIX, earlier versions forced both input and output to be files. More consistent with the UNIX spirit, this versions accepts input from stdin and output to stdout, allowing the traditional "pipe" techniques to be applied in UNIX with the inherent power they provide.

One problem with earlier versions was that gbak only could produce a giant and linear backup file. Since TAPE operations are sequential, this is not a great problem (random access to files is more restrictive in terms of size, usually), but even so, the operating system imposes a limit on a maximum file size. Gsplit comes to the rescue: it was created to split a backup into several files and to reassemble a multi file backup into a stream that can be restored to a database. The operation is done using pipes and given that only the UNIX gbak accepts streams as input or output, this functionality is available only in UNIX. Please, remember that at the time the IB5 documentation was written, Linux wasn't widely accepted as now in year 2000, so probably when an IB feature is implemented in UNIX, it can be found in Linux, too.

A faster gbak is a blessing, since the importance of backup and restore operations goes further than a simple security copy of the database:

• It can be used to produce a "clean" database. By default, the garbage collection happens when a database is backed up (unless gbak is given a parameter to avoid that), so the restored backup produces a db with only one version for each record. Allowing garbage collection as a database is being backed up produces smaller backup files at the cost of greater times; whereas backing up without garbage collection improves total times but the backup itself keeps multiple version of records if they exists at the time the backup happens, so the backup file is bigger.
• It can be used to get rid of some corruption that's hard (if not impossible) to eliminate with gfix. Usually, a backup without garbage collection and subsequent restore does the trick.
• It can be used to reconfigure a database into multiple database files. Since 32-bits operating systems usually allow up to 2GB for a random access file (NT allows up to 4GB, but some weird responses from the IB tools have been observed above in the 2-4GB range), multi-gigabyte databases should be split into several files (maybe in different disk partitions) in the same machine. Even when adding new files to a multi file db is straight, usually this is done when one db is near the (dangerous) maximum allowed for the file system, so for defining more files but at the same time changing the size of the first file, a backup is required. When restoring, the size of each file can be set at will.
• It can be used to move databases between two different platforms. Databases are not compatible in binary format between Netware and NT, for example, but a backup made in transportable format (the default, using XDR, a standard representation format) can be restored on another platform.

Again, the Operations Guide devotes a chapter to database backup and restore, using the command-line utilities and where available, the GUI utilities.

This page was last updated on 2001-01-17 04:17:25