How to use a journal for disaster recovery
Journals, like mirroring, can be used as protection against loss of data from a disk crash. The trade-off is this: Journaling uses a lot less disk space than mirroring, since it is only protecting files (which is where most of the system activity, i.e. data changes, takes place). However, this is also a disadvantage because, again, only files are protected. In addition, set-up and recovery require a few more manual steps. For maximum protection, use the following steps.
Journal set-up and save process
Every critical file (which is most files) should be journaled. You can journal multiple files to the same journal, but use caution when doing so because this will introduce another level of complexity (or confusion, as the case may be). The following describes the steps required to set up journaling for a single file:
- Set up journal(s) as described in Part I and Part II. Put journal and journal receivers in a different ASP than the file they are protecting. If you have never used ASPs before, now is a good time to start. You can keep it simple and just dedicate a small ASP for journaling only. That way you ensure that the file and its associated journal are stored on different disk units. As an added bonus, using a separate ASP for journals will improve performance, compared with putting journals and file in the same ASP.
- Save the file each night. You can stretch this out to every other night or once a week, but to keep journal receivers from getting too big, it is best to save the file each night.
- Create and attach a new journal receiver. This gives the journal a fresh start the next day.
- Save the previous (now detached) journal receiver. This step is optional. It gives you an extra layer of protection. Should anything happen to the file on the saved media, you could reconstruct the file from the previous night's save and the saved journal receiver.
- Delete the previous journal receiver. This is the only way to "clear" the entries in the receiver.
After a disk crash or other failure that renders a file unusable, use the following steps to recover that file:
- Restore the saved file. Use the most recent save media.
- Apply journaled changes to the restored file. Use the Apply Journal Changes (APYJRNCHG) command to perform this step. After completion, the file will be in the same state that it was when the disk crashed. This assumes, of course, that the journal and the journal receiver were stored in a different ASP. Note: The parameter defaults of the APYJRNCHG command are set up for disaster recovery, so you probably won't need to change them.
Restore objects in the correct order
Similar to when you use triggers or referential integrity, when you use journaling and perform a restore you must ensure that certain objects are restored in the proper order so that journaling can be re-established automatically. When you need to restore a file that is journaled, along with its associated objects (i.e., logical files, journal and journal receivers), use the following order:
- Restore the journal object first (but not the receivers)
- Restore the physical file or files
- Restore the any associated logical files
- Restore the journal receivers
To make things simple, put the journal and receivers in the same library as the files. When configured this way, the system will automatically restore them in the proper order if you restore the entire library (using the RSTLIB command). If they are in different libraries and you do not restore the objects in the above order, you will have to re-establish journaling manually, which may include re-attaching receivers and/or restarting journaling for files.
Note: The restore procedure just discussed is only for when you need to restore a file and its associated journal and receivers. In the recovery procedure discussed earlier, we assumed that the journals and receivers did not have to be restored because they were in another ASP and were not affected by the disk crash.
About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years' experience programming for and managing AS/400-iSeries systems.
This was first published in March 2005