Recovery scenarios
After following the recommended best practices of performing the backup tasks on a regular basis, you are prepared for several recovery scenarios if and when any should occur.
There are a number of different problem scenarios that can occur with your system. These scenarios can be resolved by using the backups that were made when following the recommended best practices. Consider the following examples, presented in order from least catastrophic to most catastrophic.
Be sure to periodically test these backup and recovery procedures to ensure that they actually work if and when needed.
Restoring application data
In this scenario, the system and workloads are available, but the application resources are corrupted.
To address this problem, use the same program that was used to make the file system or application database backup to restore the backup.
For example, suppose that you back up an application database including schema and data. Later, while the pattern instance is running properly but the application is not because the data in the database is corrupted, you can restore the database to make the application start running correctly again.
Restoring workloads selectively
In this scenario, the workload components are intact, but a workload has become corrupted.
To address this problem, delete the workload, redeploy the pattern, and restore its application data backup.
For example, suppose that a server (such as those in a WebSphere® Application Server cell or a DB2® instance) fails to run properly due to an emergency fix that failed to be applied successfully. In this case you can redeploy the pattern. The new pattern instance contains a new set of servers. Then restore the application data.
Restoring system or workload components selectively
In this scenario, the system is functional, but system or workload components are corrupted.
- Use the CLI or API to delete the components and import their backup.
- Use the system restore functionality to import workload components that were included with the system backup.
For example, suppose you back up all of the custom patterns. Later, when a pattern developer changes a pattern that causes a problem, or a pattern administrator deletes a pattern that is still needed, you can restore the pattern from the backup.
Recovering when the Platform System Manager (PSM) fails
- Remove the management IP address from your old PSM node or delete the old PSM virtual machine to ensure that no duplicate IP addresses exist.
- Build a new PSM with the same management IP address previously used. Important: This is critical to reconnecting to existing workloads.
- Install Cloud Pak System Software for Power® on the new PSM at the identical level previously used. Include the identical installation name and admin user name specified in the installer. This is essential to the restore process working properly.
- Once installation is complete, follow the steps in Restoring system level data to restore the system.
Recovering your environment from a full system backup
- Remove the management IP address from your old PSM node or delete the old PSM virtual machine to ensure that no duplicate IP addresses exist.
- Build a new PSM with the same management IP address previously used. Important: This is critical to reconnecting to existing workloads.
- Install Cloud Pak System Software for Power on the new PSM at the identical level previously used. Include the identical installation name and admin user name specified in the installer. This is essential to the restore process working properly.
- Once installation is complete, follow the steps in Restoring system level data to restore the system.
Copying configurations from one Cloud Pak System Software for Power to another
This is a related scenario to back up and recovery that is commonly requested. In this scenario, you want to set up two or more Cloud Pak System Software for Power instances with the same configurations.
- Ensure that both instances have comparable system configurations. This includes system software version, system and network settings, user and user group definitions, hardware capacities, and so on.
- Use scripts to configure a comparable cloud environment.
- Import or restore the workload components that were exported from the other system.
- Use the imported patterns to deploy comparable workloads, and then restore any necessary application data from those backups.
For example, suppose a workload administrator develops a pattern on one instance, and now wants to deploy it on another instance as well. After ensuring that both instances are compatible, the administrator exports the pattern from the first instance and then imports it into the second instance.