logo

GBase News

Focus on Database Software Products and Services, Committed to becoming the most trusted provider of database products for users.

GBase 8s Backup Essentials: onbar Backup and Recovery Guide

Published on 2026-10-30

1. When to Use onbar

Recommended Scenarios

  • Medium-to-large database instances and core business systems using a multi-dbspace tablespace architecture

  • Core transaction workloads with data misoperation risk, requiring rollback to any point in time after a failure and compliance with RTO/RPO targets

  • Enterprise compliance operations scenarios requiring complete backup history records, backup set expiration and retirement, and full backup lifecycle management

  • Tight backup windows where multi-device parallelism can shorten backup duration

Not Recommended For

  • Small test databases or lightweight non-core workloads pursuing minimal, zero-configuration operations

  • Simple scenarios without an XBSA storage management architecture that only require basic local backups

Note: ontape also reliably supports production workloads. onbar's value lies in advanced features such as point-in-time recovery, parallelism, and backup lifecycle management.

2. Core Capabilities at a Glance

  • Uses an XBSA storage manager to uniformly track backups and storage media

  • Supports Level 0 full, Level 1 incremental, and Level 2 incremental physical backups

  • Supports precise point-in-time recovery

  • Performs parallel backup and recovery of different storage spaces

  • Uses multiple tape drives concurrently for backup and recovery

  • Provides built-in backup metadata management, backup set validity verification, and expiration cleanup, supporting compliant operations

3. Essential Production Configuration

onbar is based on the XBSA storage backup architecture. In addition to the built-in PSM storage manager, it can connect to third-party storage managers that comply with the XBSA standard.

Using the built-in PSM as an example, both the database parameters and the PSM storage directory configuration must be in effect simultaneously — this is a prerequisite for backups to work.

Example Environment

GBase 8s installation root directory: /home/gbase

Physical backup: /opt/gbase/backup/DBSPOOL

Logical backup: /opt/gbase/backup/LOGPOOL

1. Dynamic Core Database Parameter Configuration

Bind the XBSA storage library file that onbar depends on:

onmode -wf BAR_BSALIB_PATH=/home/gbase/lib/libbsapsm.so

Configure the log-full alarm trigger script:

onmode -wf ALARMPROGRAM=/home/gbase/etc/log_full.sh

Configure the dedicated logical log backup directory (required):

onmode -wf LTAPEDEV=/opt/gbase/backup/LOGPOOL

2. PSM Backup Directory Definition

onbar uses the PSM tool to manage backup media groups and storage priorities. Define the physical backup and logical log backup directories separately, and set the highest-priority storage policy for both.

# Define the physical backup storage pool DBSPOOL (highest priority) 

onpsm -D add /opt/gbase/backup/DBSPOOL -g DBSPOOL -p HIGHEST -t FILE 

# Define the logical log backup storage pool LOGPOOL (highest priority) 

onpsm -D add /opt/gbase/backup/LOGPOOL -g LOGPOOL -p HIGHEST -t FILE

3. Remove Default Low-Priority Directories

The system includes default LOW-level backup directories by default. We recommend removing them.

# Remove the default DBSPOOL low-priority old directory 

onpsm -D del /home/gbase/backups -g DBSPOOL -y 

# Remove the default LOGPOOL low-priority old directory 

onpsm -D del /home/gbase/backups -g LOGPOOL -y

Note: Removing a directory definition does not delete the physical files on disk.

4. Verify That the Backup Directory Configuration Is in Effect

After configuration, run the list command to confirm that the custom storage pools, paths, and priorities are all in effect and that no default configuration remains.

onpsm -D list Type  Prio     Block/Size (MB)  Pool Name  Device Name FILE  HIGHEST  - - / - -        /opt/gbase/backup/DBSPOOL FILE  HIGHEST  - - / - -        /opt/gbase/backup/LOGPOOL

5. Backup Log Monitoring Configuration

The onbar runtime log is controlled by the BAR_ACT_LOG parameter. All backup, recovery, verification, and error logs are written to this file — it is the core basis for production troubleshooting and operations auditing.

BAR_ACT_LOG /home/gbase/tmp/bar_act.log

Operations guideline: For daily backup anomalies, recovery failures, broken backup chains, and similar issues, check this log first instead of blindly repeating backup and recovery operations.

4. Common Production Backup Commands

1. Level 0 Full Backup of the Entire System

A full backup is the core baseline for all incremental backups and log recovery, ensuring the integrity of the backup chain.

onbar -b -L 0 -w

Note: onbar and ontape backup media are completely incompatible and cannot be used for cross-recovery. When switching backup tools, you must run a new Level 0 baseline backup.

2. Level 1 Incremental Backup of the Entire System

Backs up only data changed since the last Level 0 backup, significantly shortening the backup window and reducing database business pressure.

onbar -b -L 1 -w

3. Level 2 Incremental Backup of the Entire System

Backs up only data changed since the last Level 1 or Level 2 backup, suitable for short-cycle, high-frequency enterprise backup scenarios.

onbar -b -L 2 -w

4. Backup of Specified Storage Spaces

Performs a Level 0 backup of the database spaces named dbspace1 and dbspace2.

onbar -b dbspace1 dbspace2

5. Single Logical Log Backup

Automatically archives full logs and switches the active log, ensuring incremental data is traceable and recoverable.

onbar -b -l -c

6. Continuous Log Backup

Runs continuously in the background and archives logs in real time, enabling precise point-in-time recovery.

onbar -b -l -c

5. Backup Set Integrity Verification Commands

1. Verify the Full-System Backup

Use case: verify the integrity of the full-system backup set.

onbar -v -w

2. Verify Only the Physical Backup

Use case: only the validity of the dbspace physical backup matters; no need to verify the logical log chain.

onbar -v -p

3. Verify the Backup of a Specified dbspace

Use case: before planning a recovery of a specific tablespace, verify only the backup corresponding to the target dbspace without scanning the entire backup set.

onbar -v dbspace1

4. Verify the Backup Up to a Specified Point in Time

Use case: before performing PITR (point-in-time recovery), verify that the entire physical + log backup chain from the Level 0 backup to the target time is complete and usable.

onbar -v -t "2026-09-14 14:30:00"

6. Core Recovery Scenario Commands

1. Full Cold Restore

Use case: total machine crash, core space corruption, rebuild on a different machine, or rollback after global data misoperation.

onmode -ky onbar -r -w

Note: The -w parameter can only restore full-system backup sets generated by onbar -b -w. For ordinary backups, use onbar -r for recovery. After recovery, the database is in Quiescent state; after verifying the data, run onmode -m to return to On-Line state.

2. Phased Recovery

onbar -r -p performs only physical recovery without replaying logical logs, leaving the data at the physical backup snapshot. Then onbar -r -l separately replays the logical logs.

onmode -ky onbar -r -p onbar -r -l

Note: After physical recovery completes, the instance enters Fast Recovery. After logical log replay finishes, it is in Quiescent; run onmode -m to return to On-Line.

3. Precise Point-in-Time Recovery (Emergency Misoperation Recovery)

Use case: accidental table deletion or batch data misupdate, requiring precise rollback to any point before the failure occurred.

onmode -ky onbar -r -t "2026-09-15 16:00:00"

Note: After point-in-time rollback, new transaction data after the specified time is lost. Confirm before proceeding.

4. Online Hot Restore (Non-Disruptive Repair)

Use case: a single business tablespace is corrupted, with no downtime required, minimizing business impact.

onbar -r dbspace1

Note: Core system spaces such as rootdbs, physical logs, and logical logs do not support hot restore.

7. Conclusion

As GBase 8s's enterprise-grade core backup tool, onbar is built on the XBSA standard storage architecture and provides advanced capabilities including incremental backup to reduce pressure, point-in-time rollback to prevent accidental deletion, cold and hot recovery to reduce failure impact, and automated management to support compliance.

Selection guidance: onbar has a more complex architecture, with a supporting storage manager and the sysutils metadata system, so operations learning costs are relatively higher. ontape is lightweight with no additional metadata dependencies and is suitable for simple, stable scenarios. Neither is absolutely better — choose based on business RTO/RPO requirements and operational capabilities.

FAQ

1. How should I choose between onbar and ontape?

Answer: ontape is lightweight with no additional metadata dependencies and is suitable for simple, stable scenarios. onbar has a more complex architecture with a storage manager and the sysutils metadata system, so operations learning costs are relatively higher; its value lies in advanced features such as point-in-time recovery, parallelism, and backup lifecycle management. Neither is absolutely better — choose based on business RTO/RPO requirements and operational capabilities.

2. What configurations must be completed before an onbar backup?

Answer: Using the built-in PSM as an example, both the database parameters and the PSM storage directory configuration must be in effect simultaneously. Configure the BAR_BSALIB_PATH, ALARMPROGRAM, and LTAPEDEV parameters via onmode -wf, and use onpsm -D add to define the physical backup and logical log storage pools.

3. Can onbar and ontape backups restore each other?

Answer: No. onbar and ontape backup media are completely incompatible and cannot be used for cross-recovery. When switching backup tools, you must run a new Level 0 baseline backup.

4. How do I use onbar to recover from accidental table deletion or data misupdate?

Answer: Use precise point-in-time recovery: stop the database with onmode -ky, then run onbar -r -t "<target time>" to roll back to any point before the failure occurred. Note that new transaction data after the specified time will be lost. Confirm before proceeding.