There are actually two ways to use SAVCHGOBJ, though.
The first way is to specify the reference date and time of the last backup. This is the kind of backup that you were referring to and this is the kind of backup implemented from the GO BACKUP menu. This is called an Incremental Backup. Only data that has changed since the LAST BACKUP (SAVLIB or SAVCHGOBJ) is saved. To restore from this kind of backup, you have to restore your FULL (SAVLIB) backup first and then restore each DAILY SAVCHGOBJ Incremental Backup.
The other kind of backup is referred to as a Cumulative Backup. This kind of backup saves anything that has changed since the last FULL (SAVLIB) backup. Each run of a cumulative backup replaces the previous one. So as the week progresses, a cumulative tape backup will most likely get bigger and bigger and the backup probably will run longer and longer. However, when you need to restore DATA, all you need to do is restore the last full backup and then restore the most current cumulative backup.
The SAVCHGOBJ command is actually defined to do a cumulative backup by default:
Reference date . . . . . . . . . REFDATE *SAVLIB
I'm not sure why the default for the GO BACKUP daily save is to do an incremental instead of a cumulative save. I guess it is implemented this way because it is probably the fastest way to save changed data. If you wanted to do a cumulative backup, you would have to execute the SAVCHGOBJ command from a program of your own.
So it is up to you... faster backup causes a longer, more complicated restore or slower backup gives you a simpler, faster restore process. Only you can decide what is best in your environment.
Now that's not the whole story, though. There are features in OS/400 such as "Journaling" and "Save-While-Active backups" that let you save your data in the least amount of time while still being able to do a cumulative backup. Using these features makes the backup process even more complicated, though. But the time savings can make it well worth the additional complexity.
This is a discussion that goes well beyond your question though. So, I'll stop right here!
Good luck on whatever backup implementation you choose to use. One very important bit of advice though... Develop and TEST TEST TEST your recovery plan. It is always best to discover holes in your backup strategy before you have real disaster recovery event!
MORE INFORMATION ON THIS TOPIC
Visit the ITKnowledge Exchange and get answers to your backup & recovery questions fast.
Search400.com's targeted search engine: Get relevant information on backup & recovery.
Check out this Search400.com Featured Topic on 30 backup/recovery tips in 30 minutes .
Related Q&A from Ken Graap
The only option to correct damage preventing file journaling is to use the RCLSTG command.continue reading
Find out if log files can be omitted during a save without causing problems in a full restore.continue reading
IBM's iSeries Backup and Recovery manual answers many questions related to system backup and disaster recovery.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.