Restoring a backup of an ISE 2.7 node to a 3.2 node is failing

[paynewj]

I'm working on upgrading our ISE deployment from 2.7 to 3.2. We currently have a 4-node production deployment of ISE 2.7 - (2) PAN/MNT nodes and (2) PSNs. I've already installed ISE 3.2 onto new VMs and am at the point where I would like to restore the configuration from our 2.7 production PAN to one of the new 3.2 VMs. I created an SFTP repository via the GUI and pointed it at our SFTP server (SolarWinds), as well as created the crypto host key via the CLI. The repository can be validated and I can see all of our production 2.7 backups in the folder from the GUI of the new 3.2 ISE server. 

When I attempt to restore one of the configuration backups of the production 2.7 PAN to the new 3.2 VM, I receive the following error:
Restore failed: copy from repository failed

Debug from the ISE 3.2 VM:

ISEPAN/iseuser#6 [3812]:[info] backup-restore:restore: br_restore.c[2297] [system]:
Received tty as NULL

7 [3812]:[debug] backup-restore:restore: br_restore.c[1158] [system]: initiating restore DAILY-CFG10-240706-0 000.tar.gpgDAILY-CFG10-240706-0000.tar.gpg from repos ISE_Backups
7 [3812]:[debug] backup-restore:restore: br_restore.c[1210] [system]: no staging url defined, using local spa ce
7 [3812]:[debug] backup-restore:restore: br_restore.c[1232] [system]: creating /opt/backup/restore-DAILY-CFG1 0-240706-0000.tar.gpgDAILY-CFG10-240706-0000.tar.gpg-1720738276
6 [3812]:[info] backup-restore:restore: br_restore.c[76] [system]: Invoke /opt/CSCOcpm/bin/iseprerestore.sh s cript for ise
3 [3812]:[error] backup-restore:restore: br_restore.c[1264] [system]: Restore failed: copy DAILY-CFG10-240706 -0000.tar.gpgDAILY-CFG10-240706-0000.tar.gpg from repository failed

Any ideas as to what might be causing this? Currently, this is the only node in the deployment. I will be adding a secondary PAN, and (2) PSNs once I can get this figured out.

[marce1000]

    + check if the target ise 3.2 node has sufficient free disk space (check all partitions)
    + check the SFTP servers logs for the particular transfer - attempt
      (SOLARWINDS) and or run it in verbose mode (if possible)

 M.

[paynewj]

Thank you for the reply, @marce1000. Below is the amount of free space that the 3.2 node has for each partition:

Where would ISE attempt to copy the file to when the restore process is initiated? If it's the temp folder, then it has insufficient space available - 1.8GB free, and the backup file is approximately 5GBs. If that's the case, how do I get around this limitation? If that's not the issue, any idea what else I should look at? Unfortunately, our SolarWinds server did not have any useful logs for the SFTP server. 

Thank you for all of your time and assistance.

[marce1000]

        >.... If it's the temp folder, then it has insufficient space available - 1.8GB free, 
  - That's probably a target problem which must be resolved. There is a simple trick to find out :
     Start a configuration restore again ; then use  your command to examine the filesystems let's say every
     second , or every 2 seconds : you will then be able  compare the previous output(s) and see which
     partition(s) are filling up.

     As far as expanding partitions on a linux-based VM on any hypervisor environment , you will find tons of info's
    by searching with relevant keywords as in : 
                         https://www.nakivo.com/blog/increasing-the-size-of-a-disk-partition/

 M.