---
title: "Overview (Disaster Recovery)"
canonical: "https://kb.myframeworks.com.au/space/PROSTIXV48DOC/31100648/Overview%20(Disaster%20Recovery)"
format: markdown
---
The following is an overview of the Disaster Recovery process.  Daily Operation During the normal day-to-day operation, the following events occur: In Case of Disaster In the event of a disaster, such as a Database crash, server crash, loss of main communications, and so on, a decision must be made to determine if it's appropriate to switch over to the DR Server. This decision depends on the time required to recover. If the decision to switch over to DR is made, there are several different methods to switch over depending on your environment & configuration. The following are at least three different scenarios: 1. Login directly to ProStix DR: This method requires the DR server to be available on the network at all times, & for each desktop to have the required icon (ProStix Character) or DR Server name configured (ProStix GUI). It requires the least involvement to activate, but a bit more preparation to setup the duplicate access methods on each desktop. 2. Swap the IP Address: Instead of maintaining duplicate setup on each desktop, you re-set the DR Server to use the IP Address of the failed Production Server. This requires additional steps at switch over, but gives you more control over access to the DR server, & requires much less preparation work. 3. Comms provider re-route: It may be necessary that if your DR server is hosted offsite, that your comms provider may need to switch or re-route access for your users to the DR server, particularly if you do not have access to it from the required desktops during normal operation. Note:  Also that in each case, the DR Live DB needs to be started manually. Refer to Appendix A for the access method defined for this site.  Switching Back from DR Server to Production Server Once you have corrected the problems with the Production Server, there is a recovery process that must be followed to get the new data from the DR database back onto the Production server, and to restart the AI synchronisation process. Typically this would be done at the end of day. The steps required are: