Do you have a sufficient backup strategy?
This is the second part of a two-part series about saving and restoring objects. It discusses advanced and infrequent save and restore operations, such as saving system libraries, saving storage, saving licensed programs, and journaling.
“Save/Restore: Part 1” (MC, March 1998) devoted itself to the frequent (daily and, at the least, weekly) saves. This article centers on some equally important save strategies, which are used less frequently.
Saving the System—or at Least a Very Important Part of the System
The first thing you must consider is saving the system with the Save System (SAVSYS) command. When I first moved to an AS/400 from a S/36 environment, I took the term save system literally as saving the entire system. This command does not save the entire system; it saves the system objects. These objects are defined as all licensed programs, the QSYS library, all user profiles, and configuration objects.
You might notice some overlap here. Last month, I talked about the Save Security Data (SAVSECDTA) and Save Configuration (SAVCFG) commands, which save user profiles and configuration objects. The SAVSYS command also saves those objects. In addition, SAVSYS saves the QSYS library in a format such that it can be installed from that SAVSYS tape.
One limitation of the SAVSYS command is that it must run with the system in restricted state. Restrictedstate is a condition of the system in which the only operation being performed is the one on the system console. This ensures that the data stored to the save tape will be clean and that no changes will be made to it while the save operation
proceeds, as could happen in the save-while-active operation discussed in the previous article.
To get the system in restricted state on the system console, enter either of these commands:
ENDSBS SBSD(*ALL) +
OPTION(*IMMED)
or
ENDSBS SBSD(*ALL)
If you have trouble getting users to sign off and you have to force the issue, use the command with the immediate (*IMMED) option to end the subsystems. If you do not have this trouble, use the second command, without the immediate option. Which version you use to put the AS/400 in a restricted state will depend on your shop and the habits of your users.
Wait for a message on the QSYSOPR message queue (DSPMSG QSYSOPR) that the system is in restricted state. Only after that can you run SAVSYS.
When SAVSYS finishes, set the record tab on the tape in such a way that the tape cannot be overwritten accidentally.
Why is SAVSYS so important? In the event of a serious crash (loss of disk or loss of data), the system can be Initial Program Loaded (IPLed) from this tape. Therefore, when you run a SAVSYS, be sure to use the alternate IPL device in your configuration.
I suggest that you run the SAVSYS command after updating OS/400 to a new release. It is also a good time to run SAVSYS when you have added several users to the system or several devices to the configuration.
Remember that if you saved user profiles or the configuration in previous saves, the SAVSYS tape will have outdated copies of those objects. When restoring using a SAVSYS tape, you may have to do several restores to reinstate the latest user profiles, authorization lists, and configuration objects.
Save Storage Command
The Save Storage (SAVSTG) command is a good utility when used correctly. Normal save and restore operations are not a good use of this command. SAVSTG is quick, possibly quicker than many save and restore operations, but it has its limitations.
SAVSTG places on tape a copy of the Licensed Internal Code (LIC) and auxiliary storage (DASD) as it finds it, sector by sector, block by block. This method is fast because the system does not have to search your DASD for the contents of an object. But the mode of this speedy save method is also the source of its limitations; individual objects cannot be restored from this tape. Instead, the tape must be restored in its entirety.
SAVSTG has a unique approach to saving data. It does not go and get the data as a Save Library (SAVLIB) or even SAVSYS would. The command begins work by issuing an immediate power down system with a restart (PWRDWNSYS *IMMED RESTART(*YES)). Then, it calls a dedicated service tool (DST) to perform the SAVSTG operations. Without going into an in-depth discussion of DST, let’s just say that it is a unique set of tools that should be handled by seasoned AS/400 veterans, such as system engineers and support line personnel. DST exists on each AS/400, regardless of what program products are installed.
Restoring from a SAVSTG is difficult but achievable. First, you must bring the system down with the power down system command with the immediate option (PWRDWNSYS OPTION(*IMMED)). Do not have the system power itself up after shutdown.
Next, you have to do a D IPL, which IPLs from tape. How you do this depends on the model of your system, but the instructions are found in your Backup and Recovery Guide—Basic V3R1.
When the system comes up from your D IPL, you will see the IPL or Install System menu. You will need DSTs and your DST password. Take the DST option for working with save and restore storage. A confirmation screen will appear to alert you that you are essentially wiping out all data on the disk and restoring what is on the tape. After replacing all of your data on the system, you will be asked to perform an IPL.
Saving Licensed Programs
The licensed programs (sometimes called program products) also need to be saved at regular intervals. The Save Licensed Program (SAVLICPGM) command saves any or all of the licensed programs to tape.
If you are thinking that this is some overlap with the SAVLIB LIB(*IBM) command, you are very perceptive. There is some overlap here; many of the licensed programs are in Q libraries, and have a “created by” user of *IBM.
Depending on your strategy, you can use either or both Save commands. Whatever you decide to use, make sure that the most recent data gets to the disk last when restoring from tape.
To save a licensed program, first look at a nonsave-related menu option. At a command line, type GO LICPGM and select option 10 to display your licensed programs. The numbers that IBM assigns to these licensed programs are an important part of this operation. A system at V3R1 might show these as some of the installed licensed programs:
5763RG1RPG
5763SS1*BASE part of program products
5763QU1Query
SAVLICPGM requires you to enter program product names. There is no *ALL value to get all of them.
To save the Query licensed program to TAP01, at a command line, type:
SAVLICPGM LICPGM(5763QU1) +
DEV(TAP01)
(If you prefer, you can run SAVLICPGM from the LICPGM menu.) To save all three programs, use this code:
SAVLICPGM +
LICPGM(5763QU1 5763SS1 5763RG1) +
DEV(TAP01)
To restore these programs, use the Restore Licensed Program (RSTLICPGM) command:
RSTLICPGM +
LICPGM(5763QU1 5763SS1 5763RG1) +
DEV(TAP01)
To be safe, save licensed programs when you apply a PTF or when you add a new licensed program to your system.
Saving APAR Data
If you have open problems with IBM authorized program analysis reports (APARs), you can also save that data with one command. The Save APAR Data (SAVAPARDTA) command can save those problems. It comes in two flavors: You can save a new record (SAVAPARDTA PRBID(*NEW)), or you can also specify a problem number by replacing *NEW with the problem number.
Saving S/36 Data
You can use two native commands to save the data from a S/36 environment: Save System 36 Library Members (SAVS36LIBM) and Save System 36 File (SAVS36F). The corresponding Restore commands are RSTS36LIBM and RSTS36F. These commands save files and library members in a format recognizable to a S/36. For example, the SAVS36LIBM command allows you to save source and procedure files from the S/36 environment. When you save source members with this command, they appear to the S/36 environment as if they were saved with a FROMLIBR OCL procedure.
You should use these commands only to build tapes that will have to be read by a S/36. For regular backup and restore purposes on your AS/400, you should use native commands like SAVLIB and Save Object (SAVOBJ).
Journaling
I have discussed many ways of making sure that your data is safe between backups. Many users may need higher levels of protection between backups. You could perform regular SAVLIB operations, but they require substantial system overhead, and your users will possibly notice a decline in throughput while these saves are running. Journaling some of your data is another viable option.
Journaling involves making either both before and after or only after copies of changed physical files. You can set up journals and journal receivers to hold these copies. I will discuss setting up journaling, cleaning out old journals, and restoring the journaled changes.
Before journaling, a manager must choose which files to journal. The system helps with that decision; only physical files can be journaled. Now for the tough decision—which physical files to journal. That is going to depend on your system and which files you could not live without losing between saves. For an early practice session, I suggest starting on a file in your system that gets low to moderate daily usage. Go through the following steps with that file for a few days until you are comfortable with journaling. Then, you can better choose which physical files need to be journaled.
Creating the Journal Receiver
Journaling requires that you create a journal receiver and a journal. The journal receiver holds the images of the physical files. To create this receiver, use the Create Journal Receiver (CRTJRNRCV) command. To create a receiver called MYRCVR in a library named MYLIB, type the following:
CRTJRNRCV JRNRCV(MYLIB/MYRCVR)
That is all it takes. There are some optional parameters on the CRTJRNRCV command that I will discuss.
The first optional parameter is the auxiliary storage pool (ASP) ID. If your system is set up with multiple ASPs, you can designate that your receivers be placed in a specific ASP. If you don’t specify, the default places that receiver in the ASP associated with your current library.
The second optional parameter is the journal receiver threshold (THRESHOLD). This parameter can make the system alert a user when a receiver gets too big. The
THRESHOLD parameter can have a value of *NONE or a receiver threshold value in kilobytes. If a threshold value other than *NONE is specified, the system will send a message to the user associated with the journal. If *SYSTEM is defined on the CRTJRN command, the system creates a new journal receiver and detatches the old one. I will explore that further when I discuss creating the journals.
Third is the text. I would suggest that it be something like “Journal Receiver for MYLIB/MYFILE.” You may substitute your nomenclature here. This text is especially helpful when you have created several receivers; you may forget six months down the road which receiver goes with which file. If you were to use the Work with Objects (WRKOBJ) command to display all journals in your library list (WRKOBJ *ALL *JRNRCV), you would see how helpful the text can be.
As a side note here, I suggest that you set up separate receivers and journals for each database file. The system allows multiple files to be journaled in one receiver and journal. For ease of use, however, I prefer only one file per journal and receiver.
Creating a Journal
Next, you must create a journal. This will help tie together the physical file and the journal receiver. To create a journal, use the Create Journal (CRTJRN) command. Using the previous example, type the following at a command line to create a journal called MYJRN:
CRTJRN JRN(MYLIB/MYJRN) +
JRNRCV(MYLIB/MYRCVR)
Notice that CRTJRN requires you to reference the journal receiver created earlier, thus tying the journal receiver to the journal. That’s why it’s important to create the receiver first.
Now, I’ll explain how those optional parameters work. The journal threshold message queue tells the system where to send messages when the receivers meet their thresholds. The important idea here is that journaling does continue when a threshold is met; a message is just issued.
The Manage receivers (MNGRCV) parameter lets either the user (*USER) or the system (*SYSTEM) manage the changing of journal receivers. I’ll discuss changing journal receivers later in this article. For now, it’s enough to say that either the user or the system can change these receivers. If the system is specified, the Delete receivers (DLTRCV) parameter tells the system if it can automatically delete the receivers or not. I prefer the user option. If the system controls the changing and deleting of the receivers, you may lose information—exactly what you are trying to avoid.
Start Journaling Physical Files
To start journaling a physical file, use the Start Journal Physical File (STRJRNPF) command. As an example, suppose you are journaling MYFILE in MYLIB. At a command line, you would type the following:
STRJRNPF FILE(MYLIB/MYFILE) +
JRN(MYLIB/MYJRN)
Starting journaling requires that you have a file with exclusive allocation to the command (exclusive meaning that no other programs are using that file) just long enough to start the journaling process. This usually takes just a few seconds. You will do one of two things: You can run a Work with Object Locks (WRKOBJLCK) command to see who is using that file, get them to discontinue their program(s), and journal the file. Or you
can put a job running in a job queue that checks for exclusive allocation. When the system is able to allocate the file exclusively, immediately start journaling that file. Use the Allocate Object (ALCOBJ) command, specifying a lock state of *EXCL to accomplish the allocation.
When journaling, there are two more parameters to consider. The first is the Images (IMAGES) parameter of the STRJRNPF command. This will specify whether you journal only the after image or both the before and after images. Journals can be used for multiple reasons. If your reason is primarily save and restore, then only the after (*AFTER) image is needed. If you have an additional reason to see who is doing what to that file, then consider both (*BOTH) images.
Omit Certain Journal Entries
You can optionally omit the open and close operations to a journal (OMTJRNE (*OPNCLO)) or omit no entries (OMTJRNE (*NONE)). For save and restore purposes, you can omit the open and close entries. However, if you want to know who is accessing the file, open and close entries are very important.
Now, your journals are merrily tracking changes to your physical files. What do you do when you need to reapply those changes? You can apply those journaled changes to a physical file with the Apply Journaled Changes (APYJRNCHG) command. This command can rebuild a file from any point in the journal to any other point in the journal. An exclusive lock on the file is needed to apply these journaled changes.
Periodically, you need to clean out the journaled data from your receivers. I recommend doing this when the physical files are saved to tape using a SAVOBJ or SAVLIB command. To start the journaling to a new receiver, use the Change Journal (CHGJRN) command. This tells the system to create a new receiver, detach the old one, and reattach the new one. CHGJRN does not delete the old receiver.
Protecting Your Magnetic Media
Magnetic media is a good storage place for data. Unfortunately, it is vulnerable to fire or water damage. Two methods of protecting magnetic media are fireproof safes and off-site storage.
Fireproof (sometimes called media) safes are an excellent way of protecting tapes from flood or fire. These safes are designed to withstand high temperatures for hours and still not harm magnetic media.
Off-site storage is another good way to protect your data. Storing the data away from your site, as in a safety deposit box, ensures that you can restore it after a catastrophe. The record/no record tabs on tapes offer another form of protection. This is especially true with SAVSYS tapes. Day-to-day tapes may be reused routinely and may not need this added protection, but you want to make sure that a SAVSYS tape is not accidentally overwritten. If you keep a save of year- or month-end data, you may also want to use the record/no record tabs to prevent accidental erasures.
Lastly, disk mirroring and RAID technologies provide a high level of access for your data. The down side to mirroring is that you need literally double the disk space that you would need if you were not mirroring. RAID uses only one disk to write the changes to, so if you have eight disk units, only one would be needed for RAID, and the balance can be used for normal day-to-day operations.
I hope these articles have made the managers of data think about differing ways to protect it from accidental loss. The threats to data are not limited to disk crashes, natural disasters, and acts of God, but also come in the form of over-eager programmers wanting to place an untested program into production.
As you can see, there are many ways to protect your data. Some have a monetary impact, and some do not. You will have to decide which level of protection is right for you and your budget.
References
Backup and Recovery Guide - Advanced V3R1 (SC41-3305, CD-ROM QBKALF00) Backup and Recovery Guide - Basic V3R1 (SC41-3304, CD-ROM QBKALE02) CL Reference, V3R1 (SC41-3722, CD-ROM QBKAUP00)
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online