As an GIS Systems Administrator I frequently need to run webgisdr backups and other limited exports in order to relocate enterprise servers , upgrade them, and//or manage disk space. When the content folders for portal get large, it becomes impossible to export the site without adding enough free disk space to stage the portal export in the same root portal folder before moving it to the temporary staging location for webgisdr. The temp portal folder is the default location for this initial full export - unfortunately it is also the location for user temp processes like uploads. Since I would ideally like to keep these areas separated so they can be independently moved, and hopefully not require a reboot for backup locations, I would suggest a location other than the <Portal_content_directory>\temp directory be used as the default location for the portal export, or that added to portal configuration so it can be easily manipulated on the fly - the problem is demonstrated very well by this article -
https://support.esri.com/en-us/knowledge-base/webgisdr-error-code-500-messages-export-operation-fail...
Root Cause: If the ArcGIS Server data being exported is larger than the space available on the C:\ drive, the export fails. Although it may be determined that enough space is available, it is often not known that ArcGIS Server uses a temporary location to build the export. With the export operation and a properties file to create a backup of ArcGIS Enterprise, the backup for each component is placed in a temporary directory on each component's machine before being moved to the shared directory that is specified in the webgisdr shared backup location. Therefore, the following directories must be large enough to contain the backup of each component:
Portal for ArcGIS: <Portal_content_directory>\temp
ArcGIS Server: C:\Users\<user>\AppData\Local\Temp
ArcGIS Data Store: <ArcGIS_Data_Store_directory>\temp
The server and datastore backups are a fraction of the size and not usually a problem. Content, however, is a huge flat nested filesystem.. Luckily these are virtual servers, but if they were physical I would have brought my environment down trying to run these backups.
In my case - I needed an extra nearly a terabyte of free space that mainly sits empty in order to accommodate the 184GB on portal content and the shared _backup location for webgisdr. This does not include the database exports which go to the <Portal_content_directory>\backups directory (configurable). I kept thinking it was the SHARED_BACKUP variable in webgisdr that was too small and kept expanding that location - however, the issue is that the 1864 GB of portal content is not compressed and gets copied twice after the initial export -it seems this process was not designed for a site of any large size. It does seem like something that should be accommodated for as part of any normal backup script.
