|
Omit IFS directories and files from your *LINK saves
You can use the QLNKOMT user-modifiable backup link list to always omit any IFS directories or files that you do not want included in a *LINK save (for example, the directories that you use for virtual tapes). Just add those directory or file omits to the BRMS-provided QLNKOMT list.
Installation time for BRMS
If the size of the QUSRBRM library on your server is large, you could experience long installation times when upgrading BRMS to a newer release. This is due to the conversion of the physical files in the QUSRBRM library to a new file format. The benefits of this conversion are:
- More storage available on your system
- Shorter save times when saving the user libraries on your system
- Less time to save the BRMS media information after each backup.
The physical file conversion occurs during the post processing phase of the primary language install. In V5R3 and above, the impact of this conversion is alleviated somewhat by processing it in a separate batch job, allowing the rest of the system install to continue processing at the same time.
The time required to convert the files in library QUSRBRM will vary depending on the system model, storage configuration and number of records in the physical file in the QUSRBRM library.
Note: When you perform the estimation process below, be sure to emulate the system environment which you plan to use when installing BRMS. The conversion performs best when system activity is minimized.
To estimate the conversion time do the following:
Improve outfile processing performance.
If you save libraries with *YES or *MBR specified in the Retain Object Detail attribute, you can significantly improve BRMS output file processing by following this tip. Output file processing spends a lot of time retrieving member size and member text fields for BRMS save history. If you do not need the member size and member text details (and you have installed SI20411 for V5R3 or SI20410 for V5R2), you can use the following command to disable retrieving those extended member details.
QSYS/CALL PGM(QBRM/Q1AOLD) PARM('RTVEXTMBR' '*NO')
Where parameter 2 may be specified as:
*NO - disable the retrieval of extended member details
*YES - enable the retrieval of extended member details
*DISPLAY - display whether the extended member details are being retrieved
Note: All parameters for this command must be entered in uppercase.
What this means:
By disabling retrieve extended member, BRMS will continue to allow you to drill down to member level detail and restore an individual member. However, the display option for that member on the WRKMEDIBRM screen will display blank for member text and 0 for member size. Object text and object size will continue to show the actual data.
Run Maintenance every day!
Make efficient use of your media by running STRMNTBRM daily to expire media, remove history records for expired media, clean up temporary files, move media and manage journal receivers.
Reorganize the BRMS data files once a month.
You can significantly lower the size of the BRMS data files by issuing the RGZPFM command. You will gain the most benefit by reorganizing QA1AHS, QA1AOD, QA1AMB, QA1AFD, QA1ALG, QA1AOQ, QA1ADI, QA1ADI2, QA1ALI and QA1ALI2 in QUSRBRM. In V5R2 or later, you can run this function during maintenance by changing the STRMNTBRM RGZBRMDB parameter to *YES. This way you do not have to enter all of the file names.
Note: Ensure that there is no BRMS activity while reorganizing these files.
Saving time doing restores
When doing BRMS recoveries, users can use the new SUBMIT TO BATCH function when saves are done in Parallel-Serial mode or there is a need to run multiple restores concurrently to save time.
To use this function, the following needs to be done:
- Put all scheduled jobs on hold. Depending on the job scheduler you use, how to do this will differ.
- CHGJOBQE QBATCH - Change MAXACT and all MAXPTY* parameters to number of concurrent restores to be run and press Enter. These parameters should be reset to the original values when the restore is complete.
- Start QBATCH
- End Q1ABRMNET subsystem if it starts
- Run a STRRCYBRM *SYSBAS *RESTORE , chose the *VOLSET with the first volume, F16 to select, then F14 to submit to batch.
- STRRCYBRM *RESUME and did same for each *VOLSET
- Use WRKSBMJOB to monitor the restores that have been submitted to batch and check for any errors.
Note:
- You will need sufficient tape drives. A minimum of one for each restore job.
- If you have iASPs to recover, you will want to use STRRCYBRM *ASPDEV *RESTORE once they are AVAILABLE.
- Available at V5R4M0 and above
System i parallel save and restore
Many customers are interested in spreading their backups across multiple drives simultaneously in order to shorten their backup time. The System i platform offers several techniques to do this, some of which have special considerations. This article will begin by outlining the various multi-streamed backup options. It will then discuss a situation with referential database constraints where care is required with multi-streamed saves. Finally, the article will delve into each of the three multi-streamed backup options, explaining how to use the save technique, and the best way to restore that type of save.
Overview of techniques for running multi-streamed backups on the System i platform
There are three different techniques for running multi-streamed backups on the System i platform:
- Concurrent saves
- Parallel-parallel saves
- Parallel-serial saves
Concurrent saves have been available since the early days of the AS/400. They are being used very successfully by many customers around the world, with very few considerations.
Parallel-parallel saves were introduced at V4R4 and were intended for customers who needed to split a single large object across multiple drives. To use them successfully, use Backup, Recovery and Media Services (BRMS) for the save, recover to a system that has access to the BRMS information about the save, and use the same number of drives for the restore as you used for the save.
Parallel-serial saves were introduced at V5R1 by allowing parallel saves to run against special values like *ALLPROD, *ALLTEST, *ALLUSR, *ASP01–*ASP99, *IBM, generics etc. They basically run a set of concurrent saves, but BRMS divides the libraries into the save streams rather than the user. To use parallel-serial saves successfully, use BRMS for the save, and use a special recovery technique to get multiple drives working on the restore simultaneously.
Referential constraints
When a database has referential constraints, there are some scenarios where multi-streamed restores can fail due to seize issues with the various objects related to the constraint. As one object is being restored, the system has a seize lock on it. If a related object is restored at the same time, then the second restore will be unable to get the necessary seize on the first object, and the restore will fail.
For customers who have referential constraints in their databases, there are three ways to work around this issue:
- Use a single stream recovery rather than a multi-streamed recovery for the libraries that have files involved in the referential constraint
- (2) If the related objects are all in a single library, and if that library is saved using a save-while-active command, then i5/OS is able to handle this situation.
- (3) If the save is a parallel-parallel save, and the recovery is done with the same number of drives as the save, then i5/OS is able to handle the situation. (** Question ... Does this handle both the case where all the related objects are in 1 library, and also when they are in multiple libraries?)
These considerations for customers with referential constraints are in addition to those described in the sections below.
Concurrent saves
For this technique, the user decides how he will allocate the objects among the tape drives. He then issues one command or job for each drive, and the various drives will run independently from one another, e.g.
Drive 1: SAVLIB LIB (A* B* C* .... H*)
Drive 2: SAVLIB LIB (I* J* K* ..... R*)
Drive 3: SAVLIB LIB (S* T* U* .....Z*)
etc
Some tinkering will be required to make the save streams approximately the same size so they will end at approximately the same time. Care must be taken to ensure that all desired objects are included in the save, including libraries that start with non-alphabetic characters, the Document Library Objects (DLO), the Integrated File System (IFS), spoolfiles, etc.
Recovery is fairly simple. The sets of tapes can be restored using the same number of drives or fewer drives, by mounting the tapes and issuing the corresponding restore command. The key consideration on the restore is for customers who have their physical/logical files or their journals/receivers in different libraries: they need to ensure that the files are restored in the proper order, otherwise an error message will occur, and the missed files will need to be restored separately later. Careful planning of the save streams can usually allow the files to be restored in a single pass, even for customers with physicals/logicals and journals/receivers in different libraries.
Parallel-parallel saves
There was a group of customers who needed to shorten their backups, but could not do so with concurrent saves, because their data included a single large object that made up the bulk of the save. In the early days, there was no way to split this object across drives, so that one stream became the limiting factor in shortening the backup window. Adding more drives to the save was no help.
To assist these customers, IBM introduced parallel-parallel saves at V4R4. For a parallel-parallel save, the user issues a single save command, but asks i5/OS to run it across multiple drives, e.g.,
SAVLIB LIB(biglib) DEV(*MEDDFN) MEDDFN(biglibdfn)
(where ”biglib” is the library with the large object, and where the “biglibdfn” media definition indicates multiple drives)
Although it is possible to implement this using i5/OS commands, it is fairly difficult since media definition files need to be created for both the save and the restore. For example, the media definition for the restore tells i5/OS the details of the data on the tapes and the file sequence numbers where the data can be found. Rather than doing this manually, customers are encouraged to use BRMS since it creates the media definition files in the background using the tape exit programs and the file sequence information in the BRMS database. Customers simply tell BRMS how many drives they would like to use for the save or restore, and BRMS handles the rest.
There are three key considerations for restoring this type of save:
- In order to restore the data, you need access to the BRMS database so the media definition can be created. This is easy for a customer who is restoring an object to a system in the same BRMS network where it was saved, or a customer doing a full system recovery who will re-load his BRMS information as part of the restore. However, it is more difficult to take a parallel-parallel tape to a separate system and try to restore it since the media definition will need to be created manually.
- When doing the recovery, i5/OS will restore all parts of the first library from each tape, then go back and restore all parts of the second library from each tape, and so on. If you have the same number of drives on the restore as you had on the save, then i5/OS mounts all the tapes and moves quickly among them and pulls the data off each tape in order. The recovery typically takes 1-2 times as long as the save. However, if the restore is done with fewer drives than the save, then i5/OS needs to mount each tape once for each library that is saved on it. Due to all the tape mounts, searches, rewinds, etc this can take a very long time and is likely not practical.
- As discussed above, using the same number of drives for the save and restore will avoid seize problems when there are referential database constraints.
The net of this is that parallel-parallel saves can be used successfully so long as saves are done with BRMS, restored to a system that has access to the BRMS information, and restored using the same number of drives as the save. As with concurrent saves, customers who have their physical / logical files and journals / receivers in different libraries need to plan their strategies so these objects are restored in the proper order
Parallel-serial saves
Starting at V5R1, it became possible to specify generics (eg ABC*) and special values like *ALLUSR, *ALLPROD, *ALLTEST, *ASP01-*ASP99, *IBM, generics, etc on a parallel save. This type of save became known as a parallel-serial save since it was a cross between a parallel save and a regular (“serial”) save. It was considered parallel since i5/OS decided how to spread the libraries among drives, unlike the concurrent save where the customer decided how to spread the libraries. However, individual objects are not necessarily spread across multiple drives: instead, i5/OS uses a round-robin algorithm to allocate the various libraries, one to each drive, working from A-Z.
When you ask for a parallel save, i5/OS decides whether to do a parallel-parallel or parallel-serial save, depending on the type of objects to be saved as follows:
- single object - parallel-parallel
- single library - parallel-parallel
- list of libraries - i5/OS decides which to do depending on various factors
- generic libraries (eg LIB*) - parallel-serial
- special values (eg *ALLUSR, *ALLPROD) - parallel-serial
The tapes that result from a parallel-serial save have the libraries jumbled on them alphabetically due to the round-robin algorithm. For example, with a 3-drive save, if all the libraries were approximately the same size, the libraries might be spread something like the following:
Tape 1: A-lib, D-lib, G-lib, etc
Tape 2: B-lib, E-lib, H-lib, etc
Tape 3: C-lib, F-lib, I-lib, etc
Now as an aside: as mentioned above, programming convention on the System i platform says that customers should try to put their physicals / logicals or their journals / receivers in the same library. In this case, i5/OS is able to restore these related files successfully. For customers who need these objects to be in separate libraries, programming convention says to name the libraries alphabetically so that i5/OS will restore the base files first and the dependent files second when it does a restore in alphabetical order.
When restoring a parallel-serial save, BRMS tries to follow the above convention by restoring the objects in alphabetical order. Customers are often surprised to learn that regardless of how many drives they ask BRMS to use, the default restore only reads from a single drive at a time as follows:
If a customer asks BRMS to use the same number of drives for the restore as for the save, then the first tape of each set is loaded into each drive. However, i5/OS then moves through the drives one by one, restoring the libraries in alphabetical order, such that only one drive is in use at any given time.
If customers ask BRMS to use a single drive for the restore, then i5/OS mounts the first tape and restores the first library. BRMS then rewinds/dismounts the first tape and mounts/loads the second tape and restores the second library. This continues, cycling through the tapes one by one until all libraries are restored. Not only is the restore being performed on a single drive, but there are also numerous mount/search/rewind/dismount cycles to wait for.
Since a single-drive restore is typically not practical for customers, a work-around was devised whereby multiple restore jobs are submitted to get multiple drives working simultaneously. At V5R3 and lower, customers need to create these streams manually by carefully selecting the items to be restored. At V5R4, new function was added to the STRRCYBRM screens to make this simpler. Here is a description:
During a recovery, the STRRCYBRM command brings up a screen showing all the objects that are available for restore. This list is in alphabetical order. There are 3 ways to handle this screen:
- If you ask BRMS to go ahead and do the default restore, you will find yourself in one of the situations described above where only a single drive is active on the recovery at a given time.
- The workaround for V5R3 and earlier releases is to submit the recovery in multiple sections. This needs to be done very carefully. Start by figuring out all the tapes that are in the first set. Then open the STRRCYBRM screen and go down through the list and select all the items that are on that set of tapes, then submit the command for restore. Then go through the list again, and select the items that are on the second set of tapes, and submit them for restore. Continue until all items have been selected from the list.
- Starting at V5R4, the same technique can be used, but BRMS offers assistance in selecting the items to be restored in each set. On the STRRCYBRM ACTION(*RESTORE) screen that lists the items for restore, there are two selection fields in the top right corner that let you specify *VOLSET and a volume number prior to using the F16=Select key. All saved items that are on the same set of tapes as that volume are marked with a ‘1’. You then use F9 for recovery defaults, and F4 to submit the restore. You then repeat this for each different save stream until all restores have been submitted.
As with concurrent and parallel-parallel saves, customers who have their physicals / logicals and journals / receivers in different libraries, may receive error messages indicating that files could not be restored since their base file was not yet on the system. Operators need to check for these messages and go back and restore the missing files later. Alternatively, it may be possible to plan the save strategy to minimize these concerns, using one of the following techniques:
- Design the save strategy so all traditional libraries are in a single stream, then use the other streams for other items like DLO, IFS, etc. That way the traditional library stream will be on a single drive and will restore in alphabetical order without dependencies between drives
- Design the streams so one stream saves all the dependent files (e.g. logical files and journal receivers). During the recovery, restore that stream last, after all the other streams are already back on the system
The net of this is that parallel-serial saves can be used successfully so long as the special recovery technique is used to get multiple drives running simultaneously during the recovery, and the restore order of physical / logical files and journals / receivers is handled.
Note that parallel-serial saves are very similar to concurrent saves, except that i5/OS carves the backup into multiple streams and attempts to have them all finish at the same time based on the round robin algorithm. For customers with data that varies from day to day such that it would be difficult to pre-plan concurrent streams, then parallel-serial saves offer a benefit. However, customers who are able to design their own concurrent streams, may find that concurrent saves are a better strategy due to the simpler recovery prior to V5R4 and less overhead on the system.
Conclusion
Concurrent and parallel saves offer customers options to shorten their backup window. If customers understand the advantages and considerations for each, they can plan a save/restore strategy that will be a good fit for their organization.
(Article by Nancy Roper appeared in the COMMON Connect magazine )
Tape library resource status tool
Do you ever want to find out who is using a resource in a tape library that you need?
PTFs SI24433 for V5R4, SI24427 for V5R3 and SI24426 for V5r2 include a helpful tool for customers with the advanced BRMS feature. This is included in the base code V6R1 and above.
This tool will produce a report that displays the users of the resources in a tape library for all systems in a BRMS network that share that library.
To find the tape library resource status for a specific system, issue the following command:
QSYS/CALL QBRM/Q1AOLD PARM('DEVUSESTS ' 'SYSTEM1 SYSTEM2')
Note that the second parameter can specify multiple systems, restricted only by the parameter length of 200 characters.
To find the tape library resource status for all systems in the BRMS network issue the following command:
QSYS/CALL QBRM/Q1AOLD PARM('DEVUSESTS ' '*NETGRP')
Both of the commands will generate an output file, QTEMP/DEVICELOG, and a printer report, QP1ADEVUSE.
Notes:
- In order to get status from a particular system, that system must have the appropriate PTF applied and must be in the BRMS network.
- All characters in the PARM field need to be in capitals (CAPs)
Adding steps to recovery report
Starting at V5R4M0, it is now possible to add additional user recovery steps to the BRMS recovery report. User recovery information can be included in the recovery report by adding records containing the information to the appropriate members of file QO1AUSRRCY in library QUSRBRM. Add records to member PROLOG to include user recovery information to the prolog information in the report.
Notes:
1. Add records to members STEP nnn to include user recovery information to specific steps in the report, where nnn is the step number as it appears on the report. Up to 92 bytes of user recovery information can be added to each record. There is no limit to the number of records.
2. User recovery information is added to the report following the BRMS information and before any saved items in the step. This information will be clearly highlighted on the report as user recovery information.
3. Each record is read sequentially from the file member, starting from the first record and ending with the last record, and will be added to the report in the same order as read. Each record will be placed on the report following the last printed line starting in column 8.
4 The user is responsible for all spacing, positioning and translation of the recovery information in each record.
5. The user is responsible for assuring the accuracy of the user recovery information.
6. The step numbers in the report differ depending on the value of the Option (OPTION) parameter and the content of the recovery. If the OPTION or content is changed, the names of the members in file QO1AUSRRCY may need to be renamed accordingly. The step numbers should be consistent if the report type and saved item content are consistent.
7. No exception is signaled if user recovery information is requested but no records are found in the members.
8. When using STRRCYBRM USRRCYINF(*ADD) FROMSYS(), the user steps from the target system will not be included in the recovery report unless the additional steps have being added to the QO1AUSRRCY file in library QUSRBRM. on the system where the recovery report is being run on.
9. STRRCYBRM ACTION(*RESTORE) USRRCYINF(*ADD) will fail with BRM132E
Setting Expiration date of duplicate volumes
It is possible to set the expiration date of duplicate volumes to match the expiration date of the original volumes. To do this, users can use the EXPDATE parameter on the DUPMEDBRM command
V6R1M0 and above
Use EXPDATE(*FROMVOL)
In V5R3M0 and V5R4M0
Set the value in the EXPDATE parameter to one of the following : 010107 for systems with a Date format of *MDY 010107 for systems with a Date format of *DMY 070101 for systems with a Date format of *YMD
Help Text (added in future release) Output file sequences and volumes from this duplication operation are assigned the expiration dates of the input file sequences and volumes.
Note: the following PTF or their superseding PTF is required
- V6R1M0 SI33975
- V5R4M0 SI33974
- V5R3M0 Si33971
Send email notification for messages sent to the BRMS log
Use the BRMS graphical user interface (GUI) to set the following 'Global Policy Properties':
- Click the 'Network' tab and set the 'Primary system', 'Secondary system' and 'E-mail address' fields.
Note: The system that you select as the primary system will distribute the messages. If the primary system cannot complete the distribution, it sends the message to the secondary system for distribution. For example, you could select a local primary system and a remote secondary system. When the local system is in restricted state, BRMS sends the email through the remote secondary system. If a secondary system is not specified and the primary system is in restricted state, the message will be queued and distributed as soon as the BRMS networking is restarted. Note: The email server must have the Simple Mail Transport Protocol (SMTP) configured. If it is not configured, messages will not get distributed and an error message may not result.
- Click the 'Logging' tab and add the messages you wish to be notified for in the 'Message IDs to distribute' field. For example, to have emails sent for errors found by the STRBKUBRM command, add messages BRM1970, BRM1971, BRM10A1, BRM1820, BRM4116 and CPF9999.
|
