I wouldn't recommend performing software downgrade. If you're sending us the logs make sure you're on the latest version.

That should delete everything, versioning shouldn't affect this functionality.

Totally forgot about their 90 day limit. In general, more frequent synthetic full backups lead to reduced charges due to most of the operations being performed in the cloud, and purging happening more frequently, but for Wasabi you'd need to adjust it to keep at least 90 days worth of backups.

In your case nothing will really change in that regard, but keeping more full backups is better just in case there's something wrong with one of them.

On your screenshot I only see the link to the detailed report which contains the full list of the files. If possible, provide the screen where you see just a couple of files failing.

Weekly full is what I usually recommend to our clients, especially if you're using synthetic full feature. It keeps versioning more consistent and should actually reduce storage charges.

Bulk deletion is already in the works, but I don't have any ETA on implementation of this feature.

As for repository synchronization, you need to go to application settings and synchronize it manually via the corresponding "synchronize repository" button

You should see them via tools > multipart uploads.

These errors are returned from storage provider followed by 403 error.
Since we don't receive any other info in our logs and issue usually happens with less popular Openstack and S3-compatible storage providers I would actually suggest to contact their support and ask why issues like that happen during uploads.

Seems like you HDD may be in a bad shape, there are I/O errors during the backup procedure:
The request could not be performed because of an I/O device error
I see one of our support guys already provided instructions to at least mitigate such problems.
Also, I suggest to disable high logging in the software, it can slow down the backups significantly and only needed in in-depth troubleshooting cases.

Yeah, sorry, we're aware of that. Information on our web site should be updated soon.

You can try testing the script mentioned in this article and modify it to your needs: https://www.cloudberrylab.com/resources/blog/deleting-files-from-local-storage-after-a-successful-backup/

Better to contact support regarding this issue.
Send us the logs and, if possible, provide the script you're trying to run.

It's an experimental feature that is only provided in standalone version of the product. We're not yet ready to mass deploy it for MBS customers, but that is likely to change in the future.

Sounds great! If you encounter any other technical issues do not hesitate to contact our support team, they'll be always ready to assist you.

That sounds unusual.
First thing to do is to update the software to version 6.1 and send us the diagnostic logs(tools >diagnostic) along with screenshots and additional details regarding the problem if the issue persists.

Have you tried using unattended access? That should solve your problems regarding Computer ID and PIN.

It looks like you are creating new tickets regarding the same problem and those tickets go to different support engineers.I suggest to get back to Boris regarding this issue and make sure to communicate with one engineer to speed up the process.

I see your ticket in our system and asked the responsible engineer about its status. I suggest to continue conversation there, since R&D is already involved in investigation.

Explorer is not really intended for automatic operations with large amount of files, so yes, it's better to use our backup tool for big data set transfers.

GDrive's API automatically merges all file versions on its side and frequently doesn't allow the software to purge files effectively, that's the root of the problem.

Repository sync may help, but it's not guaranteed to resolve the problem.