The question that matters is not "do we take backups" but how much work is lost if the system stops now, and how long it takes to be running again. A save plan answers those two questions with a number; a procedure that runs at night on its own does not.
What there is to save
A complete IBM i is made of pieces saved with different commands:
- the Licensed Internal Code and library QSYS, together with security data and
configuration objects:
SAVSYS, which saves no other library; - the libraries other than the system ones, that is products, application and data:
SAVLIB LIB(*NONSYS), or*ALLUSRfor user libraries only and*IBMfor IBM's; - documents and folders in QDLS:
SAVDLO; - IFS objects:
SAV, the command for the other file systems.
The menu that puts them in order:
GO SAVE
| Option | What it saves | Restricted state |
|---|---|---|
| 21 | the entire system | required |
| 22 | system data only, no user data | required |
| 23 | all user data | it sets it, unless you skip ENDSBS by prompting the commands |
The three options first end the TCP/IP servers and host servers, then TCP/IP, with two
waits (DLYJOB) of 300 seconds each by default, and only then run ENDSBS SBS(*ALL).
Option 21 runs, among others, SAVSYS, SAVLIB LIB(*NONSYS), SAVDLO and SAV on the IFS
omitting /QSYS.LIB and /QDLS, already saved by the earlier commands. Option 20 changes
the defaults of the other three.
Warning
restricted state means that once the save begins nobody can use the system.
IBM suggests overnight for a small system and the weekend for a large one. Independent
ASPs must be varied on first, or they are not saved. A plan made only of online library
saves does not include SAVSYS, and without SAVSYS you cannot start again from an empty
disk.
Journals
A nightly save takes the system back to how it was last night. Later changes can be recovered only if there is a journal.
The journal records changes to files in a separate object, the journal receiver. From a save plus the journal, the state can be rebuilt up to the last recorded change.
CRTJRNRCV JRNRCV(JRNLIB/RCV0001)
CRTJRN JRN(JRNLIB/JRNPROD) JRNRCV(JRNLIB/RCV0001)
STRJRNPF FILE(PRODLIB/ORDINI) JRN(JRNLIB/JRNPROD)
Journals are not only for recovery: without a journal there is no commitment control, and replication solutions are built on them.
When the system changes and deletes receivers
CRTJRN and CHGJRN parameter |
What it does |
|---|---|
MNGRCV(*SYSTEM) |
when the receiver reaches its threshold, the system detaches it, creates a new one and sends CPF7020 to the journal's message queue |
DLTRCV(*YES) |
the system deletes detached receivers when no longer needed; only with MNGRCV(*SYSTEM) |
Warning
DLTRCV(*YES) does not wait for a save. The only things that stop the
deletion are a lock on the object, a remote journal that does not yet have a full copy,
and an exit program registered on exit point QIBM_QJO_DLT_JRNRCV saying the receiver
is not eligible. Without one of these, an unsaved receiver disappears, and with it the
changes needed for recovery. More, with the queries, in
Freeing space from journal receivers.
The media is not the point
Tape, virtual tape on disk or something else matters less than three questions:
Can the save be read back? A job that ended without errors says the save was written, not that it can be restored. The proof is restoring something, on a test system or into a different library, and seeing that it is there.
Is there a copy elsewhere? Media in the cabinet next to the machine protects from a disk failure, not from a fire or an attack that encrypts the network.
Does somebody know how? A complete restore has a precise order. It is worth having it written down and tried before it is needed.
Tip
where saves are run by BRMS, it is worth understanding how it is configured rather than building a parallel procedure, which would know nothing of the other one's saves.
Restoring
The commands mirror the save commands (RSTUSRPRF, RSTLIB, RSTOBJ, RST, RSTCFG,
RSTDLO, RSTAUT), but order matters. IBM gives it as:
- User profiles, with
RSTUSRPRF: an object's owner must exist before the object can be restored.RSTUSRPRF USRPRF(*ALL)also brings back authorization lists and authority holders, which must be there before the objects. - Objects, with
RSTCFG,RSTLIB,RSTOBJ,RSTDLOorRST: owner, public authority and the other information saved with the object come back. - Private authorities, with
RSTAUT; alternatively,PVTAUT(*YES)on the restore command.
Get the order wrong and, IBM warns, ownership and authority are not restored correctly and applications may not run.
Warning
the system value QALWOBJRST decides whether security-sensitive objects can
be restored, such as a program that adopts authority or a system-state object. It is
shipped as *ALL, which is the value needed to install a release, install products and
recover the system. IBM advises setting it back to your normal value afterwards: leaving
it at *ALL accepts any authority-adopting program from any media.
For a complete recovery IBM publishes checklists, one per case, with the steps already in this order: read them for your own release before starting, not during.
Comments
No comments yet. Be the first to comment!
You need an account to comment. Log in · Sign up