Backup of Archer two servers, one DNS.
Running Archer 5.3 SP1
Windows Server 2008 R2
We currently have an RTC of 12 hours on the server and 1 hour on the database. We want to minimize this risk by adding another server and having both under one DNS; one hot and one cold. Both would use the same database. For anyone who doesn't know, a cold server is a backup server whose purpose is solely to be there in case the main server is lost or down.
Is this best practice? What are the implications of doing so. I know file attachments are hosted on the server but what else? Are the file attachment location values (in the db) relative or absolute?
Is there documentation on how to do a complete backup of the server, for the purpose of a fresh install?
Any help is appreciated.
How does adding a cold web-server minimize your risk if they both point towards the same database? If the database is down, both your web-servers (hot and cold) will be down too if they can't access the database.
In my experience, best practice would be setup your Production environment as a multi-host environment made up of your database server, which is then connected to by 2 or more load balanced web-servers, 1 or more services servers, and 1 or more job engines to make up the Production environment. You would then also maintain a redundant and identical system (1 DB, 2+ web, 1+ services, 1+ job) at another data center that would be your Business Continuity (BC) or Disaster Recovery (DR) environment.
These systems need to be continuously kept in sync for any change that takes place outside of the instance database, such as IIS settings, folder permissions, file repository / index / logging directory replication, etc. You also need to setup SAN replication, or another form of backup depending on your need, to keep a copy of your instance database in the DR environment.
We've operated under the above model for nearly 2 years now, and we exercise it quarterly to ensure it works. There was a lot to work out initially, but once we had that done and the process down, we can now fully recover our entire system at the BC/DR site in under an hour.
Since your objective is expressed in RTC and because RTC is the demonstrated time it takes to recover (including verification time), the key activities that will help you reach this objective are:
- Clear roles and responsibilities
- Clean documentation and procedures
- Scenario analysis (this is key and will help you understand when the cold server you propose would truly be helpful and when it would be useless)
- Regular exercises (and this last item is probably the most important of all and unfortunately most often forgotten one)
My guess is that your team preparedness and frequency of exercise will have a stronger effect on your RTC than the technological design of the solution.