Hello,
I'm currently testing the webgisdr utility and replicating a primary portal environment to a standby portal environment for disaster recovery. Each environment uses the same URL and references separate virtual IP addresses. My portal setup has a federated ArcGIS Server instance and a separate ArcGIS Server as the host server. I'm coming across two issues in the standby portal instance:
Solved! Go to Solution.
What version are you using? At 10.5 and on, we support different machine names between where you take the backup from and where you apply the backup. This applies for Portal, Server, and Data Store, regardless if it's HA or standalone. Do you mind providing a screenshot of the error message you receive in your first point?
In regards to your second point, the user-facing URLs have to be identical, (web context URL or web adaptor URL for Portal and the services URL used to federate for Server), directories and registered data stores, (excluding the ArcGIS Data Store) have to be identical between Site A and Site B. For example, if you have a multi-machine site and the directories for Site A are on \\fileServer\arcgisserver\directories, the directories for Site B should also be in \\fileServer\arcgisserver\directories.
We realize that it is likely difficult for an organization to replicate machine names between data centers, especially if the data centers are in the same network. There is a workaround that takes advantage of persistent mounted drives:
How to map network shares into drives to a Windows service permanently – Aspera Support
In this scenario, you map \\shareddrive\GIS_Environment\Server to the Z or X or whatever other drive letter on Site A and you map \\shareddrive\DR_Environment\Server to the same drive letter on Site B. Then, you either move or create the site with that path as the config-store and directories path. When you take a backup and restore to Site B, Site B will continue to use it's own mapped X drive which resolves to the proper share.
We're looking to improve on this for later version of the software.
Hi Sam,
The purpose of webgisdr is to restore on the exact same configuration that the webgisdr was created on so it can be a bit tricky to restore on a different machine. I haven't tried your particular workflow, but I would assume that the database name also has to match.
" If you restore to a different machine—for example, if the machine where you had Portal for ArcGIS installed cannot be recovered and you need to restore to a new machine—your content and installation directories must be the same on the new machine. For example, if your content directory was on the C: drive on the machine that failed, you must put the content directory on the C: drive on the new machine. "
Based on the above text, do your Server directories match exactly?
They are not the same. The the primary and standby environments have different locations:
The help arcticle below makes it sound like I should be able to import the primary export into a standby environment as long as the portal and server URLs are the same:
Configure disaster recovery for ArcGIS Enterprise—Portal for ArcGIS (10.5.x) | ArcGIS Enterprise
I would highly suggest contacting Technical Support if you can. They will be much better at identifying what's going wrong, or the documentation could be missing some information.
The webgisdr I was working with was setup differently, so unfortunately I can't offer much more help. Good Luck!
Hm, that line in the doc is incorrect. We support different content directories, but the install paths must be the same. I'll get that sorted out.
Thanks for investigating. I haven't used the webgisdr past 10.4.1, clearly it has improved quite a bit! I'll have to spend some more time on it.
What version are you using? At 10.5 and on, we support different machine names between where you take the backup from and where you apply the backup. This applies for Portal, Server, and Data Store, regardless if it's HA or standalone. Do you mind providing a screenshot of the error message you receive in your first point?
In regards to your second point, the user-facing URLs have to be identical, (web context URL or web adaptor URL for Portal and the services URL used to federate for Server), directories and registered data stores, (excluding the ArcGIS Data Store) have to be identical between Site A and Site B. For example, if you have a multi-machine site and the directories for Site A are on \\fileServer\arcgisserver\directories, the directories for Site B should also be in \\fileServer\arcgisserver\directories.
We realize that it is likely difficult for an organization to replicate machine names between data centers, especially if the data centers are in the same network. There is a workaround that takes advantage of persistent mounted drives:
How to map network shares into drives to a Windows service permanently – Aspera Support
In this scenario, you map \\shareddrive\GIS_Environment\Server to the Z or X or whatever other drive letter on Site A and you map \\shareddrive\DR_Environment\Server to the same drive letter on Site B. Then, you either move or create the site with that path as the config-store and directories path. When you take a backup and restore to Site B, Site B will continue to use it's own mapped X drive which resolves to the proper share.
We're looking to improve on this for later version of the software.
Jonathan,
Thanks for the quick response. I'm using ArcGIS Enterprise 10.5.1 on Windows Server 2016 virtual machines. Regarding the data store here's the webgisdr log (I modified the URLs and server names to remove some sensitive info):
==========================================
Starting the webgisdr utility.
==========================================
The configuration and base backup time in the current Web GIS
-------------------------------------------------------------
Portal: https://gis.domain.com/portal at 2/5/18 11:23 AM
|
|-- Federated Server: https://gis.domain.com/server at 2/5/18 11:23 AM
|
|-- Hosting Server: https://gis.domain.com/hostserver at 2/5/18 11:23 AM
| |
| |-- Data Store: https://standbydatastore.domain.com:2443/arcgis
Unzipping the backup file
The configuration and base backup time in the incoming Web GIS
--------------------------------------------------------------
Portal: https://gis.domain.com/portal at 2/6/18 10:38 AM
|
|-- Federated Server: https://gis.domain.com/server at 2/6/18 10:38 AM
|
|-- Hosting Server: https://gis.domain.com/hostserver at 2/6/18 10:38 AM
| |
| |-- Relational Data Store: https://primarydatstore.domain.com:2443/arcgis
Starting the restore of ArcGIS Data Store:
Admin Url: https://standbydatastore.domain.com:2443/arcgis/datastoreadmin.
Failed to restore the ArcGIS Data Store.
Admin Url: https://standbydatastore.domain.com:2443/arcgis/datastoreadmin. {"jobId":"ccbf3243-1a03-496c-9b58-34cf2625c328","errorMessage":"Failed to import data to your replicated site.. Extended error message: Failed to import data to your replicated site.. Extended error message: D:\\arcgisdatastore\\data\\backupedContents20180206\\backup_DSBackup1","description":"Deploy data store snapshot February-6-2018-10-38-49-AM-CST-79-FULL from \\\\shareddrive\\GIS_Environments\\DR\\Backups\\WebGISSite1517941612799\\dataStore\\4525fa2f-8aeb-4913-bd13-63d812774562","lastModified":"2018-02-06 12:37","status":"failed"}
Do I need to have a common alias for the data store servers as well? The standby host server logs state that are unable to find datastore "AGSDataStore_ds_6tnsqywy" and I noticed the standby environments data store has a different name. I'm unable to pull up the host server logs at the moment, but I will post that information when I can access them.
Regarding the site replication. You hit the nail on the head. Both of our data centers are on the same network and I can't have duplicate server names. I'll start working on getting those mapped drives added.
Do you have an HA data store or the backup location set to a UNC path?
Yes to both.