Backing Up

Backing up is a very important part of daily operations. The i5/OS has a different save command for each type of saving operation. Most of these save commands are complicated and have many parameters. This chapter explains the basic operations in enough detail to get you started. Always remember to:

• Have enough initialized tapes to complete your save operation. The system lets you initialize during the save operation, but doing so can be complicated.

• Give *SAVSYS special authority to those users who need to perform any kind of save or restore operation.

• Most save commands have a few parameters in common:

• DEV, where you enter the name of the tape device you want to use for this save operation. You can also enter *SAVF if you would rather save to a save file on disk. Save files are described later in this chapter.

• VOL, for the volume ID of the tape you are using. Although you can be specific, you should use *MOUNTED whenever possible. This special value means "whatever tape is currently mounted on the drive."

• TGTRLS. If the restore is going to be performed on a system that is running under an earlier release of OS/400, you must use TGTRLS to indicate which release. The special values *CURRENT and *PRV refer to the release you are running and the release immediately prior to yours, which may not necessarily be the last release you had installed. You can also indicate specific releases in the format VxRxMx, where the x's indicate version, release, and modification numbers. To use this option, you also must make sure that the object, when created in your system, was created with the same TGTRLS parameter in the appropriate CRTXXX command. You will be able to restore the object to any system that is running the target release or any subsequent release.

• ENDOPT controls what happens to the tape when the save operation is complete. You can choose between *REWIND (the default, which rewinds the tape but keeps it in the drive), *UNLOAD (rewinds the tape and unloads it), and *LEAVE (no rewind: the tape stays in the same spot where it ended the save).

• STG. Do not use STG (*FREE). The *FREE option clears the objects from your system as they are saved. If you save a file with the *FREE option, your system copies the file to the tape and clears the file as it does so, which leaves you with an empty file.

Tip 

Backing up is no guarantee that you will be able to continueoperations if something goes wrong. You should have a disaster recovery plan in place (refer to the section titled "Disaster Recovery Planning" in this chapter). At the very least, you should keep some of your backup tapes off-site, so that, if a fire or a flood occurs, your tapes will still be usable.

Saving Libraries

You save a library using the Save Library (SAVLIB) command. When you save a library, the system copies the entire library (directory and all objects contained in it) to the device you have specified. Here are some examples:

      SAVLIB LIB(FRED) DEV(TAP01) 

This command saves library FRED using tape device TAP01.

      SAVLIB LIB(ARLIB APLIB) DEV(TAP01 TAP02) 

This command saves libraries ARLIB and APLIB, using tape device TAP01. When the tape in TAP01 is full, the system automatically switches to TAP02 while TAP01 rewinds.

      SAVLIB LIB(*NONSYS) DEV(TAP01) 

This command saves all nonsystem libraries to TAP01. You need to end all subsystems to run this command.

      SAVLIB LIB(*ALLUSR) DEV(TAP01) ENDOPT(*UNLOAD) 

This command saves all user libraries to TAP01. When done, it unloads the tape from the tape drive.

Tip 

You can also use Operational Assistant's Backup List to automate the process of backing up your libraries on tape. For more information about Operational Assistant, see Chapter 7.

Saving Access Paths

You can greatly reduce the amount of time it takes to restore files if you also save the access paths of the files. If you don't save the access paths with the files, the system will rebuild the paths when the file is restored. The users cannot be using the file while the access path is being built. The save will take a little longer, but the time saved when restoring the file will definitely make up for the time lost. Here is an example of a command to save a library and the access paths of the files in the library:

      SAVLIB LIB(LIB1) DEV(TAP01) ACCPTH(*YES) 

Saving Individual Objects

If it is not necessary, you don't need to save an entire library. You can save individual objects using the Save Object (SAVOBJ) command. Here are some examples:

      SAVOBJ OBJ(EMPLOYEES) LIB(ACCTG) DEV(TAP01)      OBJTYPE(*FILE) 

This command saves file EMPLOYEES from library ACCTG to tape. Note that the SAVOBJ command does not use qualified names in the OBJ parameter.

      SAVOBJ OBJ(AR*) LIB(ARLIB) DEV(TAP01) OBJTYPE(*ALL) 

This command saves to tape all objects (regardless of type) that have names beginning in AR, in library ARLIB.

      SAVOBJ OBJ(AP001 AP002 AP003) LIB(APLIB) DEV(TAP01) +      OBJTYPE(*DTAQ *DTAARA) 

This command saves to tape objects AP001, AP002, and AP003 from library APLIB, whether they are data queues or data areas.

      SAVOBJ OBJ(QRPGSRC) LIB(PGMLIB) DEV(TAP01) OBJTYPE(*FILE)      +FILEMBR((QRPGSRC (INV001RG INV002RG))) 

This command saves to tape members INV001RG and INV002RG from source file PGMLIB/QRPGSRC. The command doesn't save anything else and can be used for database files as well.

Saving Changed Objects

One way to save time when doing your backups is to save only the objects that have changed since the last time you performed a complete SAVLIB, or since a given date. These methods are referred to as incremental backup and differential backup, respectively. i5/OS supports these backups with the Save Changed Objects (SAVCHGOBJ) command.

The key to the SAVCHGOBJ command is in two parameters: REFDATE and REFTIME, where you enter the cutoff date and time. If an object has been changed after that date/time combination, it will be saved by the SAVCHGOBJ command.

REFDATE can contain either an actual date, such as 050399, or the special value *SAVLIB, which is the default. If you use *SAVLIB, SAVCHGOBJ saves all objects that have changed since the last complete SAVLIB.

REFTIME lets you pinpoint the cutoff time. You can enter an actual time, such as 130000 for 1 o'clock in the afternoon, or use the default value, *NONE.

Here are two examples:

      SAVCHGOBJ OBJ(*ALL) LIB(*ALLUSR) DEV(TAP01 TAP02) +      OBJTYPE(*ALL) REFDATE(*SAVLIB) REFTIME(*NONE) 

This command saves to tape all objects in all user libraries that have changed since the library was saved with a complete SAVLIB. Note that because you use REFDATE(*SAVLIB), the REFTIME parameter is irrelevant, and the value is *NONE.

The above command also stipulates that the save operation be performed on the tape currently mounted on tape device TAP01. When the tape ends, the save continues on tape TAP02 while TAP01 rewinds.

      SAVCHGOBJ OBJ(PR*) LIB(DATA) DEV(TAP01) OBJTYPE(*PGM) +      REFDATE(050399) REFTIME(083000) 

This command saves all programs in library DATA that have names beginning in PR, if they have been changed since May 3, 2005 at 8:30 in the morning.

Saving While Active

In today's business world, it is not at all uncommon to need access to the computer 24 hours a day, 7 days a week. This requirement is usually at odds with another requirement: that of regularly backing up your files.

Normally, saving an object mandates that you not use the object while you are trying to save it. The save-while-active ability lets you begin the save of the object while the object is still being used. The system manages the object locks until it has locked all the objects it intends to save. It then frees up the objects for use while it is saving synchronized images.

The save-while-active function takes a picture of the object being saved at a single point in time. This point in time is called a checkpoint. It actually locks the object (*SHRNUP) until it has obtained this checkpoint, and objects cannot be changed until a checkpoint has been reached. The amount of time the objects are locked to users is called the save outage. You use different features of the save-while-active function to either reduce or eliminate the save outage.

Tip 

You should end those applications that change objects until after the checkpoint pictures are obtained. The system will send a message when it's reached this point. This will reduce your save outage and produce the least negative impact to response time and disk storage.

If you are saving multiple objects, you have different options for synchronization. You can indicate that each object being saved is locked until all objects are locked to the same checkpoint time (full synchronization). You could also indicate that all objects in a library are locked at the same time (library synchronization). With this option, different libraries could be locked with different checkpoint times. The third option is called system-defined synchronization, in which different objects can have different checkpoint times. (This option is not for the faint of heart.)

Tip 

If you are saving nonjournaled objects with the save-while active function, you should not use system-defined synchronization.

A number of restrictions are placed on the use of the save-while-active functions. You should not use this save feature while the system is very busy or short on disk space. It is a resource-intensive function and will degrade the response time of active users while the function is being performed. You shouldn't load, remove, or apply PTFs while running a save-while-active function.

Here is an example of using the save-while-active function embedded in the SAVLIB command. You should first end all jobs that update objects in the libraries being saved. (It is not mandatory that you do this, but it will tremendously reduce the amount of time the save operation takes.)

      SAVLIB LIB(LIB1 LIB2) DEV(TAP01) SAVACT(*SYNCLIB)+      SAVACTMSGQ(QSYSOPR) ACCPTH(*YES) 

If you are considering using the save-while-active functions, you should refer to the OS/400 Backup and Recovery manual for an in-depth discussion of the ramifications. For effective and safe use of this feature, you need to plan out your save and restore strategy in advance.

Saving Documents and Folders

Documents and folders reside in a special library called QDOC, but you should use the Save Document Library Object (SAVDLO) command to save them to tape. Do not use SAVLIB. Here are a few examples:

      SAVDLO DLO(*ALL) DEV(TAP01) 

This command saves all documents and folders onto the tape mounted on drive TAP01.

      SAVDLO DLO(SMITH.DOC) DEV(TAP01) FLR(DOCUMENT/LETTER) 

This command saves to tape document SMITH.DOC from folder DOCUMENT/LETTER.

      SAVDLO DLO(*SEARCH) DEV(TAP01) REFCHGDATE(050399) +      REFCHGTIME(144500) 

This command searches and saves all documents that have been changed since 2:45 in the afternoon on May 3, 2005. It is similar to the SAVCHGOBJ command.

Saving Objects in the Integrated File System

The primary purpose of the i5 is to store relational database tables. However, not all data fits the relational model. Graphical files are good examples. Newer application models, especially those used in web serving, are based on and suited to directory-based systems. For these reasons and others, IBM added support for other file systems to i5/OS. The infrastructure that integrates these disparate file system is the Integrated File System, or IFS.

The IFS includes the relational database management system, DB2 UDB, but refers to it by the name QSYS.LIB. It also includes the folders system, which it calls QDLS. A UNIX-like system called QOpenSys is also present. It is a directory-based system in which file names are case-sensitive. The CD drive may be accessed through the QOPT file system. The primary IFS file system, called root, is much like the system used with Windows-based machines. It may be used as a file system in its own right, but it also includes the other file systems.

To save objects in the IFS, use the Save Objects (SAV) command. The only required parameter is DEV (device). Here are brief explanations of some of the more commonly used parameters:

• DEV. The device to which the data is to be saved.

• OBJ. The objects to be saved or omitted from the save.

• SUBTREE. Indicates whether to save subdirectories and their contents.

When referring to objects from the library file system, you must use a directory-like syntax, and each object name must include a suffix to indicate the type of the object. For example, library ABC is ABC.LIB and file XZY is XYZ.FILE. The following DEV parameter references the TAP01 tape drive:

      DEV('/QSYS.LIB/TAP01.DEVD') 

To save data to save file MYLIB/MYSAVF, specify the following device parameter:

      DEV('/QSYS.LIB/MYLIB.LIB/MYSAVF.FILE') 

The following command, taken from IBM's CL reference manual, shows how to save everything except libraries and folders to tape:

      SAV DEV('/QSYS.LIB/TAP01.DEVD') +      OBJ(('/*') ('/QSYS.LIB' *OMIT) ('/QDLS' *OMIT)) 

Saving the System

It is very important to use the Save System (SAVSYS) command to save the system regularly. The SAVSYS command saves the following items:

• Library QSYS. The save is performed in a format that makes it possible to restore the library using the operating system installation option during an attended IPL.

• All user profiles and the private authorities to objects given to each user.

• All descriptions of devices, controllers, lines, modes, classes of service, connection lists, and network interfaces.

• All office distribution objects, authorization lists, and authority holders you have created.

Tip 

The SAVSYS command always should be executed on a blank tape. To avoid any problems, do not save anything else on the tape used by SAVSYS.

Running the SAVSYS command requires a dedicated system. A dedicated system requires that you are the only one signed on and that no other tasks are running. You must end all subsystems. Here is an example of SAVSYS:

      SAVSYS DEV(TAP01) 

Saving Configuration Objects

Although configuration objects (such as device, controller, and line descriptions) are saved automatically every time you perform a SAVSYS, you can save them independently of SAVSYS using the Save Configuration (SAVCFG) command. You can save the configuration of your system if you have performed many changes (such as installing new display stations and printers) without executing a SAVSYS, which always takes a long time to process and requires a restricted system. Here is an example of SAVCFG:

      SAVCFG DEV(TAP01) VOL(*MOUNTED) ENDOPT(*UNLOAD) 

All configuration objects are saved to the tape currently mounted on the TAP01. When the save operation is complete, the tape is unloaded. There is no way to save individual configuration objects; it is an all-or-nothing affair.

Saving Security Data

SAVSYS creates a backup copy of security information, but few if any installations run SAVSYS daily. To back-up the changes in security that occur between system saves, use the Save Security Data (SAVSEDCTA) command. Like SAVCFG, SAVSECDTA does not require a restricted system. You can use the Restore Authority (RSTAUT) and Restore User Profile (RSTUSRPRF) commands to restore from SAVSECDTA backups.

SAVSECDTA requires only one parameter—DEV. The following command saves security data to the tape drive:

      SAVSECDTA DEV(TAP01)