Security is not the main problem here. For Wasabi it doesn't really make a difference, but on B2 that could cause performance problems due to their API limitations.
As for security concerns, it would be better, of course to give each user their own bucket for better destination tracking.

Good to know about B2. Obviously with my previous recent questionsl about Wasabi I'm in the process of trying / switching to them.

What do you mean by destination tracking? You mean to make sure what the CBB client / MSP portal storage used matches what Wasabi say? So they both show 1 TB used etc?

It's more simple than that. Some of our clients simply prefer to track individual bucket names instead of checking which destination is assigned to a particular user/company.

Just add something: in my opinion the best way is to use bucket per company setup: you get enough granularity and destinations are really easy to manage.

Right, that makes sense. I was thinking about destination per user, but that seems a bit too granular. Most places we only back up a server, but we have a few customers with multiple users' machines we back up in addition to the server.

I did some research on Wasabi and found out about the 90 minimum charge for data. So, we'll probably just plan on 90 day retention as not to waste money. For DR purposes 30 days usually feels sufficient.

When the synthetic full backup runs, does it copy the previous full backup cloud to cloud? Or does it just reference it and say "keep this backup"? I'm wondering if synthetic full backup #2 & #3 will each use the same amount storage as the original full. Say Full #1 100 GB + Full #2 101 GB + Full #3 102 GB.

The way I understood the blog post is that it's going to be the same a regular monthly full, but instead of uploading from the local machine we are copying what's already there. Sort of "side-loading" into a new backup set. Is that correct?

The software detects what's changed locally, compares to what's available in the cloud and then copies only the changed blocks. The rest of the process happens in the cloud. After upload all of the parts are merged together. Synthetic fulls always rely on previously performed backups + all changes that were performed between backup plan runs, so in terms of time synthetic fulls usually take as much time as block-level uploads.

So, in terms of storage used - it seem like multiple synthetic full backups won't use the same amount of storage as say 3 x full image backups. So, we're always building on the 1st full?

I'm going to have to play around with my test machine, and take note of storage amounts used in my Wasabi bucket. It sure seems like the each monthly shouldn't be much larger than a block level - if I'm understanding.