Yeah, that's a bug, but I think you're actually the only one who got it. It's only been discovered recently by our testing team and judging by feedback in our bug-tracker it's incredibly rare.

Real-time backups send notifications every 24 hours and notification emails look like the ones that are sent via regular plan. You just need to specify to receive notifications in all cases.

We consider it as a legacy protocol and have stopped offering it to our customers

We recommend Minio - self-hosted S3-compatible storage server. Should work much better than SFTP.

Minio main website
Minio documentation page
Setup guide

As for the ciphers, this thread might help: https://forum.cloudberrylab.com/discussion/comment/247

In general, it all depends on the environment.

You can release the license yourself via Licensing menu, like on the screenshot:

After that it will be available for activation on a new machine.

If the old machine is no longer available just drop an email to supportatcloudberrylabdotcom regarding license release and we'll reset it on our side.

The first point sounds like a good feature request. Please write an email regarding that to supportatcloudberrylabdotcom so we could officially register it in our system. Mention that it's related to this forum thread.

Seems to be one of the issue we're working on at the moment. The software is still being tested and refined, so many improvements will be made in the future on that front.

Difficult to say what causes that behavior. I suggest to send us the logs via tools > diagnostic menu. Mention this forum thread, please, in the issue description so the ticket gets to me.

In my opinion, it would be better to continue with your current setup until version 6.0 is released, since it's already working fine for you.

If you have a lot of small files you need to make the following changes, since block-level mode won't bring any benefits in that case:

And that's basically it. Full backup option will be automatically disabled.

If you have big files(about 1 gig) block-level option would be beneficial and you can leave everything as it is if it's already working for you.

Rotating drives strategy is mostly used when the drives are wiped before every backup.

In your case you would need to mount the correct drives upon each full backup, which is not very convenient. Most of the clients use fresh disks each time to have full copies of the data there.

So you have 2 options

1) Disable block-level option and use full copies of the files(only the files which are changed will be re-uploaded in full)

2) Continue with block-level option and schedule full backups more frequently according to your retention policy.

If it's a file backup plan, the first option would be optimal, since file backup don't get much benefit from block-level mode as much as image-based ones.

Proper GFS mode will be released next year in version 6.0

In your case you would need to install at least Server edition of the software on a VM itself and use CLI to create image-based backup plan like specified here: https://help.cloudberrylab.com/cloudberry-backup/command-line-interface/backup-restore-plans/managing-image-based-backups.
VM edition for now can't be used on Core servers.

Due to incompatibility between these services such operations can only be performed via your machine. Direct cloud to cloud backups are not possible between different types of storage providers.

It's the latter, since those are 2 completely different cloud storage providers.

All of that info comes from the local repository and its history records. As David mentioned, the best way would be to use our managed backup product, but there may be third-party solutions that will help in monitoring backup statuses.

Not sure what you're referring to. I need more info regarding your setup.

Added as per your request.

First the software actually performs 3 retries(or the amount you specified) and then it actually continues with another 99 retries after that, so currently that's expected and the application will try to upload the files for a long time.

Yeah, that's actually quite expected, so sync should help in your case.

Thanks for the update.I suggest to continue communication in the ticket if the issue persists and re-send us the logs.

A1. Full backups are purged together with all block-level ones after another full backup, so in your case the 4th full backup will purge the oldest full + blocks.

A2. Looks ok to me, this is one of the more popular scheduling setups. If you want purge to happen more frequently you can schedule full backups once a week.