You should configure Disaster Recovery to run daily, this is to stop the SQL log getting too large
Run the backup when you expect there to be no other or few other operations running, such as report retrieval or importing; for example, overnight
Time the backup so that it does not start at the same time as any other scheduled event; this includes, archiving, management information harvest and automated report retrievalFor example, if you retrieve reports hourly at 15 minutes past the hour and your report retrieval typically takes 5 minutes, you should time Disaster Recovery to start at 25 minutes past the hour
Do not time the backup for Midnight. This is because this is when Experian Payments Gateway performs housekeeping tasks
Ideally run disaster recovery after archiving. This will reduce the amount of data that needs to be backed up and reduces the possibility of problems when restoring the data
Do not start a client and try to login when the disaster recovery backup is running. If you start a client during a disaster recovery backup, your client will be locked and you will not be able to log in. However, because the client was not active when disaster recovery was started, Experian Payments Gateway Server is not aware of the client and will not unlock it once the backup is complete. You will need to shutdown and restart the client machine to close this instance of Experian Payments Gateway.
Make sure your backup locations are not on the Experian Payments Gateway server machine
At least one of the locations should be off-site, or on a server that is regularly backed up with the backup stored off-site.
You should regularly perform a test installation of the disaster recovery server. Typically, perform this quarterly to make sure it is frequent enough that you know how to perform a restore and that you are backing up the correct level of data.
When restoring the SQL log after a database problem, you should restore up to the latest time before the problem occurred. If you do not know when that is, restore the SQL log up to the most likely safe time and if you have still have a problem, undo the SQL and try again, restoring up to an earlier time.
If you need to use the Disaster Recovery Server as the live server, you should edit serverDefault.properties to set -dr=0.
When convenient, you should switch back to the live server:
Plan the changeover back to the live server for a quiet time
Before restoring the live server, you should perform a backup (using the Backup now... button on the Disaster Recovery tab) and then shutdown the server. You can then use this backup to bring the live server fully up-to-date, without having to restore the SQL log
On the Disaster Recovery Server, edit serverDefault.properties to set -dr=1.
