Brief introduction
Editor's note: In the work of the DBA, backups are becoming a chore that is not often considered. However, any good DBA can tell you that when a system failure occurs, the data should be recovered, and the backup will suddenly become the single most important thing for you and your management chain. Because the integrity of backups is critical, you need a backup tool that ensures integrity. What's the answer? Informix On-bar.
As the system grows larger, it becomes more and more difficult to keep backups running within a limited time. You need a backup solution that can be scaled along with other system components. What's the answer? On-bar.
It is another important aspect of backup to ensure that the recovery does not run longer than the time it takes to manually enter data. How can we achieve this goal? (yes, you guessed right.) ) On-bar. The Informix On-bar Backup tool may look scary at first (especially if you've been using Ontape or onarchive for a while to back up).
This article will discuss how to configure and implement On-bar solutions from a layman's perspective. In this article, you will learn: what On-bar is and what ability it has
On-bar Brief Introduction
On-bar is a fully scalable backup product for the Informix database. It allows you to run backups and restores in parallel, which allows you to significantly improve their speed, depending on the number of threads you choose to run. On-bar applies to Informix systems of any size.
If you want to reduce system backup and restore time, then On-bar can meet your requirements. On-bar can also run when other processing is running on the machine, because it does not require any part of the database to be taken offline when the backup is run. However, when On-bar is running, it does consume a large amount of system resources, so it is recommended that you minimize the number of other running processes while running the backup.
On-bar Components-Storage Manager
In order for On-bar to work, you must install and configure the Storage Manager. The storage Manager is the software that handles the tape system for you. Some of its functions are to write data to the actual tape, track what data is on the tape, assign the data to various categories, process retention time, and so on. These are usually more expensive tools and require some expertise to configure.
An example of a storage manager is the netbackup of Legato's Networker and Veritas company. Informix also comes with a storage manager whose engine is called Informix Storage Manager (ISM), which is essentially a scaled-down version of Legato's Networker. A small system with four or fewer tape drives that can be backed up with a minimum number of threads can function correctly. (This article does not discuss setting up the product, this article assumes that you have configured the Storage Manager.) )
On-bar reads data from the database, communicates directly with the storage Manager, and stores the data to tape. The storage Manager tracks the whereabouts of the data and how long the data will remain.
Backup strategy
Before we jump directly to how to configure On-bar and let it run, I'd like to briefly discuss how to implement the appropriate backup solution. In particular, I'll discuss backup levels and their impact on save/restore times. If you have been using Ontape, you may already have an in-depth understanding of this, but there are some on-bar specific considerations to note.
On-bar provides three different levels of backup:
Level 0, which backs up all the data on the system;
Level 1, which backs up all changed data since the last level 0 backup;
Level 2, which backs up all changed data since the last level 1 or level 0 backup.
These different levels can be used in combination to shorten the operation of backup operations. Ideally, we would just run level 0 every night, and that would be fine. However, it is often necessary to consider the actual constraints of the backup run time and the number of tapes. Level 1 or Level 2 backup runs much faster than level 0, but it takes longer if you need to recover. This is because you must first restore level 0 data, then restore Level 1, and finally level 2. Before implementing a solution, you must carefully consider how to weigh the pros and cons of backup time and recovery time. A typical backup solution is shown in Figure 1.
If you have enough time and enough spare tapes, I recommend that you do a level 0 backup every day. This greatly increases your recovery time (especially for large systems), will use more tapes, and will take longer to run backups. The scalability of the On-bar is excellent, you can usually add a tape drive to keep up with the growth of the data, enough to shorten the backup run time-I've seen a backup of 1 TB systems with On-bar within three hours.
On-bar has a significant impact on query times at run time (some queries run at 10 times times the same time), so it is recommended that you run backups when no one else is using the machine. If you cannot do so, run the backup when the system load on the machine is minimal.
Another important consideration is that On-bar provides only physical backups, that is, it can cope with database space (dbspace) offline, disk failure, and engine failure. On-bar does not provide protection if someone deletes a table, runs an incorrect update, or deletes many rows that they should not delete. I called these types of errors a logical (or user) error.
It is difficult to restore logic errors using On-bar. This is because you cannot recover a single table from a On-bar backup-if you want to make a table-level backup, you must have planned to dump those tables to disk. If you need to recover a table using On-bar, you need to restore the entire system's execution point at time, which should precede the time of the logical error.