Webgisdr failed. Cannot connect to share.

[JeffTimm]

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?

[JonathanQuinn]

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.

[JeffTimm]

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.

[JonathanQuinn]

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.

[JeffTimm]

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?

[JonathanQuinn]

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?

[JeffThornton]

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