You need a backup strategy to test your company’s disaster recovery plan and, despite its reputation for reliability, administrators still need to back up their IBM i. A sound backup strategy should also restore individual user objects to account for human error. Seven save commands are required to successfully back up your system: SAVSYS, SAVCFG, SAVSECDTA, SAVLIB, SAVCHGOBJ, SAVDLO, and SAV. Make backup a snap by familiarizing yourself with these save commands and optimal frequency.
Save Commands for Your System
The Save System (SAVSYS) command is used to back up licensed internal code, operating system, profiles, configuration objects, and authorities to objects, and must be run in a restricted state. SAVSYS is best done after hours or on weekends, usually once a month or after a major operating system upgrade, after installing licensed programs, or after installing program temporary fixes (PTFs).
Save Configuration (SAVCFG) and Save Security Data (SAVSECDTA) back up the dynamic part of the operating system. Both commands can be executed with users on the system. SAVCFG backs up configuration objects, such as lines, controllers, and devices. SAVSECDTA backs up profiles and the authorities that profiles have to objects. It’s a good idea to run these commands nightly, especially on a system with many users and devices.
Save Commands for Your Business Data
The Save Library (SAVLIB) and Save Changed Objects (SAVCHGOBJ) commands back up the data in the library file system. Use these two commands together to provide complete backups of your libraries. SAVLIB backs up an entire library while SAVCHGOBJ backs up only the objects that have changed since the last SAVLIB. How often you run these commands depends on how often a library changes. Best practice is to do a SAVCHGOBJ against data, source, and program libraries on a daily basis, and to save all libraries completely using the SAVLIB command once a week.
With the Save Document Object (SAVDLO) command, you can back up the entire set or specific documents and folders—often office documents and PC files—stored in the library QDOC or QDLS directory. This command also backs up only documents and folders that have changed since the last full SAVDLO. How often you run a SAVDLO depends on how frequently the documents and folders change. While best practice used to be a daily run, in recent years QDOC and QDLS have become the least used areas for storing data, so you may be able to get away with backing up once a week.
The Save Object (SAV) command is used to back up directories on the IBM i. Even for savvy IBM i veterans, the SAV command can cause some confusion because it uses UNIX/Windows syntax when referring to objects such as tape drives. Use the SAV operation weekly against any IBM i directory to back up this data, daily if IFS directories change often in your environment. The directories can be used to store images, PDFs, scanned-in documents, UNIX file systems, and more. This is a very important area that needs to be part of your daily plan. It supports many of the same parameters the other save commands do.
In addition to the save commands, use these tips to avoid common mistakes:
- Use appropriate capacity hardware devices for backup
- Use mirrored and RAID disk units to reduce the chance of hardware failures
- Use CBU systems for high availability and do your saves on the secondary system
- Use IBM i journaling of physical files
- Use the save-while-active feature
- Perform backups when no one is using the system
- Make sure you have an off-site storage facility for your media
- Incorporate virtual tape libraries (VTL) and avoid offsite all together
- Maintain multiple rotations or generations for similar backups
- Keep your security profiles in a safe place
- Maintain a control language procedure (CLP) of any changes you’ve made to IBM i, which can be called to reestablish those changes if you need to restore on another system
- Automate restricted state operations with your own or purchased software
There are some objects on the IBM i whose contents can’t be saved. These include data queues, journals, message queues, user queues, and logical files. The contents of logical files are actually backed up when you specify Save Access Paths *YES for either the SAVLIB or SAVCHGOBJ commands for physical files.
As an administrator of backups, you need to be aware of the parameters that affect performance and try to modify them to get the most out of your system with as little downtime as possible. The faster your CPU and tape drive, the faster your backups, but not everyone can afford to buy a bigger system so their backups run faster. A new tape drive or VTL, however, may be a good investment.
Work management also affects the performance of your save in terms of memory pool size, machine pool, and number of activity levels. It’s easy to overlook these issues when we’re having performance concerns with backups. If performance isn’t an issue, you can simply do a SAVSYS, SAVLIB LIB(*NONSYS), SAVDLO, and SAV. Use option 21 from IBM’s SAVE menu and save the entire system. Do this nightly if performance and downtime aren’t an issue.
The size of data and the types and number of objects affect the speed of your backups. Objects with a lot of members are often slower to back up than a single, large object. Try splitting your backups into more than one backup job. Or simply back up only the object libraries that change instead of all libraries. Both are ways of cutting down on the number of objects you’re backing up.
The authority of the user running the backup also can affect backup performance. If your backup profile has all object authority, the system doesn’t need to check if you have authority to the objects being back up, resulting in one less operation for the system.
Restricted state is the fastest way to back up any library because the operating system doesn’t have to check for object locks. It just assumes that the library is totally free for a backup operation.
With these tools and considerations in mind, put your backup strategy to the test.
Downtime comes in many forms and it doesn’t take a full-on disaster to destroy your data. This guide shows you what you need in order to build a strong recovery strategy that your business can really rely on.