Already working on that, but I don't have a release date for that feature.

It's an ongoing problem that is being investigated by our developers. According to the latest info improvements will be made in version 2.9. It seems they were able to localize the problem with RAM and are testing things internally.

Meeting capabilities are incoming, but I don't have a particular release date for that version yet.

The old versions will be eventually purged according to your retention policy. You can also start from scratch if they are no longer needed. Starting from 6.0 the process of seeding is actually much more streamlined due to these changes, especially for Snow/Fire/Wasabi balls.

In general, there shouldn't be any conflicts when moving data containing both delimiters.

A quick update on the issue.
Here's what was found:
1) The disk where the backups have been stored died(hardware failure) and data was restored using third-party data restoration tool.
2) During disk restoration using that third-party tool it corrupted encryption headers of our backup files, making them unrecoverable. There's also a chance that they were simply corrupted during the disk failure, we'll never know at this point.

For some reason that crucial part of the problem was not mentioned neither by you or your colleagues initially, but we finally got to the root of the issue.
Even though our software is not at fault here, we'll do everything in our powers to restore your data.

To avoid problems like that we recommend using cloud backups along with the local ones, so that if you are faced with a hardware failure the files can always be recovered from the cloud.

I suppose we can add master password improvements similar to the ones we made for the backup software in one of the future versions of the app. I created a feature request on your behalf on our side and forwarded your feedback to our developers.

The issue has already been escalated to level 2. Writing this message while literally sitting near the guys who are in the remote session either with you or with your colleagues. This seems to be a quite unique issue, so I suggest to continue communication with the techs.

Sent the message to the tech responsible for your case.
We already have target release set to version 6.2.1, but there's no ETA and no workaround, as far as I'm aware.

I wouldn't rely on any of the "Drives" as a storage provider. They have severe API limitations and prone to throttling upload/download speeds, making every backup/restore procedure quite troublesome.
In short, these providers are not really designed for automatic backup procedures. That was a difficult decision, but we had to do it.

One of our engineers is already in the remote session, as far as I'm aware, the ticket will be escalated after that.

The best way would be to write an email to supportatcloudberrylabdotcom, they'll transfer your request to licensing department and assist with license conversion.

I see your colleague Joe already contacted our support department. The best way to get to the bottom of this would be to follow my colleague's instructions, step by step. I'll try to get attention of our level 2 department to this ticket, since the issue looks unusual.

Old data purge happens only upon successful plan run.

If you simply need to delete every piece of data uploaded fro ma certain machine it's better to follow this guide: https://mspbackups.com/Admin/Help.aspx?c=Contents%2Fhelp_drop_users.html

Issues like that can be caused by the infamous "Error code: 1219". Check the console.log file in C:\ProgramData\Online Backup\logs.

If you see "Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again" message I suggest to check out this article: https://serverfault.com/questions/919337/how-to-clean-up-old-connections-before-mapping-a-new-drive

Thanks. I see that the issue has "escalated to developers" tag, so unless our R&D comes up with a workaround you need to continue communication in that ticket. The problem is under active investigation and seems to be exclusive to Wasabi cloud.

Send me the ticket number via PM, please, I'll check it.

The software doesn't create any additional temp files on S3 side, so these are probably created By AWS, they'll be automatically deleted soon.
I can also suggest to check if you have "show deleted versions" option enabled under tools > options > versioning.

As for the objects, what exactly are you referring to?

If it works properly right now most likely the issue was related to problems on storage side. It's not uncommon for Oracle cloud.

What type of plans are you trying to implement? Only file backups? Only image based ones or a mix of both?

Judging by the screenshot, the software is most likely occupied with the other plan that I see above it. Such issues can happen if you run several plans at the same time using the same destination.

If you still have issues with this plan we require diagnostic logs for further investigation. You can send them via tools > diagnostic menu. Make sure to specify this forum thread in the issue description.