Sorry, not sure I understand you, but custom mode should actually automatically create your specified folder on storage side.

In your case you'd need to install SQL version on VM itself to perform database backups properly. Otherwise those VM backups will only contain SQL environment in a "frozen" state as a part of a VM backup.
Make sure you're not running those backups simultaneously just in case.

The files themselves shouldn't cause the plan to fail. The status will be "Completed with warnings", so those files are skipped, but for now they generate the error message due to how Windows tries to process them.

That's quite unusual. Excluding those files always helps.
For more details we need diagnostic logs from the software. You can send them via tools > diagnostic menu.

As for the versions, 6.0 will be available very soon, maybe even next week. 6.1 should follow-up shortly.

If that's the issue I'm thinking about, it should be fixed in 6.1. Should be available in about a month, maybe a little bit later.
If the issue occurs when backing up Mac "icon" files it's better to exclude them for now.

Correct, but that can only happen if you consciously send us the original config file of the plan from your HDD. Even when sending diagnostic info using automated procedure the password string is modified so that it can't be recovered by anything. It becomes just "*" symbols.

Forwarded your request to our R&D. If you have any more details to add regarding your request, feel free to specify them here.

We wouldn't be in backup business for long if we stored anything in plain text :)
Upon entering encryption key it is actually immediately encrypted, obfuscated and only then sent to the machine via secure connection.
You can't really extract the password from the config file in any way.

Shadow Copy errors refer regular folder paths that go after "GLOBALROOT", so you just need to select/exclude correct folder on your HDD and that's it.

Yes, the only option would be to recover the whole database. Introducing that functionality for all other versions of Exchange is on our road map, but implementation is taking longer than expected due to technical peculiarities of the process.

That's on our road map, but I don't have any ETA yet, sorry.

If everything was deleted from the backup destination all you need to do is to go to tools > options > repository and click "synchronize" for both accounts. That should help.

We'd need diagnostic logs from the machine sent to us via tools > diagnostic menu for further investigation.

Make sure you're on the latest version.

That should be available in about a month in version 6.1.

Seems to be unusual. I suggest to send us diagnostic logs via tools > diagnostic menu and once the ticket is created to attach a couple of screenshots with cbbdeleted files being visible.

Wasabi is actually a great choice overall, so feel free to test and see if it suits your needs.

None of the "consumer" storage providers support file name encryption, they simply weren't designed for that, so only enterprise-level cloud solutions allow to use file name encryption.

That's a bug that allows to enable file name encryption for Google Drive(which it doesn't support).

The best way would be to start your backups from scratch and make sure you don't click "enable" for FNE in "quick edit" section.

Also, I wouldn't really recommend using Google Drive because of bad performenace and security concerns. More info on consumer storage can be found here: https://www.cloudberrylab.com/resources/blog/consumer-storage-services-flaws/

The bug itself should be fixed soon.

Yeah, if it's a cloud destination you'd need Explorer to do that.

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.