Backup and Recovery

Backup and recovery is documented more comprehensively in a separate guide, the Servigistics InService Backup and Recovery Technical Brief. In this deployment guide, only the basic requirements for Servigistics InService backup will be documented.

In addition to the software installation binaries and configuration files, the Servigistics InService data layer maintains 3 data repositories that need to be backed up regularly and synchronized during any recovery event:

• Relational Database (Oracle)

• E3C repository – This is a proprietary XML-based storage repository. Note that in a split configuration where the Publisher is separated from the Viewer(s), unique E3C repositories exist on each, so each must be backed up separately.

• Software binaries (installation and customizations)

The backup and recovery strategy must take into account any optional additional components in your deployment architecture. For example, if there are text-based search indexes that would require a large amount of time to be recreated, the indexing data can be included in the backups.

Software binaries need to be backed up after the initial deployment and each time they are updated. An update can be as small as a single property file change or a large, new build of customizations consisting of many files.

The process for executing backups will vary for each deployment in accordance with the capabilities of the hardware and operating systems used. The following list shows the timing requirements and capabilities for each repository:

• Software Binaries – these can be copied at any time. Backups should be done after any change to the configuration such as deployment of a new build. In a cluster with separate Publisher and Viewer(s), the configuration files from each host must be part of the backup in order to facilitate recovery from total loss of any system node.

• Database – the Oracle database has advanced backup capabilities, including hot incremental backups (see Oracle documentation references in Additional Information section). This is usually configured to occur automatically at periodic intervals. PTC recommends that backups of the production RDBMS be configured to allow for point-in-time recovery (using archivelog mode) in order to adjust the recovery point to match the periodic backups of other repositories. If point-in-time recovery is not allowed by the backup strategy, backups of the relational database must coincide with backups of the LDAP and E3C repositories. The alignment between the relational database and the E3C repositories must be maintained during recovery, so plan backups accordingly.

• LDAP – There are multiple methods available to back up the Windchill Directory Server: export to an LDIF file, snapshots of the database directory, and backup commands for full or incremental backups while the system is online (hot).

• E3C Repository – These directories are signified by values of “enigma.data.home” and “enigma.work.home” in the E3C.properties file on each host. They must be copied to another device for backup. In a cluster where Publisher and Viewer nodes are separated, backup the directories separately.

The repository cannot be backed up while TAL activity is occurring. Check the Task Monitor if necessary to make sure there are no activities marked “In Progress”. The example below shows what a Transform and Load or PublishToPreview task looks like when it is “In Progress”.

Scheduled backups of the E3C repository (data or work directories on both Publisher and Viewer nodes) must not occur when a Full or Incremental TAL process is running. Coordination of the scheduled incremental publish from an authoring system such as SIM/SP should also take the backup schedule into account.

In order to perform regular scheduled backups, a system administrator will need to perform testing in order to determine how much time incremental PxTAL activities require on a daily basis, and then determine the backup schedule that best fits the requirements for Recovery Point Objective. Multiple, incremental PxTAL processes during the day will be smaller sized and take less time, allowing for smaller RPO values due to more frequent backups. Administrators should include the software logs in the backup so that they can be checked to validate the backup if necessary.

• If you have a storage system failure, for example one half of a mirrored storage device has gone off line, no rollback is required. Break the mirror and point the system storage at the functioning half using the E3C.properties files before restarting.

• If corruption has occurred, the system will need to be rolled back to the last valid backup that predates the corruption. If there are questions about determining the recovery point, contact PTC Technical Support for assistance. Note that if the recovery point is prior to the last PxTAL process between authoring and Servigistics InService, objects in authoring may need to be republished, or the authoring system can also be rolled back.

• Recover the database to any point in time within the interval of the last valid E3C repository backup. The interval extends to the start of the next set of TAL procedures (which would modify the E3C repository).