System i5 backup: Brushing up on BRMS

Backup and recovery expert Ken Graap is a big fan of the IBM backup Recovery and Media Services (BRMS) product. According to Ken, BRMS has proven to be a robust and complete software solution for backing up and recovering the AS/400, iSeries and i5 systems he's managed over the years. "For each backup/recovery design challenge I've had, BRMS has provided a way to implement a solution."

This Content Component encountered an error

Ken Graap

I have always been a big fan of the IBM backup Recovery and Media Services (BRMS) product. It has proven to be a robust and complete software solution for backing up and recovering the AS/400, iSeries and i5 systems I have managed over the years. For each backup/recovery design challenge I've had, BRMS has provided a way to implement a solution.

BRMS has been perceived by some to be complicated to use. I prefer to view it as a full-featured product with solutions for just about any backup scenario you can think of. Implementing BRMS doesn't have to be complicated, though. Just use the features you need now and learn the rest, as you need to solve other backup/recovery problems. Over time you will become an expert. You don't need to learn it all at once.

I'd like to spend some time describing how I have used BRMS to backup my company's i5/550 system.

First of all, BRMS can be managed via two interfaces -- Traditional Green Screen and through iSeries Navigator. I use the green screen interface, therefore that's what I will be describing.

System overview:

Our i5 system hosts several critical applications, including our Customer Information System (CIS), Gas Operations (NGO) and financials (Lawson) -- this is all done on one system. Therefore, the system hosts both development and production environments in a single LPAR. Since I have only one system, I have designed the backup process to minimize the time this system is unavailable to users. BRMS provides a great way to do this, also.

Release: V5R3
Main Storage: 32GB
Disk: 50 - 70GB 4327
ASP1: System & Production data (2,258GB 45.5% utilized)
ASP2: Journal Receivers (211,695MB 60-90% utilized)
ASP3: Development data (493,955MB 67.6% utilized)
Tape: 3 – 3590 E11

Setting up a Media Pool:

Tape Drive → Media Class → Media Pool (Tapes)

Before you can do anything you will need to prepare some media (tapes) by adding them to a BRMS Media Pool. The Media Pool I have created contains approximately 450 tapes. Each tape has a unique six character Volume Serial Number. These tapes were added to a Media Pool using the ADDMEDBRM command. This command lets BRMS know what media it has to work with. As tapes are added, they are initialized with a Volume Serial Number and associated with a Media Class. The Media Class is used to associate a tape with a particular type of tape drive. A Media Class is created by BRMS when you initially install the product or add a new tape drive to the system. Since I only use 3590-E11 tape drives, I only require one Media Class. I have named this class, FMT3590E. I also let BRMS manage where data is store on individual tapes. This is a GREAT feature of the product, which could be compared to the Single Level Storage feature that OS/400 uses to store data on disk drives. I don't care which tapes are used for what. I can just use BRMS commands to tell me which tapes are available for use and make sure these tapes are mounted in my tape drives before a backup process is run. And when I need to recover something, BRMS tells me which tapes to mount.

BRMS Policy Overview (Short Version):

BRMS is configured using hieratical policies containing default values. Some of these policy values can also be overridden in lower level policies and during backup execution. If carefully configured, the hieratical nature of policies makes it easy to change backup default values without having to change multiple policies and individual backup control groups.

There is a System Policy, Backup Policy, Archive Policy, Recovery Policy, Retrieve Policy, Migration Policy along with multiple Media Policies and Move Policies. See, it is already starting to get complicated isn't it? Don't worry though. All you need to be concerned with right now are the policies used for creating a backup using tape media!

Policies and control groups are related like this…

The first policies you need to define are Move Policies. These policies determine how your backup media will eventually be rotated to an offsite storage facility.

I have defined several Move Policies:

Daily: Schedule media using this policy to be sent offsite for 8 days
Full: Schedule media using this policy to be sent offsite for 14 days
Monthly: Schedule media using this policy to be sent offsite for 14 days
Sysave: Schedule media using this policy to be sent offsite for 62 days

You can also define calendars for a Move Policy -- indicating what days you want to move tape on and what days are considered working days. I kept it easy and just specified that everyday is a working day and that media could be moved offsite Monday through Friday.

Next we need to define some Media Policies. These policies associate media from your Media Pool with a Move Policy and a Media Class.

Note: Notice the names I used. For clarity my Move and Media Policies have the same names. They don't have to, though.

I have defined several Media Policies:

Daily:
Data on this media will be retained for 14 days…
This media will be moved as defined in the DAILY Move Policy…
Use media as defined in the System Policy Media Class…

Full: Data on this media will be retained for 35 days…
This media will be moved as defined in the FULL Move Policy…
Use media as defined in the System Policy Media Class…

Monthly: Data on this media will be retained for 365 days…
This media will be moved as defined in the MONTHLY Move Policy…
Use media as defined in the System Policy Media Class…

Sysave: Data on this media will be retained for 396 days…
This media will be moved as defined in the SYSAVE Move Policy…
Use media as defined in the System Policy Media Class…

Next we need to define the System Policy. The System Policy contains several default values that are used throughout BRMS. Here are a few of the important values:

The rest of the System Policy is used to define things like; Do you want to sign off interactive users whenever a backup runs? What output queue do you want BRMS reports to be spooled to? Etc.

Note: These are just 'defaults'. Many of these values can be overridden at a lower policy level, in a Backup Control Group at execution time.

Now we need to define the Backup Policy. The Backup Policy contains the default values that are used within Backup Control Groups.

The rest of the Backup Policy is used to define the default actions that are taken when a Backup Control Group is executed. Things like, how should a backup be run, as a Full backup or an Incremental backup? What kind of incremental backup should be performed? Should I save journaled files when saving changed objects? Should I save access paths? Should I pre-check objects prior to a backup? Append to media? What should I do when I reach the end of a tape? Etc.

Note: When setting up these policies use the F1 key to get more information on what the parameter values mean.

Backup Control Groups (Short version):

Now that all of the preliminary setup is done, let's talk about the real guts of BRMS, the Backup Control Group. IBM defines these as:

…groups of libraries, special values and lists that share common backup characteristics.

This is where you really start defining how your backup will execute. One of the most powerful special values is the *EXIT option. Using this option allows you to execute just about any OS/400 command. Which gives you full control over what your backup can do.

I don't have the time to go into how each and every Backup Control Group I use is defined and your implementation would vary greatly depending on your system configuration anyway. However, I will detail the control groups used to do a monthly SAVSYS process and a daily Save While Active backup of one of our production applications.

A Backup Control Group can be created from the BRMBKUPLN (Backup Planning) menu, Option 2, Work with backup control groups. To get to this menu enter:

GO BRMBKUPLN

Use Option 1 to create a control group. For example, MYBACKUP

Entries in a Backup Control Group consist of "Backup Items". Backup Items consist of Library Names, Special Values and List Names.

Some examples of Special Values are:

*QHST - save history information
*SAVCFG - saves configurations
*SAVSECDTA - save security data
*SAVSYS - save the operating system

Note: Special Values always begin with an " * " … Use F1 to see a complete list.

IBM describes Lists as:

…groups of objects, folders, spooled files or file systems that are grouped together for processing in a Backup Control Group. You assign each list a unique name. The named group of items can be added as a backup item in a control group for processing. Lists can be one of the following types:

Folder - *FLR
Object - *OBJ
Spooled file - *SPL
File system - *LNK

The Backup control Group I use monthly to save the system is executed from the system console while in a restrictive state.

Within BRMS you can display a control group in two ways. The default is to show all the Backup Items along with the major attributes associated with them. If you use the F11 key, you will see the second view. This view shows the command associated with each *EXIT Backup Item.

Option 8 (Change Attributes) from the Work with Backup Control Groups menu will let you view and change the attributes of a control group. This is where you can override the defaults defined in the Backup and System Policies. In this example you will notice I have assigned a specific Media Policy and tape drive to be used and indicated that after this control group runs, to leave the tape mounted.

The attributes for my monthly system save control group look like this:

Here is the default view of my monthly system save control group.

Here is the *EXIT view of the same Backup control Group:

Sequence 50 and 100 are examples of Lists. You use the WRKLBRM command to work with lists.

The QFPNWSSTG list is a *LNK list used to perform a full backup of my Network Server Storage, which is part of the IFS:

The list defined at sequence 100 is another *LNK list that defines several IFS directories I want to save at this point in my backup process.

Sequence 150 and 240 are examples of using BRMS Special Values.

The special value *IBM saves all system (IBM) libraries. Refer to the Special Values table for the Save Library (SAVLIB) Command in the Saving Libraries section of the iSeries Backup and Recovery book for a list of libraries included and excluded when using this special value.

*SAVSYS is included in the backup items list in a control group. When *SAVSYS is included in the list, the backup operation must be started (STRBKUBRM) from the console, the user sign on being used must be excluded from sign off in the system policy and the backup system must be in an interactive method of operation. The Save System (*SAVSYS) special value saves a copy of the QSYS library in a format compatible with the installation process. It does not save objects from any other library. The *SAVSYS special value saves all object types shown on the Object types field (OBJTYPE parameter) in the Save Object (SAVOBJ) command. In addition, it saves security and configuration objects.

Sequences 160 – 200 are example of specifying individual libraries to be backed up.

Sequence 210 and 220 are examples of how you can backup libraries generically.

You can also specify what levels of save detail you want BRMS to collect when it executes a sequence entry in a control group:

*ERR Objects that were not saved due to an error condition are identified. The message identifier that gives the reason why the object was not saved is kept. If you specify *ERR for a DLO type of object, the error message BRM1813 is issued which indicates that the only valid entries for DLO saves are *NO and *YES. If you specify any other value for DLO saves, BRMS changes the value for Retain object detail to *YES.

*NO Do not keep object detail for an entry in the backup items list. You can retrieve at the library level from the backup history.

*YES Save object details for an entry in the backup items list. This allows object retrieval from the backup history.

Note: Note that when you specify *YES, member level details are kept for physical files in addition to object detail.

*OBJ Object detail is kept in the BRMS backup history. No member level detail is kept.

*MBR Object detail is kept in the BRMS backup history.

Note: Member level information is included in the object detail for physical files.

Note: This choice is the same as *YES.

The *EXIT Special Values are used to execute programs and commands that are outside of the regular BRMS process.

In my example control Group listed above, sequence 10 calls a CL program I wrote that goes through all the steps necessary to bring the system into a restrictive state gracefully. After this program runs, control is returned to BRMS and the next sequence is executed.

Sequence 20 sends a message to the console and sequence 40 reorganizes a database that can only be allocated when the system is restricted. This is a good example of how you can include important housekeeping processes in your backup procedure.

Sequences 60 – 140 show you how I included some commands to collect additional data before and after executing a backup defined by a List named IFS2.

Sequence 250 brings me backup out of a restrictive state and sequences 260 – 360 starts QBATCH, submits the next job in my backup process and finally collects job log and PTF information.

Here is another Backup Control Group I use. This one is the default view of the monthly Production Customer Information System (CIS) application backup.

In this example you will notice I have assigned a specific Media Policy and tape drive to be used and indicated that after this control group runs, to leave the tape mounted. I have also specified that data from another backup can be appended to this tape.

The attributes for my monthly CIS application backup control group look like this:

Here is the default view of the monthly Production Customer Information System (CIS) application backup control group:

Here is the *EXIT view of the same Backup control Group:

This control group shows you how to implement a Save-While-Active save.

Sequence 10 is another List. The List CIS_IFS defines a group of IFS directories that are part of this application. I like to backup everything that is needed for a particular application at the same time to limit how long the application is unavailable to users. Sequence 20 uses the *EXIT Special Value to execute the MONSWABRM command. This is the command that begins a SAVE-While-Active process.

The Monitor Save While Active (MONSWABRM) command reviews the Save-While-Active message queue and looks for the message indicating the end of library synchronization. When synchronization is detected, you can issue a command to the system.

The MONSWABRM command can be used as an exit (*EXIT) special value in a control group during backup processing.

I have chosen to run a Save-While-Active process know as *SYNCLIB. This type of Save-While-Active insures that:

Objects in a library can be saved while they are in use by another job. All of the objects and all of the libraries in the save operation reach a checkpoint together and are saved in a consistent state in relationship to each other.

The libraries I wish to include in this save are defined on sequences 30 – 140. For this group of libraries I have also specified that the SWA Message Queue is SAVWACTCIS. This is the message queue that the MONSWABRM process monitors.

When the Save-While-Active process reaches a checkpoint, the save process begins and the MONSWABRM command can then optionally execute a command. The command I execute in my example is STRSYSCIS. This command is a CL program that starts up all the system resources required for a user to use the Production CIS System.

Using BRMS to execute a Save-While-Active save is that easy!

The remaining sequences (150 – 330) define additional libraries that are part of this application that can be saved while the application is in use. I only include what is absolutely necessary in my Save-While-Active saves because it does take time to reach a checkpoint and I want the downtime for this application to be a short as possible.

Summary:

Well that's it! I've hopefully provided you with enough information to dive right in and begin using BRMS. There is a lot more to the product that I have described here though. After all, as I stated earlier, it is a full-featured backup recovery system. For additional information you can visit the IBM Information Center site or browse through the following backup recovery manuals:

Backup Recovery and Media Services for OS/400: A Practical Approach and/or Backup and Recovery V5R3 (SC41-5304-07)

Good Luck …

If you have specific questions about this topic, email me. All email messages will be answered.

-----------------------------------
About the author: Kenneth Graap has worked in the IBM S/38 -- AS/400 -- System i arena since 1984. His most recent position is that of senior IBM System i administrator at Northwest Natural in Portland, Ore. He has extensive experience in all aspects of System i management. That includes proactive performance tuning, system software upgrades and maintenance, hardware upgrade planning, backup/recovery procedures and system security configuration. Kenneth has implemented solutions using several IBM System i management tools including, BRMS/400 (Backup Recovery), IJS/400 (Job Scheduling) and is a big fan of iSeries Navigator.

This was first published in October 2006

Dig deeper on Data backup, storage and retrieval on iSeries

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchEnterpriseLinux

SearchDataCenter

Close