Backup and restore
You can run backup and restore operations on your system configuration in the IBM PureApplication System and PureApplication Software environments. You can run scheduled backups or run backups on demand, and restore backed up data as needed. This chapter provides guidance on backing up and restoring various types of data that are associated with PureApplication System and PureApplication Software. Specifically, the chapter outlines how to back up and restore component data and system data.
This chapter covers the following topics:
10.1 Data categories
When considering the backup of the PureApplication System, there are several data categories that must be taken into account. Figure 10-1 shows the different data categories that must be addressed in the backup and restore of the system and the workload.
Figure 10-1 PureApplication data categories
10.1.1 Management function data
PureApplication System management functions control the entire system, virtualizing the hardware into resources for the cloud environment and providing a runtime environment for the workload functions. These management functions contain setup and configuration data that must be backed up.
10.1.2 Cloud environment data
The cloud environment is defined by creating and configuring cloud components, that is, IP groups and cloud groups, as shown in Figure 10-2 on page 277. This configuration organizes the system's resources by runtime environments into which the workloads can be deployed.
Figure 10-2 IP and cloud groups
Cloud configuration data must be backed up separately from the system's management data. Creating cloud resources is described in Chapter 3, “IBM PureApplication installation” on page 41.
 
Note: A cloud group is made up of a logical group of compute nodes, where the virtual machines (VMs) of the pattern instances are deployed. By having multiple cloud groups, PureApplication System and PureApplication Software provide multi-tenancy and a level of isolation for different teams to deploy their patterns
Cloud groups contain one or more IP groups for assigning IP addresses to the VMs of deployed patterns. An IP group is a range of IP addresses that are either assigned to the VMs by the system or can be specified by the deployer. During the creation of IP groups, you provide the VLAN that is configured to connect to the external data center, the gateway, the netmask, and DNS. You then define a pool of IP addresses within the subnet (an IP group within a subnet) that is available to PureApplication System.
10.1.3 Workload catalog data
The workload catalog contains the individual workload components and assets that are shown in the PureApplication console under Catalog and Patterns. The catalog contains the following items:
•Virtual images
•Virtual application patterns and pattern types
•Plug-ins,
•Virtual System Patterns (VSPs)
•Script packages
•Add-ons
•Fixes
These pattern-level components do not include the deployed pattern instances, but rather the patterns and the assets that are needed to deploy these instances. The workload catalog also includes environment profiles, which are needed to deploy the patterns into the cloud environment.
10.1.4 Workload (pattern instance) data
Workload data is the deployed patterns instances, the contents of the running VMs, and their relationships. Workload data is a considerable portion of the data that is stored by PureApplication System and PureApplication Software. Workload data is voluminous because VMs are large and applications often load much data from their databases. Workload data can grow when applications maintain much session data when they have a many concurrent users.
When following standard middleware installation and application deployment practices, if the runtime environment is lost, re-creating it is difficult, time-consuming, and error-prone. Because of patterns In PureApplication System, workload data is fairly easy to replace, so backup and restore is not as important.
With PureApplication System and PureApplication Software, if an application environment fails, workload managers can easily replace it by redeploying the pattern and redeploying the application into the pattern instance. Therefore, on PureApplication System and PureApplication Software, workload data does not need to be backed up.
10.1.5 Application data
The internal state of each application running as a workload on the system must be backed up. The state is application-specific, and typically is the application's databases, but it can also be any application-specific state, such as the following ones:
•Application configuration
•Application file system
•Logs
•Other key application artifacts
This backup is the same kind of application backup that is needed for applications running in middleware on traditional hardware. The difference for a virtualized application running in PureApplication System and PureApplication Software is that the pattern must include the backup software or agent to back up application-specific data to external storage.
10.1.6 Data categories example
Figure 10-3 on page 279 illustrates a singular set of management data:
•A cloud environment that is divided into two cloud groups. (They contain other components, such as IP groups.)
•A workload catalog containing two patterns. (These patterns might be VSPs or virtual application patterns. They contain lower-level components, such as virtual images, script packages, and plug-ins.)
•Two patterns that are deployed as workloads, each deployed into a cloud group.
•Application data in each of the workloads.
If any or all of the data on the system is lost or corrupted, that loss can cause some or all of the system to not function correctly. The goal of the backup is to enable you to replace the flawed data, restoring it to its previous state, so that the affected parts of the system once again function correctly.
Figure 10-3 Data category example
10.2 Types of backups
PureApplication System and PureApplication Software provide robust backup and restore functions to back up the data to an external Secure Copy Protocol (SCP) server, and the ability to restore them from the backup server. Backup files can be encrypted and authentication can be a user ID and password or by using private key-based authentication.
There are two types of backups:
•System backup
This is a simple monolithic snapshot for restoring the entire system. It includes management, cloud environment, and some of the workload catalog data. Virtual images, workload instances, and application data are not included.
•Component backup
This type of backup stores some of the system and all the workload artifacts in individual files. It can be restored individually, copied, stored in source code control, and so on.
10.2.1 Required permissions for backup and restore
Users and groups with different role-based permissions have access to different resources in PureApplication System and PureApplication Software. Here is the list of roles and permissions that are needed to access backup and restore functions. The user must have all these permissions to perform backup and restore functions.
•Workload administration full permission
•Cloud group administration full permission
•Hardware administration full permission
•Security administration full permission
10.3 Configuring backup functions
This section describes how to set up and configure the backup function of PureApplication System and PureApplication Software.
Here are the high-level steps to activate the backup function for either a system or component backup. Subsequent sections describe the details of each of these steps.
1. One or more external backup servers (running Linux, AIX, or Windows) must be configured for Secure Shell (SSH) protocol capability to accept connections and transfer data from remote systems. The backup server must have enough storage to perform backups of system or components. The same backup server can be for used multiple backups in different directories and encryption options. For more information about the backup server requirement, see the PureApplication System IBM Knowledge Center at the following website:
2. From the PureApplication System backup and restore console, create one or more backup locations, pointing to the backup server that is defined in step 1.
3. From the PureApplication System backup and restore console, create one or more backup configurations by using the defined backup locations, type of backup (system or components), and the backup schedule.
10.3.1 Creating backup locations
The assumption in this section is you are creating a backup location for the first time. Later, backup locations can be changed or added as needed.
To create a backup location, complete the following steps:
1. Click Systems → Backup and Restore, and then click Setup.
2. The window to create a location opens. Click Create New.
3. Enter the following values:
a. Provide a meaningful name for the backup location.
b. Provide the host or IP address of the external backup server.
c. Provide the path where the data files are backed up. If the directory does not exist in the backup server, it is created.
d. Provide the user name to access the backup server. The user must have access to the path where the backup files are created.
e. The authentication type can be either a user ID and password or a private key. Based on the kind of authentication, provide either the password for the user, or add the private key with a maximum length of 8192 bits.
f. Optionally, enable encryption for the backup data. For system backup or component backup that includes security users and groups, encryption must be enabled. The encryption certificate, private key, and paraphrase can either be provided or the system can generate one. If encryption is enabled, another dialog box opens under the table for you to provide additional certificate and private key settings for your backup location:
i. Use existing private key and certificate.
ii. Generate new private key and certificate: When you select this option, you are prompted to enter a password (and enter it a second time for verification). The new certificate and private key are generated when you click Generate. The expiration date for this certificate is set automatically to 366 days from the date of creation.
iii. Upload your own private key and x509 compliant certificate.
iv. Renew expired certificate using existing key.
For this publication, two backup locations were created. Both backup locations point to the same server, but use different directories and encryption options:
1. Figure 10-4 shows the backup location that is called RedbooksBackupComponents with no encryption. This location is used for component backup.
Figure 10-4 Backup location with no encryption
2. Figure 10-5 shows the backup location that is called RedbooksBackupSystem with encryption enabled. This location is used for system backup. This option uses PureApplication to generate the certificate, and a key that is based on the paraphrase that is provided. To upload your own certificate and key, you can use the Upload your own private key and certificate option, as shown in figure Figure 10-6.
Figure 10-5 Backup location with encryption
Figure 10-6 Option to upload you own private key and certificate
After they are created, the backup locations should look Figure 10-7. From this window, you can edit or delete the location, and test the connection to the backup server.
Figure 10-7 List of backup locations
After backup locations are created, the next step is to create backup configurations pointing to the backup locations.
10.3.2 Creating backup configurations
To create a backup configuration, complete the following steps:
1. Click Systems → Backup and Restore.
2. Click Create New.
3. Enter the following values:
a. Provide a meaningful name for the backup configuration.
b. Choose any backup Location that is created.
c. Specify the type of the backup: system or component backup.
d. Specify the backup schedule either “on demand” or a fixed schedule. The fixed scheduled backup has a start date, backup time, daily or weekly schedule, and, optionally, an end date.
e. Optionally, you can select the users who are notified after the backup is complete. The PureApplication System “Mail delivery” SMTP server must be configured to enable the notification through email. The notification provides status information about complete or incomplete backup jobs.
10.3.3 Creating a component backup configuration
If component backup is selected, you can select several resources in the Workload, Cloud, and Security categories:
•Workload category:
 – Add-ons
 – Database images
 – Database patterns
 – DB2 fix packs
 – Emergency fixes
 – Pattern components
 – Pattern types
 – Script packages
 – System plug-ins
 – Virtual application patterns
 – Virtual application templates
 – Virtual images
 – Virtual system patterns
 – Virtual system patterns (Classic)
 – Virtual system templates
•Cloud category:
 – Cloud groups
 – Environment profiles
 – IP groups
 – Volume groups
 – Virtual appliances
•Security category (requires an encrypted backup location):
 – Users
 – User groups
For this publication, the following component backup was created by completing the following steps:
1. Click System → Backup and Restore.
2. Click Create New.
3. Create the component backup configuration that is named RedbooksBackupComponents. As different resources are selected, the backup data storage and estimated time changes. Your configuration should look similar to Figure 10-8.
Figure 10-8 Backup profile workload components
a. For the workload components, the Script packages, Virtual system patterns, and Virtual system patterns (Classic) are selected.
b. For the cloud components, which are shown in Figure 10-9, the cloud groups, environment profiles, IP groups, and one storage volume group containing some storage volumes are selected. The backup of the storage volume in the volume group allows the backup of the storage data on the external server.
Figure 10-9 Backup profile - cloud components
c. The backup schedule is set to on demand.
d. Enable the backup by clicking Backup disabled.
10.3.4 Creating a system backup configuration
For this publication, the following backup configuration was created by using an encrypted backup location and completing the following steps:
1. Click System → Backup and Restore.
2. Click Create New.
3. Create the system backup configuration Redbooks BackupProfile System, as shown in Figure 10-10.
Figure 10-10 Backup profile - system
4. The location RedbooksBackupSystem is selected for system backup. The location must be encrypted for system backup.
5. A fixed schedule of every Wednesday and Friday at 12:15 am was configured with a start and end date.
10.4 Performing backups
After the backup resources (locations and configurations) are defined, both backup configurations are enabled and active, and can back up the resources based on the schedule. Figure 10-11 shows the backup configurations that are enabled in PureApplication System.
Figure 10-11 List of backup configurations
The backups that are configured to run at a scheduled time are started automatically by PureApplication System.
You can also perform on-demand backups simply by selecting the backup configuration and clicking Backup now, as shown in Figure 10-12. The backup job is created and progress is shown on the console.
Figure 10-12 Immediate backup option
10.4.1 Performing a system backup
When backing up system data, the first backup provides the baseline backup data and the subsequent backups are delta backups. The subsequent backups store only the changes to the system configuration since the last baseline backup. The backup process automatically runs either the baseline or delta backups based on the data on the backup server. Over time, the delta backup size increases because it is the delta against the last baseline, and not the last delta backup. At that time, a new baseline can be created.
A system backup to a new location creates a baseline backup.
The system backup process runs in three jobs:
1. Backup 1 of 3: This job initiates the backup process and queues the second of the three jobs to start.
2. Backup 2 of 3: This job prepares the data for backup. To ensure a consistent copy of management databases and other artifacts, new tasks are blocked or placed in a pending state while this job runs. This job might run for 10 - 15 minutes based on the resources on the rack. After all target data is defined, the third job starts.
3. Backup 3 of 3: This job compresses, encrypts, and transfers the target data to the specified remote backup system. This job is not a blocking job and other changes to the console are allowed during this stage.
While the system backup is performed, you can monitor the progress of the backup from the console, as shown in Figure 10-13.
Figure 10-13 Monitor the backup job progress
System-level backup directory structure
System-level data is backed up to the backup server and organized in a unique directory structure. The general directory structure for system level backup data is shown in the following sections.
System-level data that is associated with internal IBM Workload Deployer functions
The system-level data that is associated with internal IBM Workload Deployer functions is found in the following location:
/<backup_location_path>/<rack_ID>/<iwd-version number like 5.1.0.1>/backupStorage/<iwd_artifact>/<timestamp>
<iwd-artifact> represents several artifacts.
PureSystems Manager data
The PureSystems Manager (PSM) data is found in the following location:
/<backup_location_path>/<rack_ID>/backupStorage/<timestamp>
The <timestamp> folder contains full baseline system-level backups of PSM for each backup operation in several directories (databases, key, IBM Tivoli Provisioning Manager, and Storwize V7000 storage system).
Pattern type data
The pattern type data is found in the following location:
/<backup_location_path>/<rack_ID>/backupStorage/ptype/<ptype_name>/<timestamp>
Subdirectories in this directory represent folders for each pattern type.
Volume group data
Volume group data is found in the following location:
/<backup_location_path>/<rack_ID>/backupStorage/volumegroup/<timestamp>
All time stamps are in milliseconds. The details for the file system and how to convert the time stamp into a readable string is available in the PureApplication System IBM Knowledge Center at the following website:
10.4.2 Performing a component backup
The first time components are backed up, a baseline is created for all the resources that are selected for component backup. For subsequent component backups, only changes are added to the backup. Component backups are Automated Component Export operations. A component backup is a single job that is non-blocking, as shown in Figure 10-14.
Figure 10-14 Component backup job
While the component backup is performed, you can monitor the progress of the backup from the console, as shown in Figure 10-15 on page 289.
Figure 10-15 Component backup job progress
On the backup server, each type of component resource has its own directory within the specified backup file system. Storage volumes that are contained in the storage volume group that are selected for backup are backed up with compression.
Some examples of directories for component resources on the backup server are shown in Figure 10-16. This example is based on the components that are selected for this publication’s scenario for the component backup in Figure 10-8 on page 284.
Figure 10-16 Component backup directories
Component-level backup directory structure
Component-level data is backed up to the backup server and organized in a unique directory structure. Here is the general directory structure for component backup data:
/<backup_location_path>/<rack_ID>/backupStorage/<comp_type>/<internal_ID>/<timestamp>
The <comp_type> is the component resource being backed up, such as an add-on, script packages, and vsyspatterns.
The <internal_ID> is a simple integer value that is assigned sequentially as new components are defined
10.4.3 Viewing the backup history
From the Backup and Restore console, you can view the history of all the backups for each backup configuration. Figure 10-17 shows the Redbooks BackupProfile System configuration.
Figure 10-17 View Backups
If you click View History, the results of the system backup history are shown in Figure 10-18. The delta backup is smaller and faster than the earlier baseline backup (dated July 27 in the figure).
Figure 10-18 History of system backups
Similarly, Figure 10-19 shows the history of the component backup of Redbooks BackupProfile Components. In this example, the oldest backup has data. Subsequent backups have no data (size 0) because no changes were made to the components being backed up.
Figure 10-19 History of component backups
Preferred practices for backing up data
This section lists some preferred practices for backing up system and component data.
System backups
Here are some preferred practices for system backups:
•Run backups regularly, either daily or few times a week. The first backup takes longer, but subsequent delta backups run quickly.
•Once a week, archive a new baseline and delete some of the older ones. Over time, the delta backup size increases because it is the delta against the last baseline, and not the last delta backup. At that time, create a new baseline. As the time duration for the delta operations get close to the baseline backup, this is another indication that you should create a new baseline.
Component backups
Here are some preferred practices for component backups:
•Run backups on a regular schedule or on demand as needed. Component-level data is backed up only if there are changes since the previous backup.
•Over time, perform general archiving and pruning tasks on the backup server to delete data that is no longer needed and free up additional storage. The backed up data can be archived on a tape or other backup solutions such as SAN. Ensure that encryption keys for archived backups are stored safely and are not lost.
10.5 Restoring backup data
After system and component data is backed up to the backup server location, it can be restored from the console. Figure 10-20 shows the restore section of the console. The list of backup locations that have backed up data is visible in the table. For this example, the RedbooksBackupSystem and RedbooksBackupComponents locations are available. If there were backup locations but no data that is backed up to those locations, they do not appear in the Restore location table. Along with the location, the size of the data and the availability status is shown. You may also set an alternative location.
Figure 10-20 Restore location table
From the restore table view, you can select the location from where the backup data is to be restored, as shown in Figure 10-21. Click Restore Data.
Figure 10-21 Restore location
The Restore Configuration window for the selected backup location opens, as shown in Figure 10-22.
Figure 10-22 Restore configuration
10.5.1 Restoring system data
System restore is used for critical issues, such as internal PSM database corruption, loss of both PSMs, and other unrecoverable conditions. System restore is not to be used lightly. This function is used for disaster situations where the complete system must be restored from the backed up data.
Only authorized IBM Support representatives can and should perform system-level restore operations. If you must perform the restore yourself, do so only under the guidance of IBM Support. Contact IBM Support for assistance in restoring system-level data. The IBM representative can back up from the baseline system backup or from any delta backup (which also includes the baseline backup). During the backup, the PSM is offline.
Figure 10-23 on page 293 shows the system restore window.
Figure 10-23 Restore system configuration window
10.5.2 Restoring component data
You can select a backup location that has component data to restore all or a subset of components that are backed up, which allows a much granular restore of the component resources.
To restore the example components in this publication, complete the following steps:
1. Click System → Backup and Restore.
2. Select the RedbooksBackupComponents location (where component resources are backed up). Restore Configuration - RedbooksBackupComponents is displayed.
3. Select Component Restore. All the components that can be restored are shown, as shown in Figure 10-24.
Figure 10-24 Restore components
4. From this window, you can select the components to be restored.
You can use the restore function to display all or only new or changed component resources from what is in the PureApplication System. Figure 10-25 shows the list of component resources that are in the backup, but either changed or new to the rack. Component backups are Automated Component Export operations. Virtual Images and Virtual Appliances create additional jobs to perform the OVA or Image import operations, and appear as additional jobs in the job queue.
Figure 10-25 List of component resources for restore
Click Restore to start the restore. Progress can be monitored in the job queue, as shown in Figure 10-26. If the restore selection includes a storage volume group that has storage volumes, those volumes are restored. This function provides another option of backing up the storage and restoring it at a later point.
Figure 10-26 Monitor the restore progress
10.5.3 Alternative backup locations to restore component data
There might be situations where you must restore data from an alternative backup location that is another PureApplication System. It is also possible that you do not have a component backup location that is defined for the PureApplication System, but defined a location for another rack from where you want to restore the component data. It is valuable to have the ability to restore components from an alternative backup location belonging to another PureApplication System. This capability can be used to copy components from one system to another, especially in disaster recovery (DR) scenarios where the same pattern and assets might be needed in the DR system.
You can use PureApplication System restore to set an alternative backup location by clicking Set alternate location in the Restore section of the Backup and Restore console. In addition to the settings to create a backup location, you need the serial number of the alternative rack (which can be obtained from the console Hardware Infrastructure Map view). Figure 10-27 shows the fields for the alternative backup location called Redbooks-AlternateLocation.
Figure 10-27 Example of an alternative backup location
After the alternative backup location is set, it is visible in the Restore table upon refresh, as shown in Figure 10-28.
Figure 10-28 Restore from an alternative backup location
To restore all or selected components from another rack to this rack, complete the following steps:
1. Select the Redbooks-AlternateLocation.
2. Click Restore data
10.5.4 Troubleshooting
Backup tasks create jobs that can be viewed in the Event console. Event jobs start with a text string of “CWZIP95”. Using this string as a search filter provides a way to look at the events that are associated with backup jobs.
Failed backup or restore jobs automatically trigger the Backup and Restore Log Collection Set. You can view them in the System troubleshooting. You can download the log collection from the System Console, and upload it into the Problem Management Record (PMR).
10.6 Backing up and restoring by using the CLI or REST API
Although the backup and restore function that is provided by PureApplication System should be the primary way of backing and restoring components, there is a rich set of CLI and REST API that can be used to selectively back up and restore resources within PureApplication System.
Chapter 12, “Service and Support Manager” on page 333 provides the basics of developing scripts by using these APIs.
There are some scripts that are available in the samples directory of the CLI tool. You can write custom scripts to perform the backup and restore.
10.7 Backup instances and application data
PureApplication System does not back up deployed instances. There is a mechanism to create one snapshot of the deployed instance from the instance console, which makes a copy (snapshot) of all the VMs in the instance. For example, if a WebSphere Application Server cell had a Deployment Manager, one HTTP Server, and two custom nodes with a total of four VMs, the snapshot makes a copy of all four VMs. Later, the snapshot can be restored.
There is no built-in continuous backup function of the instance or any application data within the VM. This task is the responsibility of the client. Most existing backups or continuous backups of the application data can be reused. If there are agents that provide those functions, those agents can be added into the pattern, so the VMs have the agents that can interact with the backup system that is used within the data center.
Here are some examples of application-specific data:
•Database
•Log files
•Transaction logs
•Configuration files, which might not be needed if the configuration of the middleware is automated
Solutions such as IBM Tivoli Storage Manager or other third-party backup solutions can be adopted. PureApplication System provides a Tivoli Storage Manager plug-in for database backups to an external Tivoli Storage Manager server. After it is configured, the backup of the database can be scheduled.
You can use IBM Endpoint Manager to inject backup agents, such as Tivoli Storage Manager agent fixlets, in VMs. Figure 10-29 shows a high-level diagram of using IBM Endpoint Manager to inject agents. Alternatively, agents can be part of the pattern so that they are added to the deployed VMs.
Figure 10-29 Use IBM Endpoint Manager to inject agents
 
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset