SQL Server DB server disaster recovery process documented at ESRI to change all of your data connections in all of your maps and then republish all of your services. I could not get a full answer from the ESRI Case worker as they can not test my approach, nor has ESRI ever come across an alternative to build another VMware server and SQL server instance with the same machine name and instance as the current DBserver, take the original server off of the Domain, connect the new server to the domain, install SQL Server and restore the DB backups. This should make all of your database connections, services, Portal content (maps and apps) stay the same and nothing else to do...This approach would save potentially a few weeks based on your Enterprise usage. Has anyone else had to recover or migrate to another SQL Server machine without the long and painful method?
Hi @BrettSanders,
I think the major hurdle with the workflow you're suggesting is there are a number of areas where things can go wrong, and all the steps in the process are achieved outside of Esri software. While it is absolutely true that a new but "identical" SQL instance could run the services, there are a number of caveats including using the same FQDN (or SPN from an OS-authentication perspective), the same security/users/passwords configured on the instance, and no other underlying data changes compared to the original machine/database.
With that being the case, it's difficult from an Esri Support perspective to recommend workflows that are not officially documented, even if the workflow could technically work if implemented correctly. If you were to push forward with this plan, I would recommend having a plan to revert to the original stack in case anything along the way goes awry, which is made difficult since in an AD environment/domain having the same computer name twice within a domain is not possible.
There is another option to update the registered data store connection with a new SDE file when a new instance is stood-up and the data/security migrated to that new instance. The documentation only mentions password updates, but it works for hostname changes as well (documentation enhancement is in the works already). This would be a band-aid to prevent immediately needing to republish all referenced services, but the Service Workspace information would not be updated within Server Manager so it is worth republishing when the opportunity arises.
Register your data with ArcGIS Server using Server Manager—ArcGIS Server | Documentation for ArcGIS Enterprise
https://enterprise.arcgis.com/en/server/latest/manage-data/windows/registering-your-data-with-arcgis...
Hope that helps,
Chris
You are correct, if the plan goes off without a hitch then this is a viable approach for migration to a new DBMS instance, but it does fall outside of Esri's scope of support since all the moving parts are non-Esri products/technologies. If you are using the same hostname (FQDN) then you would not need to update any of the SDE connection strings within the registered databases.
I primarily wanted to expound a bit upon the supportability of such a maneuver, and outline some of the potential pitfalls along the way. In terms of recreating the user permissions/roles, the instance would have to be domain-joined to add OS-authentication users, but database users could be mirrored at any point in the process.
As you've already alluded to, make sure to have a sound back-out strategy for if things go awry.