Because the index properties on Image Services and Content Engine are synchronized, the two systems must be backed up at the same time. If the system backups are not synchronized, resynchronization after a restore could become more complicated. Choose a time to make your backups when
When either system needs to be restored, the other system must also be restored to the same level.
The first line of defense against data loss is mirroring or RAID. The last line of defense is backup and restore. To back up a large system, consider mirroring the database server.
To perform a backup
This method avoids bringing the system down for backup and prevents a degradation of performance on the production system during the backup. What is in effect being backed up is the state of the system as it would be if the system had crashed at the time the mirror was broken.
For Image Services systems, you can use Enterprise Backup and Restore (EBR) to back up the system. The backup should be performed while both the Image Services system and the Content Engine system are shut down.
When both the Image Services system and the Content Engine system are backed up at the same time, either system can be restored first. Both systems should be restarted at about the same time.
In general, when a database is restored, the recovery log of the database can be used to roll the database forward in time so that no completed database transactions are lost. The ideal situation after a restore is that the database is rolled forward to the last complete transaction. Then, no work is lost, and production can be resumed.
The roll forward technique does not apply to databases such as the Image Services transient database, however, because the transient database maps data stored in files or partitions, and those files or partitions cannot be rolled forward. When such databases are restored, the files or partitions that they map must also be restored, and updates made since the backup are lost. David?
Fortunately, the Content Engine catalog database and the Image Services catalog database are databases to which the roll forward technique applies. The best practice is to take advantage of database roll forward.
If mirroring or RAID and roll forward have both failed, you could restore the
other catalog database as well. If you have followed best practices and backed
them both up at the same time, the two catalog databases will be synchronized.
However, the work since the backups were made will be missing from both systems.
It is desirable that the restore of one catalog database does not force a restore
of the other. In this regard, several cases must be considered:
For documents entered on the Content Engine system, there is no corresponding catalog entry in the associated Image Services catalog database. Therefore, there is no catalog synchronization issue. Just restore the Content Engine catalog database.
For documents entered on the Image Services system, dual catalog entries must exist until the Panagon applications are switched over completely to the FileNet P8 Platform applications and cataloging to the Image Services catalog is no longer performed. When Image Services cataloging is turned off, there is no catalog synchronization issue.
If the Image SErvices catalog database is restored but not rolled forward, you can import the optical or MSAR transaction log surfaces that were updated after the time the backup of the Image Services catalog database was made.
A query against the Image Services catalog database using the document entry date of the backup and ordered on document number can be made to determine the smallest document number assigned after the offline backup. The permanent database can be queried to determine the next available document number. Documents whose document numbers are in that range are the documents that must be imported. The catalog entries will be recreated from the document properties written to the surface.
The import utility will cause the catalog entries to be inserted into the Image Services catalog database and propagated to the Content Engine catalog database, overwriting any catalog entries that exist in the Content Engine database.
NOTE When there are dual catalog entries, it is important not to update the catalog entries on the Content Engine system. As mentioned earlier, if you update the dual catalog entry on the Content Engine system, you immediately cause it to be out of synchronization with the dual Image Services catalog entry because the update does not propagate back to the Image Services catalog. You can prevent such updates using FileNet P8 marking sets with the property being the Image Services document class number.
Because you should not be updating dual catalog entries on the Content Engine system, there should be no problems, except that updates to the Image Services catalog entries made after the document was committed will be lost. Note also that some deleted documents could reappear.