My question is about the AS/400 and SAVSYS. Is it true that a daily backup process backs-up everything that has changed since the last SAVSYS? I’m being told that all changes (including data, programs and patches) are backed up as part of the daily backup. They also tell me that the daily backup includes configuration data and security data, plus QGPL, QUSRSYS and QUSRBRM. They claim that bringing the system down, is not required for this daily backup process. What’s the real story?
Software/Hardware used:
ASKED:
August 31, 2009 1:43 PM
UPDATED:
October 10, 2009 11:46 AM
By your description, it sounds like a in house program running a SAVCHGOBJ which will save everything since the last Full Save(which includes a SAVSYS).
SAVSECDTA saves security data (user profiles, etc)
SAVCFG saves configuration data (ctls, lines, etc)
You didn’t mention the IFS or DLO which may need to be saved as well in your environment.
If you’re involved in the backup process, you should confirm this with the developement staff or the admin. You can also verify by viewing the joblog of the backup job and by your QHST log.
On iSeries there are a lot of save and restore commands. Some of those will require that the system be placed in “Restricted State” (SAVSYS).
There used to be or still is a nice document from IBM called “Are you saving the right stuff?” .
Visit http://www.ibm.com/services/continuity for more info.
Your must understand the Backup process in AS/400 first
The SAVSYS would backup
- System object Licensed Internal Code, Operating System, Security Data(userprofiles) and Configuration (Devices)
And required the restriced state because you con’t backup OS while it running
(End subsystem user con’t access)
But another user objests (programs, database) doesn’t required the restriced state
QGPL, QUSRSYS and QUSRBRM also included in Library *ALLUSR
The solution for backup any thing but OS and not in restriced state
1. Security data using SAVSECDTA command for backup user profile and security
2. Configuration data using SAVCFG command for backup configration and devices
3. All user data using command SAVLIB LIB(*ALLUSR)
BUT BUT BUT
As you know, the on-line backup the object locked (in used) may be cause of uncompleted backup process the DSPLOG or spooled file from backup process would guide you which object was not saved
Good luck
The answer to your question should be “it depends” – You did not specify any details as to how your system is set up or configured. You mention the QUSRBRM library, but do not mention if you are using BRMS or native save commands. You’ll need to provide a bit more information for a more detailed response.
You do not need to bring the system down daily to save MOST data, however, there are some data sets that do require the system to be either fully or somewhat restricted. As mentioned by Whatis23, IFS data may need to be saved. This data set can be tricky to capture, considering all the applications that are using it.
Your question really needs to be “Am I saving everything I need in an unrestricted environment?” and only you (or your system admins) can determine this by looking at the job logs for the backups and determining whether or not objects are in use at the time of the backup. You also must consider the frequency of saving patches and such because if you’re only loading them once a week, then you may only need to save them once a week. SAVCFG is another one that you may or may not need to worry about on a daily basis. How frequently are you changing your configuration data?
Your backup strategy needs to be what the business demands it to be. If you are only worried about “user” data, then as long as the items are not locked at the time of the backup by a user or a process, then you should be getting all changed objects with the SAVCHGOBJ command. You really need to look at the program or application configuration for your save to better determine if everything you need is being saved.
Pepper who told you that is what your saving? From your statement it appears that you don’t know a whole lot about the 400. A daily backup could be anything! What do you mean by a daily backup? There is no such thing as daily backup on the 400. Let me give you an example: I create a CL program. Within the program I have specify to backup my production libraries. Well, because I want to backup these libraries on a daily basis I want to call this program DailyBackup. I then schedule this program to be run everynight Monday thru Friday. Later on I decided that I want to also backup some data from the IFS system and I want to backup this data on a daily basis. So, what do I do? I include a statement within my CL program to backup the data from the IFS system on a daily basis. As you can see you can tell the program what you want to backup and how do you want to back it up. So, the question is how do you determine what is been backup, how and when. The most simple way to backup you data on the 400 is by going into the BACKUP menu and working with the options about how, what and when to backup your data. But from what your describing it appears that you have an in-house program running on a daily basis. Your question then should be where is this program? In which library is this program? What is the name of the program? If you know how to locate the program then you should be able to take a look at the program and see what is been backup.
Question, don’t you have any documentation about this? You should have some type of documentation about this so that you can easy locate that information.
Please get back to us if you have any more information or have any more questions.
…all changes (including data, programs and patches) are backed up as part of the daily backup. They also tell me that the daily backup includes configuration data and security data, plus QGPL, QUSRSYS and QUSRBRM. They claim that bringing the system down, is not required for this daily backup process.
With the possible exception of “patches”, yes, it’s perfectly possible. What do you mean by “patches”? Applied operating system PTFs? No. Third-party vendor product updates? Probably. Changes to in-house apps and database? Almost certainly.
Tom