Making GBase 8a Backup and Recovery Reliable: Full Backups, Incrementals, and Recovery Drills

The gcrcman tool in GBase 8a supports backup and recovery at the cluster, database, table, and batch-table levels. In a production gbase database, knowing the commands isn't enough — you need a sound backup strategy, verified recovery prerequisites, and the right granularity for the incident you're facing. This guide covers full and incremental backups, table‑level recovery, batch backup limits, and regular recovery drills.

1. Layered Backup Strategy

Don't back up everything the same way. Design your strategy around business importance and recovery objectives:

• Core databases: Periodic full backups (level 0) as the ultimate safety net.
• Frequently changing objects: Incremental backups (level 1) to refine recovery points without the cost of daily fulls.
• High‑risk tables: Dedicated table‑level or batch backups to recover from accidental drops or bad DELETE/UPDATE — by far the most common incidents.

2. Prerequisites Matter More Than the Commands

Before running gcrcman.py, ensure:

• You operate as the dbauser specified during installation.
• Execution happens on a coordinator node.
• All nodes are network‑reachable, and the backup directory exists on every node with read/write permissions for dbauser.
• The backup path is never under $GCLUSTER_BASE, $GBASE_BASE, or $GCWARE_BASE.
• The cluster topology (management nodes, data nodes, distribution info) at recovery time matches the topology at backup time.

3. Essential Commands

# View backup history
python $GCLUSTER_BASE/server/bin/gcrcman.py -d /backup/cluster_bak -e "show backup"

# Cluster‑level full backup
python $GCLUSTER_BASE/server/bin/gcrcman.py -d /backup/cluster_bak -e "backup level 0"

# Database‑level full backup
python $GCLUSTER_BASE/server/bin/gcrcman.py -d /backup/cluster_bak -e "backup database appdb level 0"

# Table‑level full backup
python $GCLUSTER_BASE/server/bin/gcrcman.py -d /backup/cluster_bak -e "backup table appdb.fact_order level 0"

# Table‑level force recovery (overwrites existing table)
python $GCLUSTER_BASE/server/bin/gcrcman.py -d /backup/cluster_bak -e "recover force table appdb.fact_order"

# Refresh table metadata after recovery
refresh table appdb.fact_order;

Key parameters: -r sets parallelism (default 4), -t sets the transaction wait timeout (default 300 s), -C enables backup data verification.

4. Table‑Level Recovery Is the Most Practical

Dropping a table by mistake is the most frequent production accident. After performing a table‑level recovery, always run refresh table to re‑register the table object in the cluster. Verify the recovered row count matches expectations.

5. Batch Backup Limitations

To back up a set of tables, list them in a file (format database.table):

appdb.fact_order
appdb.fact_trade_detail

python $GCLUSTER_BASE/server/bin/gcrcman.py -d /backup/cluster_bak -e "backup tables table.list level 0"

Critical rule: Within the same backup cycle, the table.list file must be identical for the full backup and all subsequent incremental backups. You cannot add new tables to an incremental run — doing so corrupts the cycle logic.

6. Recovery Drills Validate the Whole Effort

Untested backups are worthless. Establish a regular drill cadence:

• Weekly: Restore a few critical tables and verify row counts.
• Monthly: Perform a full database recovery exercise.
• After any topology change: Re‑validate the entire recovery chain.
• During every drill, check: row counts, business query correctness, view and index integrity, and whether recovery time fits the acceptable window.

A reliable backup and recovery practice in a gbase database goes beyond running gcrcman.py. It's a closed loop of strategy, permissions, topology awareness, and continuous verification.