Disaster Recovery (or moving database to another server) on SQL Server process

1877
5
11-12-2020 07:22 AM
bsanders69
Occasional Contributor

In the case of a relational database server failure, ESRI recommends that we restore geodatabases from backups on new server, make all new connection strings to new database Instance (machine name), fix every database connection error in every map and/or ArcGIS Pro project that is connected to an Enterprise database (SQLServer/Oracle, etc.), republish every service on your Enterprise ArcGIS Servers and potentially check/fix all maps and their popups.  This process, to me, sounds like potentially a ton of work to get your Enterprise back up and running again.  

 

I proposed that there is, potentially, another solution that cuts the work down to a few hours at best.  Our servers are virtual on VMware.  This approach still would work with stand alone physical machines used as database servers as well. 

  1. I propose that it is possible to create a server with the same machine name for your Enterprise database server (and for this document, we'll just use SQL Server as an example), leave it off your Domain.
  2. Add OS and any typical software and install SQL Server, taking the machine name as the Instance (in effect having the new server with the same name and Instance as your existing server),
  3. Then the magic...Take old server off the Domain and add the newly created one to your Domain and restore all geodatabases from their backups
  4. Verify user accounts are still there or authorize the same user accounts set up on old server, and in theory, everything is back up and running at that point.  All of your old connections should now still work, including Services and Maps.

 

I could not get confirmation form Tech support that this approach works as they have apparently never had anyone with a failing DB Server to confirm this method, so I thought I would ask the Community if this seems to be a way around this type of disaster recovery without all of the work.  

 

Please let me know if anyone else has had a failing DB Server and tried another method.

0 Kudos
5 Replies
RyanUthoff
Occasional Contributor III

We recently had a scenario where a database server failed. We had to spin up a new server VM with the same name and restore all of the databases from a backup onto that VM. Since the VM server name stayed the same, we didn't have to change any of the connections within Esri. I'm not sure if that answers your questions, but that is the situation we experienced when our server crashed.

BrettSanders
New Contributor III

Thanks for the feedback and confirmation that this is a viable option for having to move database servers and, by far, the quickest, least painful method.

0 Kudos
BrettSanders
New Contributor III

Did you have any issues with the db/geodatabase admin and other user accounts?

0 Kudos
RyanUthoff
Occasional Contributor III

I'm not a DBA, so I'm not exactly sure what all extra had to be done. I do know that the user account used to publish feature services to server did not have permission to access the databases, so that had to be fixed. But I'm not sure about the details. I just know that I didn't have to update any connections or anything like that within Esri.

0 Kudos
bsanders69
Occasional Contributor

I believe that by adding a redirect to the DNS that points bad SQLOS server name to new SQLSOS server should also work without having to change the path to every layer in every map file/pro project.  This might not be the case if the server is on a different domain, but we don't have that issue.  Can someone tell me if I am wrong?

0 Kudos