NOTE: This procedure assumes that the Main (rebuilt) Primary system is configured as it was prior to the performed failover as well as Carbonite (Double-Take) application is installed and its services are running but the PrinergyDB and PrinergyDbRestore Replication sets are NOT CREATED. However, if Primary was fixed w/o redeploying new image, make sure these two replication sets are STOPPED
If this is not the case, rebuild Primary from scratch using the following steps:
- Reinstall and configure the main Primary with the same Windows OS and Prinergy version as before, matching EPM+ server. H/W Options:
- From a saved Ghost: If the saved (ghost) image is matching the current running EPM+ Windows OS and Prinergy version, restore the server using that saved image and go to step 2. If Prinergy version is inferior, upgrade Prinergy.
- From scratch: Deploy WIM image of current running EPM+ Windows OS and Prinergy version. If Prinergy version is inferior, upgrade Prinergy.
Note: You may need to release the License ID in PLAS.
2. Restore the Prinergy Configuration from the latest available Prinergy daily backup by using the rehost tool. You must keep the same server name and IP address as prior to the failover. There’s no need to restore the database with the rehost tool.
3. Install Carbonite (Double-Take) but do not create the PrinergyDB and the PrinergyDbRestore Replication Sets.
Very important Note: Creating the PrinergyDB replication set on the Primary might break the entire database restore.
4. Check for successful starting/running Prinergy on the main Primary.
After the main primary server is repaired, revert to using it as the primary server and using the Hot Standby server as a secondary server.
...
- On the primary server, log into Double-Take Console, and confirm that the PrinergyDb PrinergyDB replication job is stopped.
Important: You must disconnect the PrinergyDb PrinergyDB replication job otherwise the database will be corrupted. - Stop Prinergy on all servers.
- Verify that the primary server's network cable is connected.
- On the failover server, switch the failover server to a secondary server again by selecting Administrator > Revert to Secondary.
Note: To save time when performing test with large databases, you can skip the remaining steps which restore the Oracle data files. However, any work done while the system is in failover mode is lost.
Important: Take a cold database backup of the failover server database in case the restoration procedure is not followed correctly causing database corruption:- On the failover server, make sure the Oracle services are stopped. The Revert to Secondary operation should have stopped the Oracle services but confirm this before taking the cold backup.
- Make a copy of the
C:\Oracle\oradata
folder and theJ:\Oracle
folder
- Run the
DisableOracle.cmd
script and verify that there are no errors.- On the primary server, run the
DisableOracle.cmd
script, located at <SystemDrive>:\Program Files\Vision Solutions\Double-Take\creo\
. When prompted, confirm that you want to stop and disable Oracle. - Check the output of the
DisableOracle.cmd
script for errors. If there are errors, do not proceed. Contact your service representative.
- On the primary server, run the
- Enable the PrinergyDbRestore job, by performing the following actions:
- On the failover server, in the Double-Take Console, select Manage Jobs.
- Under View Job Details, confirm that Target route is set for primary server IP address
- Right-click the PrinergyDbRestore job, and select Start.
- Wait for the Activity to become Protecting and the Mirror Status to become Idle.
- Right-click the PrinergyDbRestore job, and select Stop.
Note: If there is an unexpected interruption, such as a power outage, you can restart the restore process from the step to runDisableOracle.cmd
and onwards. The restore process overwrites the unusable database on the primary server with the still-good copy from the failover server.
- On the primary server, start Oracle by running the
EnableOracle
script at<SystemDrive>
:\Program Files\Vision Solutions\Double-Take\creo
. - From the primary server, start Prinergy on all servers. Ensure Prinergy is operating properly before proceeding to the next step.
- Reconfigure Double-Take to replicate the data onto the failover server again by performing the following actions:
- In the Double-Take Console, select Manage Jobs.
- Right-click the AraxiDb PrinergyDB job and select Start.
- Wait for the Activity to become Protecting and the Mirror Status to become Idle.
- If an InSite Prepress Portal or InSite Storefront server is connected to the Hot Standby server, redirect the InSite server to the primary server:
- From the Start menu on the InSite server, select Run.
- Type
ICU
, and click OK. - Press Enter to stop InSite.
- In the InSite Configuration Utility wizard, click Next until the Prinergy primary Server Information dialog box appears.
- Type the Primary Server Name and IP address of the primary server.
- Click Next until the Configuration Summary window appears, and click Apply.
- Click Next until the Diagnostics dialog box appears, and click Close.
- At the command prompt, type:
net start InSite
exit
- Restart Prinergy services, and verify that the InSite system is operating properly.
- If Creative Workflow server or Business Link-based software (running on a separate server) is connected to the Hot Standby server, redirect them to the primary server. See the user documentation for this software, or contact your service representative.
- If Rules Based Automation is used, switch any dependencies on the hot standby server back to the primary server:
- If remote triggers are used between rule sets, redirect these remote triggers back to the primary server.
- If remote triggers are coming from external systems, redirect these remote triggers to the primary server.
- Once confident that everything is working correctly, perform the starting database replication procedure.