To get more specific at the risk of being off-target:
I don’t have SharePoint, but OneDrive personal has a Recycle bin on the side, and a Search at the top.
Possibly you can figure out the history of some files. Duplicati’s big ones would have dblock in names.
The Duplicati database also has history in <job> → Show log → Remote, but sometimes DB is locked.
About → System info has Server state properties, where lastPgEvent can give info on where things are.
- lastPgEvent : {“BackupID”:“1”,“TaskID”:2,“BackendAction”:“Get”,“BackendPath”:“duplicati-b199748aa266d4bd78862ca9136d68a88.dblock.zip.aes”,“BackendFileSize”:52336829,“BackendFileProgress”:52336829,“BackendSpeed”:154660,“BackendIsBlocking”:false,“CurrentFilename”:null,“CurrentFilesize”:0,“CurrentFileoffset”:0,“CurrentFilecomplete”:false,“Phase”:“Backup_Complete”,“OverallProgress”:1,“ProcessedFileCount”:6832,“ProcessedFileSize”:8146201281,“TotalFileCount”:6832,“TotalFileSize”:8146201281,“StillCounting”:false}
is mine, while sitting in a slow run-script-after. Comparing the Size and Progress numbers shows it’s completed work. If numbers were different, that might be a hint of which part of the work has stopped.
It’s also useful to look at performance tools such as Windows Task Manager to see if resource use is happening (CPU and Disk especially), or if everything just looks idle, and not trying to make progress.
This might have been a test of an initial backup that didn’t end, but maybe @D4NNK can confirm that.
Really frustrated with Duplicati’s lack of feedback has other ideas on debug of seemingly stuck cases.
EDIT:
That one seemed to be using a CPU core. The one here might be different, but you’d have to look at it. Disappearing files are also weird here, and I hope you can find some traces of it in the SharePoint info.