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?
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.
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.
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.
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?
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?
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?
Jeffrey Todd Thornton
Systems Programmer Analyst III
Kansas City Board of Public Utilities
(913) 573-9086 Office
(913) 396-3766 Cell