Catalog Recovery

Using Warm Standby or Log Shipping

NTT has developed a shared-nothing replication system for PostgreSQL implemented with transaction log shipping. The goal is to minimize the system downtime and the impact for update performance. Failover can be done within 15 seconds and the overhead is at worst 7% on heavily updated workloads in the current implementation.

Using this technology, you are able to always have a valid copy of your Catalog across the network. If something goes wrong with your Catalog server, you just have to activate the PostgreSQL master mode on the backup node, change the virtual IP address and restart the Director.

The detail of those procedures are available on https://www.postgresql.org/docs/current/high-availability.html

Using Catalog Backup

If you have backed up your database nightly (as you should) and you have made a bootstrap file, you can rapidly restore your database (or the ASCII SQL output). Make a copy of your current database, re-initialize it, then you should be able to run Bacula. If you now try to use the restore command, it will not work because the database will be empty. However, you can manually run a restore job and specify your bootstrap file. Once the database is restored, you can start the database import process. When restoring from the ASCII SQL file, depending of the Catalog size, it can take several hours to complete. Restoration can be done much faster if you use binary backups of the Catalog.

Note that it’s also possible to recover your Catalog backup with the backup Job output, or by scanning volumes. All these procedures are completely described in The Restore Command chapter of the manual.