Manage Learn to apply best practices and optimize your operations.

Restoring procedure after using "SAVCHGOBJ"

If I use "SAVCHGOBJ" for my save strategy Monday through Friday and I need to restore an object from the Friday backup, why is it necessary to restore starting from Monday through the Friday backup? We want to shorten our backup window by saving changed objects, but we're leery about such a seemingly extensive restore procedure. Can you shed some light on this?
You made a good choice using SAVCHGOBJ between full backups. It can significantly reduce the amount of time spent doing daily backups. It does, however, increase the amount of time needed to restore. This is a good trade off though as you will always spend much more time saving data than restoring it.

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!


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 .

Dig Deeper on Data backup, storage and retrieval on iSeries