Select to view content in your preferred language

Webgisdr failed. Cannot connect to share.

1440
6
01-02-2020 07:49 AM
JeffTimm
Frequent Contributor

Here is a new error for the Webgisdr tool.  In my process the original portal creates the backup then a script moves this backup file to the secondary portal where the restore process is then ran.  This morning I came in and my server could not reach any file shares.  I discovered why (attached screenshot) and restarted the server restoring file share access.  Has anyone seen this before?

0 Kudos
6 Replies
JonathanQuinn
Esri Notable Contributor

Can you determine the share that the error is referencing? Was the DR tool creating a backup or restoring a backup during that time? Each backup process stages the backups on the local drives. For example, the DR tool creates a backup and the SHARED_LOCATION is set to \\fileserver\staging and the BACKUP_LOCATION is set to \\fileserver\full, when the portal is backed up, it'll copy all of the items in the content directory to C:\arcgisportal\temp\<tmp backup folder>. Once it's done, it'll zip it and then copy the backup, (one large zipped file of all content), to the SHARED_LOCATION. The same happens for Server and Data Store; the backups are staged locally before copying to the SHARED_LOCATION. I imagine the copy would open a single TCP port, rather than chunking the file and opening multiple ports.

0 Kudos
JeffTimm
Frequent Contributor

I have found that unpacking a zipped backup file off of the network takes forever and sometimes times out.  How I got around that is I have shared a file off of my secondary portal server.  \\gispt2\SHARED.  This is also known as D:\SHARED.  The webgisdr tool does not seem to allow storage on a local drive thus the trickory.  The error is happening on the restore.

0 Kudos
JonathanQuinn
Esri Notable Contributor

If you have a distributed environment and there's latency to the file share, then yes zipping or unzipping will take a long time. You can definitely set up the share on the local machine where the DR tool is running and set the share as the SHARED_LOCATION property and the BACKUP_LOCATION as a local drive to avoid going over the network. Then, have another process within your automated backup copy the file from the BACKUP_LOCATION to your file server where you're storing the backups. This would work for backing up the environment. For restoring, just copy from the file server to a local drive prior to the restore. We've updated the documentation to reflect this.

0 Kudos
JeffTimm
Frequent Contributor

Right, that is what I am doing but with this process I get the above error.  It is causing the ports all to be used. 

If I restart the server I then can run the webgisdr again.  This error is causing all network shares (even local folders shared as a network share) to be unreachable.

Is there a setting somewhere to prevent this?

0 Kudos
JonathanQuinn
Esri Notable Contributor

There are no settings to control how many connections are open. I've tested the DR tool with 100k items in the portal and didn't run into a problem like you're experiencing. How many items do you have? Can you set up a Performance Monitor counter to track the number of Connections Established and see if an increase always corresponds to when the DR tool is running?

0 Kudos
JeffThornton
Emerging Contributor

John,

My name is Jeffrey Thornton. I really need some help on a complex issue with too many redirects from portal 10.7.1 signing in externally (outside world). We have a old enviroment called Multihoming that uses different IP addresses to route our traffic. Woudl you be willing to help me? Could we do a call possibly? 

Best,

Jeffrey Todd Thornton

Systems Programmer Analyst III

Information Technology

Kansas City Board of Public Utilities

(913) 573-9086  Office

(913) 396-3766  Cell

Email: jthornton@bpu.com

 

Facebook | Twitter | LinkedIn | YouTube

0 Kudos