Doesn’t appear to be any additional input here, so I’ll add a postscript and try to summarize my understanding.
I performed a “nuclear” prune on both the local and cloud storage pools to remove all snapshots older than 30 days. This appears to have fixed the issue and the entire backup job is now running in 2-4 hours (that includes creating/copying images of two server volumes, backing up the server target volume to the local Duplicacy storage pool, pruning both the local and cloud storage pools, copying the local storage pool to the cloud with snapshots from four targets).
I’ve noticed during the prune on the cloud storage, a recent snapshot from the most active target is removed, and then the copy process re-adds that snapshot to the cloud. Not sure if that’s something to be watched or not.
My impression is that I likely caused the issue initially by backing up one of the targets directly to the cloud storage pool on several occasions thereby ‘confusing’ Duplicacy as it attempted to prune what was no longer needed in both pools and then copying data from local to cloud. The result was older shapshots being pruned out of the cloud and then re-uploaded during the copy process.
Is that an accurate explanation?
If so, then it seems reasonable to state that backing up directly to a storage pool that is primarily used for replication is a BAD IDEA. Correct?