Full System Recovery: PostgreSQL

The difference between a full PostgreSQL Server restore and a full system restore is the severity of the problem. Normally, if data is lost or removed, it is recovered from the archives using the restore procedures in the CommCell Console.

However, when a normal restore operation cannot correct a software and/or hardware corruption problem on the client system (such as a damaged or destroyed operating system, hardware, hard drives, etc.), some level of full system restore is required.

The level of system restore required may be different as described below:

When the client system (operating system, hardware, hard drives, etc.) is damaged or destroyed, a full system restore may be required.
When the database is corrupted and a restore is required, both the application software and database must be restored. This can be achieved by restoring the data and log files using the restore options at instance level in the Agent.

Preparing for a Full System Recovery

Before you begin a disaster recovery, make sure to do the following:

Perform regular backups of application files along with their binaries. Frequent file system and dump backups will also be helpful for a successful disaster recovery.
Ensure that the client, PostgreSQL Agent software , instance names and user created subclients are the same as the corrupted or damaged client while performing a disaster recovery. The client should have the same PostgreSQL version.

Managing Backups

As a best practice, it is recommended that you group databases into multiple subclients as follows:

Add larger databases into separate subclients.
Add small databases together into one or more subclients. This is important for the following reasons:
- During Disaster recovery, when you have to quickly rebuild the entire instance, you can concurrently restore all the subclients together.
- During Backup failures, the backup will restart from the beginning of the database instead of from the beginning of the entire instance. Similarly, this will ensure that large database backups are not affected by restarts from a smaller database.
Once the subclients are created, schedule frequent backups for dynamic data and regular backup schedules for static data in the SQL Server.

Browse Databases

This Agent captures the state information for the database at backup time. In the event of system failure, it is critical for administrators to know the current version of the database and any feature releases that were installed on the system. If the database is upgraded, the next backup that is run automatically detects the new version that was used during backup. This version is then refreshed in the instance Properties dialog box.