Thanks, I appreciate the clear instructions. I will give it a try.

I just updated to the latest version and noticed that this is fixed now. I see a yellow exclamation point for failed consistency checks. Thanks.

Thanks Matt, I appreciate you looking into this.

Matt, I wonder if you might have misread Bhesh's question? As I read it, he wants files to be deleted from the local computer, that is backup source, not from the backup target. If my reading is correct, he wants to use S3 as an archiving solution, not a backup as that's normally understood.

I'm glad I could help. Good luck with the fix.

Done.

No. I assumed this was the right place for a bug report.

I don't need support for this issue, it's a minor thing, but I thought you wanted to know.

Sorry for lack of clarity. I meant C:\Users\<username>\Documents\

This happens even if I have no applications open. I tried running the backup plan twice in a row and got the above-mentioned log entry both times. I did the same for my other backup plan backing up the same files (see my initial post) and got no log entries at all, as expected.

Both plans are set up to backup the above folder and both use the same file filter ("~$*; ~WRL*.tmp; desktop.ini ; .dropbox").

I repeat my question from my initial post, is it somehow possible to see which file it is that CloudBerry thinks has been deleted?

I could try deleting my local storage and starting over. That might solve the problem but then we won't be able to find what I assume is a bug. Do you want me to try this?

No. This particular plan only backs up my Documents folder.

The other plan, which runs once per day and doesn't produce this log entry, backs up my Documents folder plus a few others.

Good question, Jan. I too would like to be able to manually launch the UI for file deletion. Hopefully such a feature will be implemented at some point.

Thanks Matt. I'm fine with slow restores but not one minute per file. That would equal more than 40 days for my quite moderate archive of 60.000 files.

Luckily, things seems to speed up for larger restores. I tried another restore of around 800 files and while that took 40 minutes all in all, somewhere around 95% of the files were restored within a 10 minute windows.

So I guess GDA scales quite nicely.

Problem solved.