This information is currently not available on the summary screen. I've filed a feature request on your behalf to our developers.

By local database(repository) I mean the cbbackup.db file that is located in C:\ProgramData\CloudBerryLab\CloudBerry Backup\data by default. It is a file that contains records of all files uploaded to the cloud to avoid reaching out to cloud storage every time you need to check which files are there. So in case the data was changed outside of our software you would need to either
run consistency check or synchronize the repository(tools > options > repository) for the software to update the info about your files on the storage side.

After consistency check/sync is finished you can navigate to the backup storage tab to see the most up-to-date state of your files.

Going via Explorer would basically work the same, each inventory request would take about 5 hours to complete, but status of some newly uploaded files still won't be updated momentarily, since they need some time to "settle" in Glacier after upload.

Regarding your questions/issues:

1) It's difficult to say what's affecting the speed in your scenario. The best way would be to send the logs to support via tools > diagnostic menu and we'll see if something is affecting it.

2) That is just how our licensing model works. You can use restore-only version that is always free to restore your data without activating a commercial/trial license. Also, this version does not rely on local repository, so in case of disaster recovery you don't need to wait for it to be rebuilt.

3) This setup should work fine as long as you have CPU credits. Just send us the logs and our support guys will look into this issue.

Try deleting the following file C:\ProgramData\CloudBerryLab\CloudBerry Explorer for Amazon S3\queue.list", that should reset the status of queue.

Plan configs are actually stored in .cbb format and are located in C:\ProgramData\CloudBerryLab\CloudBerry Backup by default.

You need to replace the part below after creating a new hybrid plan.
<Items>
<PlanItem>
<Path>C:\</Path>
</PlanItem>
</Items>
It is responsible for your selected backup set.

Please note that a new full backup will still be triggered upon launching such plan, but only the files that are changed will be re-uploaded in that case.

In the future we'll introduce an ability to switch between regular and hybrid mode by editing a plan.

Consistency checks are not really needed for Glacier due to specifics of that storage class(basically, once uploaded you need to try very hard to actually change data on their side) and their long inventory updates. "Resolved" status means that the records in your local database have been corrected according to the info that consistency check was able to acquire from storage.

As for the encryption password and schedule:
1) You don't need to specify the password if you data is not encrypted.

2) Scheduling problem is a known issue which we're working on. R&D is already preparing a fix.

Not yet, but I've filed a feature request to our developers on your behalf.

We've received several memory dumps from affected users and that helped our developers to identify the problem. The fix is already in the works.

This is just how our developers decided to name that option. It simply switches VSS on and off during backups.

Local files that locked by other software are impossible to back up without VSS, so currently my only assumption is that they were actually not in use by the time you were launching your second run of the plan.

This is a known issue that is related to restore-only mode being used. Please activate trial or commersial version.

This soon will be fixed by our R&D.

On the first run, the email report says "Error: Warning.[sic!] One or more backup paths don't exist". Later it says "files failed to backup: 3". Does this mean that the "failure to backup" is the "warning"? (I can believe that an occasional file gets deleted before it gets backed up. That's not a problem; I'm just trying to understand the messages.)
Yes, that's just a warning message about some files that are failed, so most of your data except those 3 files is safely placed on storage side.

Regarding those 53 failed files: Most likely they were actually in use by some other process during the backup. I suggest to make sure "Always use VSS" and "Use system VSS provider" are enabled for that plan to avoid issues like that.

In cases like that it is better to investigate the issue by inspecting the logs.
Please send them to us via tools > diagnostic menu.

Looks like you're using freeware version of ESXI.
Please refer to this article: https://kb.msp360.com/standalone-backup/esxi-&-hyper-v/current-license-or-esxi-version-prohibits-execution-of-the-requested-operation

You either need to upgrade your VMware to full version or use image-based backup by directly installing our software on a VM.

The easiest way would be to simply install this build, it contains both image-based and VM functionality.

Yes, both variants are possible.
If you want to restore that backup to Hyper-V please follow this guide: https://www.msp360.com/resources/blog/how-to-perform-physical-to-virtual-restores/

Restore to Azure VM: https://www.msp360.com/resources/blog/how-to-restore-to-azure-vm/

Regarding installation:
If you're using Server version you need to install the software on the VM itself and perform image-based backup.

For VM version you can specify server IP for our software to reach out to it. Please follow this guide: https://help.msp360.com/cloudberry-backup/backup/back-up-vmware-virtual-machine

There is no "direct" transmission either to Hyper-V or Azure VM, you would first need to back your data up and then launch the restore operation.

All of these options, except for the first one, are available in our managed backup software.
You can receive scheduled backup reports and status notifications when your plans skipped their schedule.

This is not yet available, unfortunately. I've filed a feature request on your behalf to our R&D.

We're already working on a separate "hidden PCs" section, but currently you simply need to make sure the machine is online for it to be visible again.

Yes, that is correct, but sending the memory dump would certainly help in speeding up the process.