Secret Server

Hi,

Can someone help me in backing up and restoring the database in case of server crash?

Thanks,
Sridhar

Hello Sridhar,

These knowledge base articles walk through the backup and restore process.

Automatic Backup
http://www.thycotic.com/documentation/secretserver/secretserver.html#d4e1135

Manual Backup
http://support.thycotic.com/KB/a19/how-to-manually-backup-secret-server.aspx?KBSearchID=0

Restoring Secret Server from a backup
http://support.thycotic.com/KB/a22/restoring-secret-server-from-a-backup.aspx?KBSearchID=0

Hi Tucker,

Thanks. Can you help as what is required in configuring high availabilty for secret server i.e software required.


Thanks,
Sridhar

Setting up Secret Server for disaster recovery

Secret Server supports setting up the database in a disaster recovery environment by using the mirroring capabilities in SQL Server 2005 and SQL Server 2008. This allows you to have a copy of your database on another server and automatically start using the backup server should your primary database server fail.

Here is a detailed guide to configuring database mirroring: http://www.thycotic.com/articles/secretserver/SQLServerMirroringAndSSL.pdf

The advised high availablility setup is a single webserver frontend with a primary and secondary database backend.

Hi Tucker,

Does this mean I need to have 3 servers running i.e one primary, one secondary and one witness for monitoring the health of primary and secondary? Can we have two servers (primary and secondary) and the sql witness instance running on either primary or secondary? Bit confused with 3 differednt sql instances hence so many questions. Please let me know as how many servers and sql 2008 licenses are required to implement sql server mirroring with secret server.

Thanks,
Sridhar

Hi Sridhar,

Yes, the recommended configuration is to have three different physical servers. One running the Primary, Secondary, and Witness server.

Note that the Witness Server can be a SQL 2008 Express instance, so an additional license is not required for the Witness Server.

The Primary and Secondary Servers must SQL 2008 Standard Edition or higher.

It is recommended that all three instances of SQL 2008 are on different physical hardware as this provides the maximum protection. It is possible to do fail-over without a Witness Server, however that will cause the protection to be in "High Protection" mode as opposed to "High Availability" mode. The roles are as such:

Primary (or Principal) - This is the "primary" database that Secret Server will communicate to.

Secondary - This server will contain a mirror of the data of the primary server. Should the Primary ever fail, the secondary becomes the primary server.

Witness Server - This server acts as a decider for when automatic fail-over should occur. It monitors the health of both the primary and secondary servers. If the primary should fail, the witness tells the secondary to take over. Should the Witness server fail, the primary and secondary servers will continue to act as normal, but automatic fail-over will not occur. You must manually cause a fail-over.

For more information, I recommend reading here. This is for SQL 2005, but all of the concepts are configuration are the same for SQL 2008:

http://technet.microsoft.com/en-us/library/cc917680.aspx

Hi Kevin,

Thanks for the reply. could you clarify my queries below

1. I am planning to have primary server at my main site and witness & secondary at my DR site. So in the event of failure of primary can i use my Secondary as webserver for accessing passwords which is at DR site? Currently we have only one server running at the main site.

2. Am i permitted to do this under the terms of license agreement that we have currently?

Thanks,
Sridhar

Hi Sridhar,

1. This may pose to be a performance problem. Our recommended configuration is a synchronous transaction - so that changes to data in the database are ensured to be committed on the backup before they are committed to the primary. You can configure asynchronous operation for better performance but it may can result in some data loss in the event of a failure.

As explained in the DR Whitepaper, if you configure Secret Server during Step 3 to know the location of the Primary and Secondary database, Secret Server will automatically switch to the second database server.

2. Secret Server Licenses can be used a second time purely as a means of disaster recovery.

If you have any additional questions or concerns, please contact support by emailing support@thycotic.com.

Thanks,
-- Kevin

Hi Kevin,

Though the secondary server is located at DR site, all the three ( primary, witness and secondary) will be communicating with each other. Lets assume that primary and witness are at my primary site and secondary at my DR site, In the event of failure in the production environment we would also want to fail the web server over to a machine in the DR Site. Could the secondary SQL server be used for this ? or do we need to have one more webserver for accessing the secondary database .

Thanks,
Sridhar

Yes - you can use the secondary SQL server as a web server. You will need to be able to change your DNS to point users to the new webserver or alternatively have a central link that everyone uses (for example - on your intranet portal) and then just change the link if necessary.

Hi Sridhar, all suggested ways imply that you have backed up the data previously. If it was not done, you may try the [url=http://www.recoverytoolbox.com/microsoft_sql_server_database_recovery_download.html]sql server 2005 in recovery[/url] program, it analysis corrupted databases and retrieves the data if possible

Our DR config is a little simplified, but worked just fine when we had a DR test a few months back

We have a primary SS DB mirrored to our DR SQL server offsite. We also have a principle SS webserver, and a warm DR SS webserver at the DR site. The server's up and running with IIS services off.

Our DR test brought our main site offline, we broke the mirror on the DR SQL DB and then started up the IIS services on the DR SS webserver and pointed it to the DR SQL DB. Clients just used the DR web address for the duration of the test. From going offline, to bringing the secondary SS webserver online with DB access took 10-15 minutes.

Just remember to re-mirror the DB after you go back to your main setup.