How are the ".portalsite" files managed in a portal content/temp directory?

[pfoppe]

Our ArcGIS Enterprise v10.7.1 portal has some .portalsite files in a temp folder on the portal content directory.  It appears these are related to some backups, but I do not have these .portalsite files for every full or incremental backup we have run.  Each of these are anywhere from ~1GB - 3.5GB and we currently have 6 of these on our D:\arcgisportal\temp folder

As a result, it is taking up 14GB of content out of the 27GB in our content directory.  

Do these files get cleaned up automatically?  Can we safely delete these? 

Thanks for any guidance we have

[JonathanQuinn · Accepted solution]

You can delete them. They should be deleted automatically if the export process fails or completes. Since you're seeing differing sizes, it seems like something is interrupting the export process. Any pattern to when they were created, and the last time modified values?

[pfoppe]

Thanks for the reply Jonathan Quinn‌!

I found a few hints that may have caused this...

We started running backups in this test environment on 1.8.2020 and both the "SHARED_LOC" and "BACKUP_LOC" were on a distributed file system.  The backups were taking quite a while so one of our SA's was testing out migrating the SHARED_LOC to a local path on the portal server and leaving the BACKUP_LOC on a network location.  Looking through the webgisdr logs (on this date), it looks like during that testing some of the webgisdr.properties were not valid..

Specifically... there was a C:\shared_loc reference in the properties file and so the federated servers (and datastore) that live on different machines were failing to write and logged an error: 

Cannot access the file C:\Loc\SHARED_LOC\WebGISSite1578958815609\server\<redacted>\January-13-2020-at-4-40-53-PM-MST.agssite.

Exiting the WebGIS DR utility.

I remember consulting with the SA that it had to be a UNC path, so I suspect the webgisdr utility pre-maturely failed and left them behind.  

Again... thanks for confirming that we can remove these!

[JonathanQuinn]

Thanks for the feedback. Let me look into that to see if I get the same behavior.

If you have a distributed environment, (Portal, Server, and Data Store on separate machines), the SHARED_LOCATION must be set to a share. However, you can package the backup locally by setting the BACKUP_LOCATION to a local drive. That'll be far faster for at least the zipping step. Once it's zipped, you can then move it to the file share it's supposed to live on.

[pfoppe]

Thanks for the feedback.  We have fixed all the webgisdr.properties to use a UNC for the shared loc (on the portal server itself), then a DFS path for the backup loc.  

From your feedback, I think only the portal server accesses the BACKUP_LOCATION, hence why that could reference a local drive on the portal server (to speed things up)?  And that might make the process faster (since its local and will minimize network traffic)?

I think for now, we will leave the BACKUP_LOCATION on a DFS path as the file system on that DFS path is being backed up by our corporate backup solution... that will prevent us from having to do a robocopy (or like) to that DFS location after the webgisdr utility has finished.  Although... I'll keep this in my back pocket in the event the webgisdr backups become un-sustainable (taking to long).  At this point, we plan to only run a weekly FULL and daily INCREMENTAL in the middle of the night... so I suspect they will be finished long before our normal business hours.  

Thanks!