Proxmox: Restore from PBS to PVE node takes hours to verify

I’m running into a rather odd issue and I’m not sure how to really begin troubleshooting it. For context, I currently run 2 PVE nodes independently instead of in a cluster because they’re differing architecture, RAM capacity, and storage capacity. I also have spun up a PBS server on a dell R710 with 2 Xeons and 48 GBs of RAM. I know the hardware’s old, but it was cast-off from my last job and electricity is cheap.

PVE node 1 has 6 x 2TB drives in a RAIDz1 array.
PVE node 2 has 8 x 300GB drives in a RAID-5 array with a HBA.
PBS node has 6 x 8TB drives in a RAIDz1 array.

Each node is connected via a 10gb SPF link to a 10gb capable switch.

On PVE node 1 I had a template created from an ESXi 7.0 host. This template had 1 32GB drive and 1 256GB drive. I backed up this template to the PBS server which took over half-an-hour. Longer than I would expect for a 10Gb link but ZFS does alot of stuff under the hood so whatever.

Next I restored that backup from the PBS server to PVE Node 2. The restore operation completed within 15 minutes, much better right? Then it started the verification process. By my estimate it’s going to take 4+ hours to verify the VM whose total size is less than 300 GBs.

I’ve got no idea why it would be taking so long, especially because Node 2 is using hardware RAID and not ZFS. It has plenty of CPU horsepower, but right now CPU utilization is sitting at ~5%. Does anybody have any idea why this process is SO SLOW??? Usually when you’re restoring from a backup you would at least hope for a quick turn-around time because usually you only pull backups when shit hits the fan. I’ve tried searching through the Proxmox support forums but the best i’ve been able to piece together is maybe the actual verification process is single-threaded and cannot be parallelized for reasons. Which just blows my mind. How can this be considered a viable solution if your disaster recovery estimate could potentially be DAYS not because of poor hardware or vast amounts of data, but because the backup solution runs at a literal snails pace.