Better to open a support ticket regarding that, but most likely there's a problem with connecting to our Amazon SMTP servers, so before creating a ticket I suggest to make sure that AWS servers can be reached from your machine and no-replyatcloudberrylabdotcom is white-listed in your mail filter.

Not familiar with this AV software, but usually adding the executable and cloud storage IPs is enough for 99% of such applications.

Removed the key from your post, because it's not safe to post such information here.

Regarding your problem:
1TB limit means that you can at any time have at most 1TB of data on the cloud account managed by CloudBerry Backup. E.g. you can upload 800 GB, then another 200GB, then delete 300GB but you can't exceed the limit of 1TB. The limit is imposed on Aug, 15 2014 and it doesn't affect any purchases made before.

To be able to back up more than 1TB you need CloudBerry Backup Ultimate Edition.

You can upgrade by paying the difference:
https://www.cloudberrylab.com/upgrade

If you're sure that your current data set doesn't exceed this limit you'd need to contact our support department.

Here's an article on that: https://help.msp360.com/cloudberry-backup/miscellaneous/migrating-from-cloudberry-backup-to-mbs

There are no consistency checks for Linux/Mac software. If you need to update the information about the files in the cloud via MBS panel you can go to to RMM > Remote management, click on the "gear" button, and select Edit > Options. There will be "repository" section where you can perform synchronization.

Consistency checks are usually only needed if there's a chance that files are changed/deleted in the cloud and there's currently no way to schedule the sync process.

Looks unusual, so we would need you to create a ticket in our support system to troubleshoot that.

Just points 1 & 3 or 2 & 3 will be enough.

Make sure that all of the versioning is handled through our software via the retention policy and you should be good.

Can you confirm that these issues only happen when the AV software is running?

The case has been escalated to our level 3 team, for now please continue communication in the ticket.

So, for me as an individual user with no business critical data to back up, what are the risk if not using encryption when uploading files? — Roger Averdahl

Well, the main drawback is that unencrypted files can be accessed by someone/something else if handled incorrectly.

If i go to File > Export Settings, are the Encryption password exported as well?
If i go to File > Import Settings, will the Encryption password imported as well? — Roger Averdahl

Yes, encryption settings will be saved in a config file in an encrypted state.

What are the main pros and cons with encryption? — Roger Averdahl

I guess I answered that question already, but the main advantage is more security in general, and the main disadvantage is that you won't be able to access the data if you lost the encryption password.

Try using this command via Terminal:

sudo chown root:root /opt/local/Online\ Backup/OWNER-ID/plans

Owner ID should be visible once you get to that location.

Where are the source files located at? Is this a situation where you're backing up files from another machine via network share? In that case the files will be first transferred to a machine where the software is installed and then the data is sent to the cloud.

Yeah, full is required for proper purging of your data. The software only deletes old versions in chains of full + incrementals, so if retention is somehow misconfigured you'd end up with a lot of data that is not being purged. The best way to set it up is to run full backups more frequently.

If there are problems with slow local upload speeds it's better to contact support regarding that, since it could be a technical problem.

In that case we need to receive the logs right after you try using the standard retrieval rate. Please reference the existing ticket while doing that.

In general, we currently don't recommend using "classic" Glacier, since it's much easier to restore data that way.

According to the log information you're currently running expedited restore. The Expedited retrieval option is not intended to be used to retrieve thousands of file. Currently I can suggest to recreate the restore plan, set retrieval rate to standard, and launch the plan then wait at least 10 hours.

That's in the works, please bear with us. As for the "Inconsistent backup" error message, please contact our support team, we need to log that incident in with our developers, it's a known problem.

Try making an object public, that should help: https://aws.amazon.com/premiumsupport/knowledge-center/read-access-objects-s3-bucket/

Priorities have shifted and the issue is more complex than we though initially, so it'll be fixed in v 6.4.

Well, that's your choice, if you still need the old data as it is it's better to start from scratch using a new bucket. You can also continue to upload everything to the old one. If computer's name is different now the files will be uploaded under a different sub-folder, but you can specify the old computer name while setting up your storage.

Most likely that's a known issue our developers are working on. To confirm that make sure you're on the latest version of the software, reproduce the problem, and send us the diagnostic archive via tools > diagnostic menu.