I have shell access, but commands are limited.
Structure looks normal.
Chunks, Config and Snapshots are the only things in the folder.
Another idea. Since this is an sftp client (is it?), duplciacy uploads into a temp file, and then renames it. I’m wondering if due to some glitch the target system copies instead of renaming? or has some other mishap in the similar vein.
Or perhaps duplciacy fails to upload half way, and those partially uploaded files keep accumulated for some reason? Maybe the provider has some sort of versioning?
Literally grasping at straws…
No versioning, and commands to create, move, copy, delete, etc are not limited.
Just re-ran DU. I wonder if it’s just taking forever to delete chunks. It’s now down to 3T.
Wait, I thought exhaustive prune has completed, did it not?
So after waiting, it finally caught up. I think the prune may have finished locally but was taking time to catch up remotely. It shows 2.4TB now remotely. Though still makes me wonder, if it’s mostly music, why there’s half a TB over what’s local. Either way, glad to have figured that out. Thank you Saspus! 
2 Likes
I’m glad it is sorted out now
There is a quirk in logging, where when duplicacy says “deleting chunk blah” it does not actually delete the chunk that instant. It just collects its name and will proceed deleting all collected ones in the very end. It’s a misleading log message and I have stumbled on it myself in the past.
So I guess if you were watching prune “deleting” chunks but space on the remote would not change — that’s why.
There a few reasons you may have ended up with orphaned chunks: interrupted prunes, manually deleted snapshots, and similar instances when chunks that are no longer needed stayed in the remote.
2 Likes