In any disaster recovery situation, the data backup / replication recovery options can be summarized as:
1- Replicate the data using IDMS standard utilities;
2- Replicate the data using IBM-provided DASD backup utilities;
3- Use third-party software to manage the data replication.
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.
For option one, 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. Details on using these are documented in the IDMS Utilities manual. If the originating CV is used 24/7, then a "Hot Backup" could be taken. The technique for taking "Hot" backups is documented in the IDMS Database Administration Guide.
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 & recovery strategy, a few considerations are important:
1- How frequently are backups taken?
2- Is it adequate to recover to the most recent backup, or must the target CV also be updated with any transactions that have occurred on the originating CV since the backup was taken?
3- Are local mode update jobs run on the origin CV? If so, must those updates also be incorporated into the DR planning?
As you can tell, 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 & 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 you will be using the journal files from the origin CV to accomplish that. This will require that you use the ARCHIVE JOURNAL & 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. Details on using these utilities are in the IDMS Utilities manual;.
If you are using ‘hot’ backups, then you would need to also need the journal files 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 &/or ROLLBACK jobs, to ensure that the exact timing of the updates on the origin CV is duplicated on the DR CV.
You will probably also want to use the IDMSDBAN utility to insure the data integrity on the target CV after you have 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 your goal, then the best approach is to post a question to the IDMS User Community on the CA Communities site asking who has this requirement and what software they use to manage it. You will probably get much more detailed information there than CA would have, about what people are using to accomplish this.