In any disaster recovery situation, the data backup / replication recovery options can be summarized as:
In all three of these options, there are some timing considerations that will impact what work can be done in advance, and what would have to be done last minute.
Release: All supported releases.
For option 1, the main utilities involved would be the IDMS BACKUP and RESTORE. Copies can be made of data areas or files from one CV using the BACKUP utility. For this to execute successfully, the CV must either be down or the areas to be backed up must be offline to the CV. If the originating CV is used 24/7, then a "Hot Backup" could be taken. The technique for taking "Hot" backups is documented at Backup Procedures.
The backups produced using the above method could then be placed into the Disaster Recovery (DR) environment using the RESTORE utility. As with the BACKUP, the CV would need to be inactive, or the areas varied offline to the CV, when the RESTORE was run.
For option 2, IEBGENER or similar utility could be used to back up disk packs from one LPAR to another. That is effective regardless of whether there is an active CV on the target LPAR. The only stipulation would be the same as noted above – when the copies are made or when they are used to populate a new DASD, the CV referencing those volumes must either be inactive or the areas referencing those volumes must be varied offline to the CV.
In planning the backup and recovery strategy, a few considerations are important:
Obviously, these questions are related, and the answer to each may influence the answer to the other.
If backups are taken with adequate frequency to satisfy the recovery needs, so that it is not necessary to update the DR databases with any updates performed in the origin CV after the backup was taken, that is the simplest scenario. In that case, the only processes that are involved are the ones outlined above: either the BACKUP and RESTORE utilities, or the IBM DASD manipulation utilities.
If it is necessary to update the DR CV with any database updates that were performed on the origin CV after the backups were taken, then the archive journal files from the origin CV must be used to accomplish that. This will require using the ARCHIVE JOURNAL and ROLLFORWARD (and possibly ROLLBACK) utilities to process the journal files from the origin CV and to apply those changes to the database on the DR CV.
If using "hot" backups, then the archive journal files are also needed to ensure that all the updates were up-to-date.
If any local mode jobs were run on the origin CV after the backup was taken, those updates will not be on the journal file. So those jobs would need to be re-run against the DR CV, possibly interspersed between multiple ROLLFORWARD and/or ROLLBACK jobs, to ensure that the exact timing of the updates on the origin CV is duplicated on the DR CV.
The IDMSDBAN utility should also be used to ensure the data integrity on the target CV after having applied any journal transactions, and before bringing up the target CV.
The third option that was originally noted is using 3rd party software. Some IDMS sites clients do use third-party software to manage this process; but that is used most often when near-instantaneous recovery is required, so that journal updates on the origin CV are almost instantly replicated on the target CV. If that is required, then the best approach is to post a question to the IDMS Community site asking who has this requirement and what software they use to manage it.