IBM PureApplication System does not currently allow a full backup of all the storage on the system. Instead, what it does is permit a back up of the system configuration of PureApplication System that would enable a system to be reconstructed in the case of a total PSM failure. In addition, the system can optionally also back up the virtual system images. We currently recommend that you allocate about 160 GB of storage to cover the system db files and user images, although this figure could change over time as you create new custom images and obtain new patterns. This system and image backup is currently implemented through SSH copies, and is done incrementally, where only deltas are recorded after the first full system backup.
Since PureApplication System does not allow a full backup of all storage, users of PureApplication System have to be more selective about what other parts of the user storage (besides the system configuration above) is backed up. Remember that PureApplication System essentially runs system workloads that consist of instances of patterns that are composed of virtual images, plus the deployable artifacts (application code, such as JARs, WARs, and EARs) that are deployed into those pattern instances. Given the automation that is either built into the system or that we recommend be added onto the system, what we contend is that the pattern instances can be entirely recreated from the patterns and the deployment automation at any time. Thus, the only information that can't be easily reconstructed would be user-specific data, such as database contents or the contents of specific files that hold user data. Thus, those are the only parts of the remaining data that need to be backed up.
So, what we recommend is that any database that is stored on PureApplication System have an IBM Tivoli® Storage Manager agent configured on it so that it can be backed up onto a Tivoli Storage Manager infrastructure. This is something that is already preconfigured in the Database as a Service (DBAAS) images. For other IBM DB2® images (for example, the built-in DB2HADR images) you have to write a simple script package to install and configure the Tivoli Storage Manager agent to point to the location of your existing Tivoli Storage Manager servers.
The overall configuration of these two backup types is shown in Figure 1.
Figure 1. SSH system backup and Tivoli Storage Manager database backup
In this diagram, the same box is shown at two different points in time. On the left is the backup sequence. A shows a DB2 backup to a Tivoli Storage Manager server through a standard Tivoli Storage Manager schedule, while B shows a scheduled backup of the system configuration and virtualsSystem images through SSH. If a problem with the entire box occurs, necessitating a restore of the system and images, then line C shows how that would be carried out. D and E show the sequence for restoring a single database instance that has become bad or corrupted.
Database as a Service
As mentioned above, DBAAS patterns already include the Tivoli Storage Manager agent as part of their system configurations. In order to configure the connection to a Tivoli Storage Manager server for the DBAAS patterns within a PureApplication System, click Cloud > System Plug-ins and then select tsm from the pane on the left side. Click the Configure icon. Fill the values to the entries. This is shown in Figure 2.
Figure 2. Tivoli Storage Manager configuration for DBAAS
Configuring a virtual system instance of DB2 HADR
As described above, you need to provide a script package that executes as part of the setup of DB2 HADR in order to connect the Tivoli Storage Manager agent to an existing Tivoli Storage Manager infrastructure. The Tivoli Storage Manager client is not pre-installed for any of the DB2 vSys patterns on PureApplication System. However, the process for installing the Tivoli Storage Manager client on a VM in PureApplication System is very simple and quick, and the client software is free for users to download (see Resources.
The steps for installing the Tivoli Storage Manager client on a Linux x86 64bit machine can be found in the Information Center.
This script will need to be included with each DB2 HADR VSys pattern. One point to be careful of is that each specific DB2 or other product VM (or "node" in Tivoli Storage Manager parlance) that is being backed up needs to be registered with the Tivoli Storage Manager server individually using the dsmadmc tool.
A best practice for Tivoli Storage Manager traffic
One standard best practice that needs to be implemented when you are using Tivoli Storage Manager to back up databases running on PureApplication System is that the Tivoli Storage Manager traffic needs to be routed over its own VLAN so that the backup traffic does not interact with or affect the standard incoming and outgoing data network and impact the overall performance of your system. In PureApplication System virtual systems, this is achieved through a two-step process.
- You need to add a new network port, VLAN, and IP address range that are going to be reserved for backup traffic from Tivoli Storage Manager. Your Tivoli Storage Manager servers would be present on the subnet corresponding to these IP addresses and you would externally set up whatever routing is needed to allow this connection. Configuring this on PureApplication System is done through adding a new port and VLAN mapping and then creating a new IP Group in PureApplication System for that VLAN.
- You then need to use the "add NIC" add-on to create a new virtual NIC (network interface card) for the virtual images (see Resources). Creating that NIC will allow you, at deployment time, to assign the second network interface (usually eth1) to the specialized backup IP group you defined in the previous step. At this point, the Tivoli Storage Manager client should be able to see the Tivoli Storage Manager server which is on the subnet defined by the IP address range specified in step 1.
(This configuration is not currently permitted for DBAAS.)
Who performs the database restore
Once a database has been backed up using Tivoli Storage Manager, then the process of performing a restore is the normal business-as-usual process that would normally be followed for any standard Tivoli Storage Manager restore. The database administrator would gain access to the particular database instance running within a PureApplication System pattern and follow the normal DB2 restore procedures. PureApplication System does not affect or change this process in any way.
Setting up system and image backups
Creating a scheduled system backup process for the system configuration and virtual image library is a simple five-step process in PureApplication System. This only needs to happen once to configure the connections and establish the schedule. Because this is done for the system as a whole, this would be a task performed by the PureApplication system administrator. Be aware that, currently, system restores require an IBM system engineer to perform the system restoration process because it requires special access to lower-level consoles that are not exposed to the PureApplication System customer. As such, we will not cover that process here.
- Backup begins by first establishing a connection to an SSH server to store your certificate and private key used to encrypt the backup (Figure 3). We recommend that the certificate and private key be stored on a location other than the location that will be used for backup.
Figure 3. Store your certificate and private key
- Next, you specify a set of information that describes which private key and certificates to use — either generating new ones, or using pre-existing ones uploaded from another location (Figure 4).
Figure 4. Specify certificate and private key usage
- Set up the connection to the location that is running the SSH server that the system configuration will be backed up to (Figure 5).
Figure 5. Configure backup storage
- Optionally, you can select if virtual images should be exported along with the system configuration. We recommend that this checkbox always be checked (Figure 6).
Figure 6. Component specific backup
- Finally, set up the schedule for performing the backup (Figure 7). When the backup operation runs, there is a short administrative outage during which all new deployments will be blocked. This blocking time is very short, only about 5-10 minutes. Be aware that all existing workloads will continue to function during this time, but this does restrict new workloads from being deployed while the backup is being taken.
Figure 7. Perform backup
At this time, PureApplication System does not allow the SSH traffic for the configuration and image backup to be specially routed through its own IP group. However, after the initial backup, incremental backups are very short and should not result in much network traffic.
This article examined the capabilities of IBM PureApplication System V1.1 for backup and restore. Because this is an important part of business continuity, understanding the capabilities of the system are critical to help you make the right decisions for your applications.
The author thanks Ashok Iyengar and Maria Schwenger for all their help and contributions in testing out Tivoli Storage Manager database backups for PureApplication System, Sung-Ik Son from IBM Software Services for WebSphere for reviewing this article, and Rohit Singh from IBM PureApplication System Development for his help with explaining the backup changes in V1.1.
- Organizational Structure in PureApplication System Operations
- IBM Tivoli Storage Manager for Linux: Administrator's Reference
- Managing Application Runtime Environments in IBM PureApplication System
- IBM Education Assistant:Using Virtual System Add-ons
- IBM Tivoli Storage Manager Information Center: Installing the Tivoli Storage Manager Linux x86_64 client
- Video: Kyle Brown: IBM PureApplication System Innovations for Business Continuity
- IBM developerWorks WebSphere