The problem is that restic can spend quite some time to process files without uploading anything. In case of a 50GB VM image with essentially no changes and an HDD which can read 100MB/s it’s rather simple to arrive at scenario where no data is uploaded for 5 minutes and then the ETA is broken. Dividing the bytes to be processed (which cannot know yet how much will be deduplicated) by the upload rate will result in a permanent overestimation.
restic only knows how much data it would have to upload right at the end of a backup run and not a moment before. It is just not possible to accurately estimate beforehand how much data still has to be uploaded, as the deduplication only happens while processing the backup data.
Take for example the 50GB VM image, the first 20GB could deduplicate perfectly, then there’s 1GB with changes, which is uploaded at 1MB/s. This gives use 30GB remaining at 1MB/s = 8 hours ETA. However, the next 29GB can also be deduplicated. Which results in 1000 seconds upload time and 500 seconds processing = 0.42 hours. In which case the 8 hours ETA was a rather bad guess.