Duplicating your data, or how to backup
|
This article isn't finished yet or needs to be revised. Please keep in mind that thus it may be incomplete.
Reason: Make complete. |
As with any other computer system, things can go wrong and valuable data might be unrecoverable. So it's proven best practice to duplicate your data in a way that survives all the wrongness which can happen.
Basics
No matter which platform, it's important to keep one thing in mind:
- You're not doing backups to (only) sleep well. You're doing backups for the sake of a speedy and stressless recovery to the latest point in time, aka the last backup!
The last thing you wanna deal with after something bad happened is to bootstrap yourself out of nothingness into a complicated, error prone, and slow process of copying backups from here to there until you finally can restore the data from there.
Also, don't forget that installing and patching an OS is also a very time consuming process. Thus, the best backup you can have according to the quote above includes the operating system.
How?
A proven way to be on the safe side is to do
- periodical full backups, maybe each week, each month or before doing grave changes to the system configuration
- daily backups of data having changed since the last full backup
Full backups, or a Save 21 requires the system to be in a restricted state. This permits the backup to contain a consistent set of data for a given point in time, because nothing is changed while the backup runs. What's more, restricted state closes (most) files, so the backup program does not fail to access files being in use.
OS/400 has everything one needs to save, and restore.
Scripts
Daily backups should be automated and tailored to individual needs. This can be done with CL programs. CL is akin to shell scripts or batch files in other OS's, but they're compiled.
Daily backup to an ISO image
This example is in daily use with a machine in a DC. Since there's nobody to change tapes in a daily manner, incremental saves go to ISO images. These are copied to an FTP server (and compressed there by a locally run cronjob).
PGM
DCL VAR(&OPTDRV) TYPE(*CHAR) LEN(8) VALUE(OPTVRT01)
DCL VAR(&SYSDAT) TYPE(*CHAR) LEN(6)
DCL VAR(&OPTDAT) TYPE(*CHAR) LEN(10)
/* Create Image Catalog and Image */
CRTIMGCLG IMGCLG(BACKUPS) DIR('/backups') CRTDIR(*YES) ADDVRTVOL(1) IMGSIZ(10240)
LODIMGCLG IMGCLG(BACKUPS) OPTION(*LOAD) DEV(OPTVRT01) WRTPTC(*NONE)
LODIMGCLGE IMGCLG(BACKUPS) IMGCLGIDX(*FIRST) OPTION(*MOUNT)
/* Initialize with current date */
RTVSYSVAL SYSVAL(QDATE) RTNVAR(&SYSDAT)
CVTDAT DATE(&SYSDAT) TOVAR(&OPTDAT) TOFMT(*YMD) TOSEP(*NONE)
INZOPT DEV(&OPTDRV) NEWVOL(&OPTDAT) MEDFMT(*UDF)
/* Actually save */
SAVCHGOBJ OBJ(*ALL) LIB(*ALLUSR) DEV(&OPTDRV) VOL(&OPTDAT) ENDOPT(*UNLOAD) +
SAVACT(*SYSDFN) SAVACTWAIT(10) DTACPR(*LOW) OMITLIB(SAVRST) OUTPUT(*PRINT)
MONMSG MSGID(CPF3778)
MONMSG MSGID(CPF9845)
MONMSG MSGID(CPF3794) EXEC(GOTO CMDLBL(SENDMSG))
/* Close Image file properly */
LODIMGCLG IMGCLG(BACKUPS) OPTION(*UNLOAD) DEV(OPTVRT01)
/* Upload to server */
OVRDBF FILE(INPUT) TOFILE(QUSRSYS/FTP$BKUP)
OVRDBF FILE(OUTPUT) TOFILE(QUSRSYS/FTP$LOG)
FTP RMTSYS(SRVBACKUPSTORAGE)
DLTOVR FILE(INPUT)
DLTOVR FILE(OUTPUT)
/* Cleanup Image catalog */
DLTIMGCLG IMGCLG(BACKUPS) KEEP(*NO)
GOTO CMDLBL(END)
SENDMSG:
SNDMSG MSG('Error happened. Bailing out.') TOUSR(QSYSOPR)
END:
ENDPGM
/* vim: syntax=clp colorcolumn=81 autoindent */
The above save mechanism does not care about IFS objects, nor does it save document library objects. These two separate saves are spared, because in this case, the IFS and DLO isn't really used. It's completely sufficient to save them each month with a save 21.
As you can see, to automate the FTP process, OVERDBF is called for backups and logs. The content of QUSRSYS/FTP$BKUP is as follows:
username password bin namefmt 1 mput /backups/* quit
- username
- The user for the remote FTP server
- password
- The user for the remote FTP server