Admin Alerts: Old IBM i Backups, New Tricks

July 9, 2014 Joe Hertvik

If you’re like most IBM i administrators, your backup routine is probably set in stone and you don’t really need to change it all that much. It’s solid and it works. But sometimes things happen and you may need to tweak your backup to accommodate new situations or needs. This week, let’s look at three different scenarios where you might have to change or modify your backup solution.

Our Backup Scenarios

Here are three different backup situations you may encounter that could force you to make some small but significant changes to your backup routines.

Developing a new IBM i partition that isn’t in production yet.
A new auditing requirement to prove that you can restore objects from daily, weekly, or monthly IBM i backups.
Modifying your backup when your backup window starts to shrink.

Let’s look at each scenario and see how it can affect your backup strategy

#1–Developing a new IBM i partition that isn’t in production yet.

True story. A company I worked with in the early 2000s was developing a replacement ERP system on a newly configured IBM i partition. They spent an entire month loading the system, configuring it, adding third-party software, and readying it for testing. Ten people were working on the project. Tens of thousands of dollars were spent developing the new partition. And there was a deadline for getting the partition up and running.

One day the system crashed and the shop needed to roll back a number of changes and restore the development partition to a previous version.

And that’s when we found out. . . whoops, no backup.

The IT Ops Manager (not me) decided that since this was a developmental system and not production, there was no rush to get a regular backup plan in place. A whole month went by while he fiddled with the great new backup strategy for this partition. Meanwhile the system crashed and we lost a whole month of work we weren’t able to get back. We had to start over again.

The morale of this story is: Don’t fool yourself into thinking that development systems can do without rigorous backup plans. If anything, development systems need more backup than a production box for one simple reason.

A development system isn’t as stable as a production system.

Software and operating system changes happen more quickly on a development box than on a production box. In some shops where the production software and the operating system change slowly, you may be able to get away with just backing up your data during the week and then backing up your entire system including programs and the operating system only on weekends.

Development partition backup objectives are the exact opposite of what you’re aiming at with a production system.

With a development box, data is less important than in the programming environment because data can always be refreshed or reloaded. Daily programming, configuration, and operating system changes happen much more often, and they can’t be reloaded if you haven’t implemented a solid backup plan.

If you’re not backing up your development OS and programming changes occur every day, you run the risk of losing them in the event of a system failure. Don’t be like the stupid IT Ops manager mentioned here. Back up your development and in-process systems on a regular basis so you don’t get burned if a system failure occurs.

#2–A new auditing requirement to prove that you can restore objects from daily, weekly, or monthly IBM i backups.

Here’s a classic question that auditors ask about production system backup.

“Do you have proof that the backup works?”

You may have the slickest backup procedure in the world, but it won’t do you any good if you’re not able to restore IBM i objects from your backup media. In addition to running and documenting regular backups, it’s a good idea to test restoring objects from your backup media just to prove your backup is working.

In one shop I worked in, object restoration documentation was a requirement for our Sarbanes Oxley auditing. In addition to using job logs to document the backup was working, we performed a test restore from the backup media at the end of each backup.

Performing these two steps produced documentation that: 1) the backup worked; AND 2) that we were able to successfully restore from the backup media we produced. We verified that the media was written correctly and ready to go, in the event something needed to be restored.

#3–Modifying your backup when your backup window starts to shrink.

If you’re running production 24x7x365 and can’t get regular full system backups (FSBs), here are three ways you can adjust your backups to compensate for a busy production system.

1. If you have a replicated High Available (HA) system, backup your data from the HA box–If you’re replicating all of your data and programs to a Capacity Backup (CBU) system or a clustered system, you can perform user data backups from the replicated data rather than from the production system. Your replicated data will be current per your Recovery Point Objective (RPO) and you’ll be able to backup production data without taking down your production system.

2. Backup your system data only on a regular basis using a GO SAVE 22 backup (System data only)–An option 22 save puts the system in restricted mode and only backups the following objects during a save operation.

The partition’s licensed internal code
The QSYS system library
All security objects, including user profiles
All your device configuration objects
All IBM-supplied libraries and directories that don’t contain user data

Option 22 does not backup user data and programs. Since most of your data is tied up in user data, an option 22 backup will run much quicker than a full system backup. You can leverage an option 22 backup to fit into a smaller maintenance window (option 22 requires a restricted system) so that you’ll always be able to backup your IBM operating system and related objects.

3. Backup high change IBM system objects without restricting your system–Most of the items in an option 22 backup are relatively static. Your licensed program data, system library (QSYS), and IBM-supplied libraries don’t change that often. The only things in an option 22 backup that change on a regular basis are your security objects (including user profiles) and your device configuration objects. The good news is that you can back up security objects and configuration objects while the system is active, which allows to keep a current copy of those objects for restoration as needed. Use the following commands to only back up these two types of system objects:

The Save Security Data (SAVSECDTA) command saves all security data while the system is active.
The Save Configuration (SAVCFG) command saves all your device configurations while the system is active.

Putting these three items together, you can perform a full system backup in a smaller backup window by running the following tasks on your production system and on your HA system.

Perform an option 22 backup every few months or as you change your operating system–This will create a baseline for restoring your production operating system from media, if necessary.
Perform SAVSECDTA and SAVCFG commands on a regular basis on your production system–This will save all your security and device configuration data to bring your every-once-in-a-while option 22 backup up to date. In the event you need to restore, you can first restore the baseline operating system from the option 22 backup and then update your restored system with the security data and configuration changes that occurred since the option 22 save.
If you have a replicated HA system, perform regular program data and program library saves or option 21 saves on the HA system–This will save your data for restoration, if needed while keeping your production active.
If you don’t have a HA system, look into save while active strategies for saving user data–Check out my starter save while active backup program in the Related Stories section for a simple introduction to save while active technology.

Joe Hertvik is an IBM i subject matter expert (SME) and the owner of Hertvik Business Services, a content strategy company that provides white papers, case studies, blogging, and social media services for B2B software companies. Joe also runs a data center and help desk for several companies. Joe has written the Admin Alert column for IT Jungle since 2002.