WebGISdr starts but never completes backup

[NC-BoCastillo]

We recently upgraded to Portal 10.8.1. We use the WebGISdr commands to import/export backups between the primary (SERVER1) and standby (SERVER2) machines. We are not in a high availability set up.

We got 10.8.1 Portal up and running on the standby (SERVER2) first and made it the primary machine while we upgraded the original primary server. We ran numerous WebGISdr backups from SERVER2 without an issue.

After getting a base install of Portal 10.8.1 on SERVER1, we imported the backup using WebGISdr. It was successful and we changed SERVER2 back to standby and made SERVER1 the primary. Everything seems to function fine except.

After numerous attempts, the WebGISdr will no longer complete a backup on SERVER1.

It creates a folder named similar to WebGISSite1615390701747 in the Portal directory designated as the shared located. Inside of that folder, there is a Portal folder with a file named something similar to 20210310-100307-EST-FULL.portalsite. It is roughly the size I would expect it to be. Once it hits this point, it never leaves the following screen below and completes the packaging. It's working but it seems to be hung up somewhere in the process and never completes. I left it running overnight last night and it never completed. I tried again this morning and still the same results on SERVER1.

==================================================
Starting the WebGIS DR utility.
==================================================

The configuration and base backup time in the current Web GIS
-------------------------------------------------------------
Portal: https://arc.mydomain.org/portal at 3/9/21, 3:57 PM

Starting the backup process with the WebGIS DR utility.

Starting the backup for Portal for ArcGIS:
Url: https://arc.mydomain.org/portal.

SERVER2 (standby) will complete a full backup in about 20 minutes, as I verified twice this morning. Everything should be the same such as version and patches.

It does not appear to be this issue:

When I run the webgisdr utility to either create or restore a backup, it never completes. 

Any ideas or suggestions???

ADDED:

Using the Export Site through the Portaladmin directory yielding similar results. It creates a portalsite file similar to  20210310-130316-EST-FULL.portalsite that seems to be an appropriate size but the process never seems to finish. It'll just spin and spin.

[JonathanQuinn]

How many items do you have in the portal? Where is the content located? When portal creates a backup, it stages files under C:\arcgisportal\temp. Do you see that directory grow in size and the number of files? Eventually it should match the number of items in the content directory before it's zipped up to a portalsite file and copied to the backup location.

[NC-BoCastillo]

I don't know the number off the top of my head but we have quite a few items in Portal. The backup process normally takes 20 minutes.

The content is on a local drive. It does stage properly under the D:\arcgisportal\temp folder before moving the information over to a temporary folder in the SHARED_LOCATION listed in the webgisdr.properties files. At this point it seems to never complete to make the final *.webgissite file. On the standby server, the process is working fine.

I have a case open with ESRI and will post any results.

[MichaelAugust]

Did you ever figure this out, since upgrading to 10.9.1 I can't get a Portal backup completed with webgisdr either...

[JonathanQuinn]

Have you contacted Support? If not, I recommend doing so and providing DEBUG logs from Portal and the DR tool when running a backup as well as a ProcMon log which can help track what's being attempted on the file system.

[NC-BoCastillo]

I forgot to follow up on this one.

I wanted to say that the solution was as simple as a server reboot for us. After the reboot, the WebGISdr worked as expected.

[NunoCaeiro]

Did you manage to get through this?

[JeffTimm]

What were your results?

[NC-BoCastillo]

I forgot to follow up on this one.

I wanted to say that the solution was as simple as a server reboot for us. After the reboot, the WebGISdr worked as expected.