On IBM i, saving works so well that it tends to become invisible: somebody set it up years ago, the job runs, nobody looks at it. The trouble is that a backup is not there to save: it is there to restore. And the difference between the two only shows up on the day you need it.
Three questions to ask before any command
- How much work can we afford to lose? If you save at 22:00 and the failure comes at 17:00, you lose an entire day's transactions. If the answer is "we cannot afford that", you do not need a better backup: you need journalling, which is a different thing.
- How long do we have to get back up? A full system restore is not fast. Measure it once, as a drill, so the number is known before you have to quote it to somebody.
- Where does the backup physically end up? A backup that stays in the same room as the machine protects against hardware failure, not against fire or ransomware.
The commands, from broadest to most targeted
GO SAVE option 21 is the full save: operating system, licences, all user libraries, the IFS. It requires the machine in restricted state — nobody signed on, subsystems stopped — so it happens in planned windows. It is the only save you can rebuild from onto new hardware.
SAVLIB saves a whole library:
SAVLIB LIB(MYLIB) DEV(*SAVF) SAVF(BACKUP/SAVMYLIB)
SAVOBJ saves selected objects, when you need something specific.
SAVCHGOBJ saves only what has changed since a given date:
SAVCHGOBJ OBJ(*ALL) LIB(MYLIB)
REFDATE('01/07/2026')
DEV(*SAVF) SAVF(BACKUP/SAVDELTA)
That is the basis of incremental saving: full at the weekend, incremental every evening. It shortens the save considerably, but lengthens the restore, because you have to reload the full save and then the incrementals in order.
Save files: convenient, with one limit to know
A save file is a container on disk that behaves like a tape:
CRTSAVF FILE(BACKUP/SAVMYLIB) TEXT('MYLIB save')
They are extremely handy: created on the spot, transferable by FTP, kept online. But they have one characteristic that has to be stated plainly: they sit on the same disks as the machine. A save file is an excellent way to move objects around and to keep a safety copy before a change; it is not a backup, because it shares the fate of the system it is meant to protect.
Serious saves go to tape, or get copied off the machine immediately after being created.
Before every delicate change
This is the habit that repays most of all, and it costs thirty seconds:
CRTDUPOBJ OBJ(PGMORD) FROMLIB(MYLIB)
OBJTYPE(*PGM) TOLIB(MYLIBBAK)
NEWOBJ(PGMORD01)
A program or file duplicated before you touch it turns a restore into a one-second job instead of an hour. It matters most for data files, where CRTDUPOBJ with DATA(*YES) brings the records across too.
The part almost nobody does
An unverified backup is a hypothesis. The checks worth putting in the calendar:
Check the job succeeded, not just that it ran. The job log holds the completion messages with the number of objects saved and, more importantly, those not saved. An object in use at save time is skipped: the job reports as finished, but that object is not in the backup.
Try a real restore. You do not need to stop production: restore a library into a test library.
RSTLIB SAVLIB(MYLIB) DEV(*SAVF)
SAVF(BACKUP/SAVMYLIB)
RSTLIB(TESTMYLIB)
If that command works and the data inside is what you expect, the backup genuinely exists. If it has never been tried, you are hoping.
Measure how long it takes. The restore time for a large library, multiplied by the number of libraries, gives the order of magnitude of the disaster. It is a number better known in advance.
If the estate is large, there is BRMS
Handling tape rotations, incrementals and expiry by hand becomes unmanageable quickly. Backup, Recovery and Media Services is the IBM product that takes care of it: it keeps the catalogue of what is where, manages media rotation, and can tell you, given an object, which save it is in. It is separately licensed, and it makes sense once the number of libraries and volumes exceeds what one person can remember.
The bare minimum
If there is time for nothing else, at least these three:
- A periodic
GO SAVEoption 21, onto media that leaves the room. - A daily save of the application libraries, verified by reading the job log.
- One test restore a year, with the time recorded.
The third is what turns a hope into a certainty.
Which versions this works on
SAVLIB, RSTLIB, SAVOBJ, RSTOBJ, SAVCHGOBJ, CRTSAVF, CRTDUPOBJ, GO SAVE — long-standing commands, present on every release in use and with the same underlying behaviour. This area changes little precisely because recovery rests on it.
BRMS (Backup, Recovery and Media Services) is a separately licensed product, not part of the operating system. It has to be bought and installed separately, and is available for all supported releases.
What does change between versions is mainly the media and destination options — save encryption, saving to cloud, BRMS functions — and the details of a full restore, which also depend on the machine model.
For a total restore, do not rely on an article, not even this one: IBM publishes the Recovering your system manual for each release, and that is the document to have printed before you need it. You will find it in the sources.
Comments
No comments yet. Be the first to comment!
You need an account to comment. Log in · Sign up