Restore from old WebGISDR Backup

[Sunnywaygis]

Hi Folks, Our multi machine ArcGIS Enterprise environment includes a Portal machine, with one hosted GIS Server and Data store. We also have image server federated. We lost our Portal server earlier. I am in process of rebuilding the new portal machine from scratch and have it configured as before. Once Portal is configured, our plan is to federate GIS servers and then use webgisdr utility to restore. We do have a full backup (webgisdr) before we lost the Portal machine.

In order to check if GIS servers are functioning properly, Authentication tier was changed to GIS_SERVER from ARCGIS_Portal via Admin page. We have confirmed that all GIS servers are functioning. Once Portal is setup, will federate GIS servers and then run webgisdr. I have few questions:

- Does Change of Authentication tier to GIS_SERVER would have any negative impact during restore from webgisdr?

- We want to run only backup for Portal only as all other components (GIS Server/Data Store) are functioning OK. We have extracted Portal portion from full webgisdr backup using 7-Zip. 

- We have webgisdr backup that is pretty old, more than 12 months. Has anyone done restore from webgisdr backup that is few months old and if there any challenges they came across. 

Appreciate your feedback

Thanks

[RyanUthoff]

I probably won't be able to fully answer your question, but I can give you one piece of advice that I found out the hard way regarding Portal authentication and WebGISDR.

The Portal initial administrator account in your new environment (the very first account you create when installing Portal) MUST have the same username and password as the initial admin account in your old environment (unless you have changed the username/password of your Portal PostgreSQL DB. See below for details). Otherwise, the WebGISDR will fail.

Long explanation: Creating the initial admin account does two things.

1. Create an admin Portal account.
2. Creates an account for the underlying PostgreSQL DB that runs Portal using the same credentials as the admin Portal account.

It is important to note that these two accounts are NOT connected to each other. So if you change the initial admin Portal account, the PG account will NOT change. What matters during the WebGISDR is that the username and password of the PG DB are the same. On a side note, you can change the username and password of the PG DB account here: https://portalURL.com/portal/portaladmin/system/database 

To my knowledge, none of this information is documented anywhere (which seems pretty dangerous considering if you no longer have the credentials of the primary Portal account and/or PG account, it can render your WebGISDR backups useless). This may or may not impact the question you had about authentication. 

Regarding running a restore only for Portal, I don't believe that is possible for a WebGISDR. I believe a WebGISDR is all or nothing, meaning your server and data store will also get restored. However, there are ways to restore specific components outside of the WebGISDR. For Portal, you can use the "importSite" operation found here: https://portalURL.com/portal/portaladmin/importSite 

You mentioned you extracted the Portal backup from the WebGISDR, but I'm not sure if that backup will be compatible with the importSite operation. That's not something I have done before.

Finally, regarding your last question, theoretically, a 12 month WebGISDR backup should be perfectly fine as long as the version of ArcGIS Enterprise has stayed the same and you haven't made any architectural changes to your enterprise deployment. It's just going to be a very old backup.

[Sunnywaygis · Accepted solution]

Thanks Ryan for your detailed notes above, very helpful.

Yes, I do have portal admin account credentials so will use the same to configure Portal.

re: webgisdr backup, I will go with running full backup as there are no structural changes to the system. 

Thanks again for your help. 

[DavidHoy]

Actually Ryan - keeping the initial site administrator (ISA) credentials the same is "sort of" mentioned in the.
help doc
ArcGIS Enterprise backups—Portal for ArcGIS | Documentation for ArcGIS Enterprise

Must this item or setting be identical across deployments when running the WebGISDR utility?

Item or setting 10.4.x 10.5.x, 10.6 10.6.1 and later

Version	Yes	Yes	Yes
Public portal URLs	Yes	Yes	Yes
Services URL for federated servers	Yes	Yes	Yes
Registered data stores other than ArcGIS Data Store	Yes	Yes	Yes
Account credentials for the ...webgisdr.properties file	Yes	Yes	Yes
Portal content directory storage type	Yes	Yes	Yes

I say "sort of" because if you do use the ISA in the webgisdr.properties file (and I think most people do when using webgisdr) then this is saying you must use the same ISA credentials in the target.
Your explanation of WHY this is so, is definitely helpful.

[RyanUthoff]

And your last paragraph is definitely what messed me up. It's saying to use the same credentials (which I did, even though it wasn't the ISA, just the same credentials from the same admin account in both Portals). And considering any admin account can run the WebGISDR, I didn't think that the source and target MUST be the same ISA. I thought two admin accounts in both Portals was good enough, which is what the documentation leads me to believe.

Now that I think of it, it might be fine to use any admin account to backup/restore on an existing installation of Portal (I'm not 100% sure on that), but the ISA definitely needs to be the same if you're restoring on a fresh installation of Portal. If that's the case, I feel like Esri's documentation needs to be clarified to reflect that. Last thing I want is an organization to lose their entire Enterprise because they don't know the credentials to the original ISA because the documentation leads users to think (imo) it can be any admin account. 

[JonathanQuinn]

This has come up every so often and it isn't as straightforward as:

1. Create an environment using credentials A
2. Create a backup
3. Re-create the environment using credentials B
4. Restore the backup

We've tested that many times internally without a problem. Ultimately, the database credentials, which initially match the initial administrator account used to create the site, in the backup doesn't need to be the same as the database credentials in the target site. There does seem to be steps that would cause a problem if they're not the same, which is a bug that needs to be identified. However, the credentials used in the DR tool should be the same, which is what Account credentials for the ...webgisdr.properties file refers to. At the end of the restore, the DR tool will generate a new token to validate federated servers. The only credentials the DR tool knows about are the ones in the properties file. If you have credentials A in the backup but used credentials B in the target site, the restore should succeed without running into a problem with the database credentials, but a token can't be generated because credentials B (as a portal user) don't exist anymore. Creating the token will fail and validating federated servers will fail, but the rest of the restore will have completed. If there are steps you recall related to updating the database credentials using the Portal Administrator Directory, that'd be helpful to know why the restore is failing for you.

[RyanUthoff]

That is very interesting that that is a bug. Judging from the messages I received when I attempted the WebGISDR restore, I thought that was by design. I tried restoring the backup several times and it wasn't until I updated the DB credentials in the Portal Admin Directory and used those credentials as the ISA in the new Portal site did it work.

This was awhile back and I don't have any of the logs from that anymore. The WebGISDR itself didn't give any useful information. However, I believe the Portal PostgreSQL logs (C:\arcgisportal\logs\database\pg_log) is what gave me the information to realize what was going on. Even though the username was the same, it was saying something about the password or something like that. And that's when I realized that maybe the PG password has to match too. So, I made the password match and that magically fixed it.

I might try and see if I can replicate that again in my spare time and report back if I can.