---
title: "Switching back from DR to Production"
canonical: "https://kb.myframeworks.com.au/space/PROSTIXV48DOC/31100687/Switching%20back%20from%20DR%20to%20Production"
format: markdown
---
Once the failure on the Production server has been rectified and you are ready to recover back to it, the next steps involve bringing the DR Live Database back from the DR server to the Production server and then re-syncing the AI process.  Steps on the DR Server The following steps must be performed on the DR server, with all users off the system, typically at the end of the day: Backup the DR Live DB First, shutdown the DR Database from Promenu #19 Then, backup the database to disk using the following script: /prostix/bat/menu/mnu_backupoffline This runs the Progress probkup utility to backup the DR Live DB to the [DrBackupPath] directory, on the DR Server. Copy the Backup files to the Production Server Copy the Backup Files from the DR Server to the Production Server: cd [DrBackupPath] [AccessMethod] stix*.pbk [LiveServerName]:[LiveBackupPath]  From the Production Server The following steps must be performed on the recovered Production server: Restore the Production DB On the Production Server, restore the DB backup files using the following script: /prostix/bat/dr/dbrest.sh Clear any old AI files left behind There may have been AI work files left behind from prior to the Production server crash. These should be cleared out, however this step is optional. Remove the files using the unix rm command, for example: rm -f [LiveAiCopy]/stix.a?.*  Re-start Production DB This can be done either from Promenu option #19, Start Databases, or via the Production DB start script from the command prompt, for example: /prostix/bat/rc.live Check cron AI process running The root cron job may still be enabled from the initial DR installation, however if it was disabled for whatever reason (say during the rebuild/reload of the Production server after the repair of its failure, it may have been disabled), you need to confirm that the entry exists and is active. Using the crontab -l or crontab -e commands, check that your [cron entries] exist & are not hashed out.