Configure and implement an Informix ON-Bar backup solution

Introduction
Editor's note: in DBA's work, backup has gradually become a hard task that is not often considered. However, any good DBA can tell you that data should be restored when a system failure occurs, at this time, backup will suddenly become the only and most important thing for you and your management chain. As backup integrity is critical, you need a backup tool that ensures integrity. What is the answer? Informix ON-Bar.
As the system grows larger, it becomes more and more difficult to run the backup within a limited period of time. You need a backup solution that can be scaled along with other system components. What is the answer? ON-Bar.

Ensuring that the recovery running time does not exceed the time spent on manual data input is another important aspect of backup. How can we achieve this goal? Yes, you guessed it .) ON-Bar. The Informix ON-Bar backup tool may seem very scary at first, especially if you have been using ontape or onarchive for backup for a while ).

This article will discuss how to configure and implement the ON-Bar solution from a layman's perspective. In this article, you will learn: What is ON-Bar and its capabilities

ON-BarBrief Introduction

ON-Bar is a fully scalable backup product for Informix databases. It allows you to run backup and recovery in parallel, depending on the number of threads you choose to run, which can greatly increase their speed. ON-Bar is applicable to Informix systems of any size.

If you want to reduce system backup and recovery time, ON-Bar can meet your requirements. When other processing is running ON the machine, the ON-Bar operation can also be performed, because when the backup is running, it does not require any part of the database to be taken offline. However, when ON-Bar is running, it does consume a large amount of system resources. Therefore, we recommend that you reduce the number of other running processes when running the backup.

ON-BarComponents-Storage Manager

To make ON-Bar work, you must install and configure the Storage Manager. The storage manager is the software that processes the tape System for you. Some of its functions are to write data to the actual tape, track the disk on which the data is stored, allocate the data to various categories, and process the retention time. These tools are usually expensive and require specialized knowledge for configuration.

The example of the Storage Manager is the NetWorker of Legato and VERITAS of VERITAS. Informix also comes with a Storage manager, whose engine is Informix Storage ManagerISM), which is basically a small version of NetWorker of Legato. A small system with four or fewer tape drives that can be backed up with a minimum number of threads can run normally. This article does not discuss how to set up this product. This article assumes that you have configured the Storage Manager .)

ON-Bar reads data from the database and then communicates directly with the Storage Manager to store the data to the tape. The Storage Manager tracks the whereabouts of the data and how long the data will be retained.

Backup Policy
Before we jump directly to how to configure the ON-Bar and run it, I would like to briefly discuss how to implement an appropriate backup solution. In particular, I will discuss the backup level and their impact on the number of storage/recovery times. If you have been using ontape for a long time, you may have an in-depth understanding of this, but there are also some considerations specific to ON-Bar.

ON-Bar provides three different levels of backup:
Level 0, which backs up all data on the system;
Level 1: it backs up all changed data since the last level 0 backup; and
Level 2: it backs up all changed data since the last level 1 or level 0 backup.
These different levels can be used together to shorten the backup operation. Ideally, we only need to run level 0 once every night. However, the actual backup running time and the number of tapes must be considered. Compared with level 0, level 1 or Level 2 backup runs much faster. However, if you need to recover, it takes a longer time. This is because you must first restore level 0 data, then restore level 1, and finally Level 2. Before implementing the solution, you must carefully consider how to weigh the gains and losses of backup time and recovery time. Shows a typical backup solution.

If you have enough time and enough backup tape, we recommend that you perform level 0 backup every day. This will greatly increase your recovery time, especially for large systems). More tapes will be used and backup will take longer. ON-Bar is very scalable. You can add a tape drive to keep up with the data growth rate, enough to shorten the backup running time-I have seen that 1 TB of system backup is completed in three hours using ON-Bar.

The ON-Bar operation has a significant impact ON the query time. Some queries take 10 times as long as the original time. Therefore, we recommend that you run the backup when no one else uses the machine. If this is not possible, the backup will be performed when the system load on the machine is minimal.

Another important thing to consider is that ON-Bar only provides physical backup, that is, it can cope with database space dbspace) offline, disk faults and engine faults. If someone deletes a table, runs an update error, or deletes many rows that they should not delete, ON-Bar will not provide protection. I call these types of errors logical or user errors.

Using ON-Bar makes it difficult to restore logical errors. This is because you cannot recover a single table from the ON-Bar backup-if you want to perform a table-level backup, you must have a plan to dump those tables to the disk. If you want to use ON-Bar to restore a table, you need to execute point in time for the whole system to restore the table. The time point should be before the time when a logical error occurs.
　
What backup is required?

In addition to the main purpose of running the backup for your data), other files should be backed up each time you run the ON-Bar backup.
$ INFORMIXDIR contains some files required for ON-Bar to complete restoration. These files are called emergency boot files ". They are used to replace the sysutils database in the cold recovery from full loss events. We recommend that you back up these files after each ON-Bar backup.

Most storage managers have an Informix-specific part that you can handle for you and you will know if you have this part because you need to pay additional fees for it ). This Informix part is required when running ON-Bar. It is important to ensure that these files are being backed up, because this is usually an option that can be disabled.

If you are using an ISM or storage manager that does not back up these files for you, we recommend that you back up the entire $ INFORMIXDIR after each backup. This ensures that you do not omit a file and will not be able to recover data in the future. If you cannot back up the entire $ INFORMIXDIR file, see obtain the list of emergency boot files and other files I suggest you back up.
SysutilsDatabase

The sysutils database stores all data ON-Bar. This database will remember the Storage Manager identity that the storage manager needs to retrieve information) and information about what was backed up and when it was backed up. When using ON-Bar, it is a crucial database, just like the relationship between sysmaster and database ).

You will notice that the sysutils size increases when the backup is run. To regularly clear some data in the database, you can use the onsmsync utility to perform this operation. If you are running an earlier version of Informix, you may find that this utility does not exist. This will introduce us to the topic of frequent server upgrades, but I will leave this question to another discussion ).

ConfigurationON-Bar
Configuring ON-Bar includes setting ON-Bar to interact with the Storage Manager, setting the ON-Bar file itself, and setting all onconfig parameters to run ON-Bar. See to obtain the ON-Bar configuration file list.

When setting ON-Bar, the first file to be viewed is the sm_versions file in $ INFORMIXDIR/etc. This file defines the Storage Manager to the ON-Bar. The default line in this file will be the Informix part of the ISM Storage Manager), which will clearly tell you what to put in this file.

The actual ON-Bar command in $ INFORMIXDIR/bin is a script for V8.2, V7.3, and later versions ). This is a good place to set certain environment variables, which are any environment variables specific to the storage manager required for the ON-Bar operation. If you are running Informix Extended Parallel Server? XPS), and the other place where the environment variable is set is the $ INFORMIXDIR/etc/start_worker.sh file. This file will be called when the log is full ON the current day or another worker thread needs to be started ON-Bar.

For details about how to control ON-Bar parameters in the onconfig file, see ). The following describes the parameters whose default values should be changed.

BAR_ACT_LOG is the full path name of the ON-Bar log file. This file is usually called bar_act.log. The example is BAR_ACT_LOG/Informix/logs/bar_act.log.

BAR_BOOT_DIR is the directory name that contains the emergency boot file. Unless you move them, the directory is $ INFORMIXDIR/etc. In this example, BAR_BOOT_DIR/usr/Informix/etcBAR_RETRY is the number of times the ON-Bar process retries before it is abandoned if the ON-Bar process fails at the beginning. I usually set this value to 0, because the failure of the ON-Bar process usually indicates that something else is wrong and retry does not work. In this example, BAR_RETRY 0BAR_PROGRESS_FREQ controls the frequency of writing progress to the bar_act.log file ON-Bar. I keep it as 0 unless further debugging is required. By default, ON-Bar writes a large amount of data to log files.

BAR_WORKER_MAX directly controls the number of parallel operations in ON-Bar. This includes how many processes will be started when backup or recovery is run-if too many processes are started, the machine will be shut down. If too few, the backup will take more time than they would have been. The DLT tape drive can accept 10 processes before performance degradation, while the common 8mm tape drive can only accept five processes.

Confirm this parameter through the experiment because your Storage Manager/tape drive settings may be different. Correct setting of this number is the key to ON-Bar performance-you want it to be as high as possible before declining returns. An Important Note: Make sure that the concurrency settings of the Storage Manager are equal to this number. Otherwise, the number of ON-Bar processes that you start will exceed the number that the storage manager can process in ISM, this is the stream setting ). Each ON-Bar worker thread processes a database space or log file.

BAR_IDLE_TIMEOUT is the number of minutes that the ON-Bar will wait before the idle process is aborted due to an exception. Setting this parameter too high will cause many ON-Bar_w processes to be suspended after the backup is complete.

BAR_BSALIB_PATH should be provided to you by your Storage Manager vendor. It is a path that leads to the library used to communicate with the Storage Manager.
ISM_DATA_POOL is a default pool. database space backup is written from the storage manager to this default pool. See the ISM_LOG_POOL comment below.

ISM_LOG_POOL is a default pool. Logical log backup is written from the storage manager to this default pool. I always send logs and data to the same pool. This makes it unnecessary for me to use a tape drive dedicated to logical log backup. It also helps me maintain the capacity in the storage manager because I only need to track a set of tapes. When recovery is required, restoring logs and data in one operation also results in a much faster speed.

If XPS is used, you need to set each coserver to an independent ON-Bar entity. I recommend that each collaborative server back up its own logs and data. This eliminates the need for XPS to move all the data of a collaborative server across switches, making each collaborative server a dedicated server for its own data. Another note of XPS is to ensure that the concurrency of the Storage Manager is set to the sum of the BAR_WORKER_MAX parameter of the given node. For example, if there are two collaborative servers on one machine and a storage manager that can process 10 threads, set BAR_WORKER_MAX of each collaborative server to 5.

XPSParameters include

LOG_BACKUP_MODE should be set to NONE, CONT, or MANUAL. NONE indicates that log files are never backed up, which is equivalent to setting the Log Device to/dev/null. In this case, logical recovery cannot be performed. This method is generally only applicable to instance installation. Once real data is available on the system, logs must be saved.

MANUAL requires you to manually run the log backup ON-Bar-l). If you forget to back up, you will be at risk of using up logs. If you store logs and data in two different pools with only one tape drive, this may be your only choice.

CONT backs up logical logs immediately after they are full. ON-Bar starts the start_worker.sh script to back up the log file. This is the right option for a real 24x7 operation, 24 hours a day, 7 days a week. If the data and log pool are set to the same, the tape drive will not be dedicated to logs. If you do not do this, you must have a dedicated Log Device and there is always a tape in it for this method to take effect.

BAR_SM is the storage manager identifier. This is the collaborative server number, which is associated with these ON-Bar parameters.
BAR_SM_NAME is the name of the Storage Manager. Generally, this is the name of the host where the Storage Manager resides and is used for backup of the collaborative server.
BAR_WORKER_COSVR is the collaborative server where the collaborative server storage manager is located.
BAR_DBS_COSVR indicates the collaborative server to which the database space is backed up. This should be the same as the BAR_SM associated with it; otherwise, the data must cross the switch to its correct coprocessor.
BAR_LOG_COSVR is the collaborative server that backs up logical logs. This should be the same as the BAR_SM associated with it; otherwise, the data must cross the switch to its correct coprocessor.