May be a problem with backup service.
Try reproducing the issue and send us the diagnostic logs(tools > diagnostic) for further investigation.

This will be introduced in version 6.1. If everything goes right the build will be released this week.

Thanks for confirming that! Yes, support for EU buckets is on the way.

Do you see "incorrect function" message like in this thread https://forum.cloudberrylab.com/discussion/922/drive-with-wasabi-incorrect-function?

If so, try adding the account as S3-compatible storage.

Repository database is corrupted, so you need to recreate it.

- Open Backup software and make sure there are no running plans
- In the left bottom corner right click "Backup Service" and choose "Stop Service". Do the same for RM Service if you can see it.
- After that close Backup software interface.
- Navigate to the database location: C:\ProgramData\CloudBerryLab\CloudBerry Backup\Data
- Delete "CBBackup.db"
- Launch Backup software, the repository sync process will be started automatically.
- You will need to start Backup Services back manually - the same way you stopped them.

You can monitor the progress on Welcome tab under the Storage Accounts section
When sync is complete, you can see backed up data on the Backup Storage tab and continue working with the backup.

Yep, found the ticket. Check your inbox, I already sent you the link with the build.

This problem will be fixed in version 6.1 which is scheduled for release next week(although delays may happen). If you create a ticket by sending us the logs with reference to this forum thread I might be able to provide an early build.

Setting up and performing backups via RMM is actually the best choice in your case.

There's not much to recommend here, to be honest. For all of your backups just use these instructions to create and manage your plans.

If you're using just one VM you can install desktop/server license on it(unless you also want to back up some data from the host) and use image-based functionality.

That'll be quite problematic to implement, but I'll consult with our devs on your case.

Try to enable "Use system VSS Provider" option first, if that doesn't help follow Klim's advice and we'll continue investigation in the ticket.

The folder structure is most likely different. Compatibility between Linux and Windows is not 100% tested, but the first thing I can suggest is to check if the folder structure is identical and also to try switching the backup prefix be editing your storage destination and clicking "advanced options".

Just re-send the code to you. To anyone who also experiences this problem: just write an email to supportatcloudberrylabdotcom and one of our engineers will re-send an activation email.

If it still doesn't run send us the logs via tools > diagnostic menu. Make sure that skipped full backup is (supposedly) among the last 10 runs, that way we get more info on that.

Most likely the full backup was in overdue status but then block backups cleared it out. Try running your backups with the setup you mentioned, should work without problems.

I usually recommend running fulls every week because it'll make versioning and purging more consistent. If additional versions on storage side is not a problem then you can run full once a month. In your case that's pretty sensible, since Wasabi charges for early deletions.

In most of the cases simply specifying full backup for the second plan in chain should help, but make sure you have a a pretty big Windows between the runs to make sure the software is able to finish one full backup and start the next one. Basically, the second plan only needs to have full backup scheduled and that's it.

Now, regarding the rest of your questions:
Synthetic full will appear just like a regular full, so you don't need to worry about that. As for 6 months of block-level backups, this actually might be a problem. A small one, but a problem nonetheless.
The thing is, purging only happens upon full backups and only in chains of full+block, and if you're setting up a time-based retention purge of the oldest chain will happen only when its last block is old enough(let's say 90 days), meaning that previous backups will be much older and they'll still will occupy your storage space.

My suggestions on setting up your retention policy:
Since synthetic full will take much less time to complete I recommend running full backup once a week and use your existing retention settings. That should be optimal in terms of purging, versioning, used space and the amount of data kept on storage side without triggering early deletion fees from Wasabi.

Regarding full backup size: It'll be the size of a proper full backup, but the software will reference previous full + blocks to merge all previously uploaded data with changes that have been performed since the last plan run. Synthetic full is usually about 5 times faster than regular full because of that. On some configurations I got even better results.

Sorry, we don't yet support native Windows deduplication, there are still some things to iron out before this functionality will be implemented.

I don't see any signs of "corruption" of your data in the cloud, it's impossible to corrupt anything once it's in the cloud, unless there are problems on storage side.

Removing hundreds of thousands of files might take some time to complete for obvious reasons, since this will require both sending a deletion request to the cloud and updating our database regarding any removals happening.

I understand the need for such functionality but the implementation for this feature will not happen in the nearest time. If you have a concept on how to implement this on our side I'll be glad to forward this feedback to our developers.

Please keep things civil here. As I already mentioned, I'm waiting for your feedback in the ticket system. Continuing technically-related conversation on forum will not be efficient in any way for both sides.

Do you have them already mounted in the system? I mean, are they visible in OS? Can you provide a screenshot?