You can actually select the other files with shift-left click and then delete them en-masse. We'll improve that functionality in one of the future versions.

Could you please clarify what exactly do you want to modify so I could form a proper feature request?

Thanks for the feedback. Forwarded that info to our devs for evaluation.

It's better to open a support ticket regarding that. We need to see what errors are given by our software. Go to CloudBerry Drive tray icon, right-click and choose Diagnostic, use "Send to Support" button there. The logs will be sent to our support team automatically.

I see you(or one of your colleagues) already send diagnostic logs regarding the issue. We need some time to investigate them. For now I suggest to continue communication in the ticket, since we would most likely require additional info from your side.

The best way would be to use the backup software, so you wouldn't need to change/rename anything. After transition is complete you simply need to run repository sync for new storage destination on the original machine and you're good to go.

Yes, that will be possible. The setup is pretty straightforward, you just need to correctly specify the path to the storage destination after the data has been transferred and synchronize the repository via tools > options > repository after you finished transferring the data to its final destination.

As for slow image-based backups to network share - that is a known rare issue. Target release for the fix is version 6.0.1, which is scheduled for release in October.

There are, of course, plans to publish a doc like that and we're working on it, but there's no concrete release date.
I've added you to the list of people to be notified upon its release.
For now the only source of documentation is our Help section.

As with any similar situation, I can suggest to update the software to the latest version, make sure "Use System VSS provider" option is enabled, and in your case you can try to set schedule to the time when you run the plan manually, since something else in the system might be using VSS.

Since Glacier archive is performed via S3 lifecycle policy you need to specify your S3 bucket and not Glacier Vault, so perhaps you tried to specify your vault at first instead of the bucket. Perhaps your previously created bucket was created in a different region.

No support for this cloud storage provider yet, but I've forwarded this feedback to our devs.

Forwarded my colleague's latest reply to your address(that's the only way, I guess).
Ticket number should be #86554

Just noticed that there's also ticket #101882, which is newer, but the problem is similar. You can also request to add you to that ticket directly via supportatcloudberrylabdotcom

You might want to follow the instructions here or re-register VSS components

First of all, make sure VSS works outside of our software.

We don't have plans on that for now, so currently the only list of fixed and known things is available via release notes.

For Mac/Linux versions of the software Glacier backups are performed via lifecycle policy, as specified here: https://www.msp360.com/resources/blog/introducing-backup-for-mac-linux-2-8-1/

As for the bucket name, it must be universally unique and contain only lowercase letters.
More info on that here: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-s3-bucket-naming-requirements.html

The location of backed up data shouldn't matter. As long as you see the data on storage side you should be able to restore it. Anyway, it's good that you've found a suitable config for your setup.

You can restore your data directly into your existing environment, like described here: https://help.cloudberrylab.com/cloudberry-backup/restore/restore-types/sql-server-restore

Yes, there's a thread limit in the Free version. You can adjust the amount of threads in commercial/trial version of the software.

I only see the original logs and the error message that refers to network credentials.
I suggest to re-send the logs to the original ticket after making sure the credentials are 100% correct and continue communication there. Also, since it's a hybrid backup I would suggest to synchronize the repository for both storage accounts via tools > options > repository, but the first thing is to make sure the software can transfer the data to the local destination.

Ok, thanks for the detailed explanation!
Forwarded that info to our developers and created a feature request on your behalf.