This may be a problem related to mshtml.dll mentioned in the error message.
First thing I can suggest is to run SFC scan:

1) Press Windows key + X, select Command prompt (Admin) to bring up elevated command prompt.

2) In the command prompt type the following command: sfc /scannow and press enter.

Once the scan is done, restart the computer and ensure that the computer is up to date with the latest Windows Updates.

Recycle bin and page file are excluded automatically, you don't need to worry about that.

Even if you exclude recycle bin manually nothing bad will happen during restore.

Yes, VM backups require Server OS for technical reasons.

Yeah, our software works well with Azure, but they have the same long path/file name limitation like OneDrive. AWS S3 doesn't have those limitations and Google Cloud allows any sequence of valid Unicode characters, of length 1-1024 bytes when UTF-8 encoded. There is also Wasabi and B2, which are pretty popular and don't have such limitations.

Setting up separate job for each database is not a bad idea, but I want to mention that currently we can only recommend to chain only the file plans. There is no option to set up full backup for chained plans
Until we implement separate backup schedule for each plan the best way would be to try and re-schedule the plans manually, unfortunately.

The second option with just one database and 2 plans is not going to work due to how Exchange operates.

The main problem here is that freeware requests require internet connection and TLS 1.2 protocol. Do you use proxy by any chance?
Freeware is intended for personal/home users, so there's no CLI activation. On each PC you need to click "I don't have the code" and enter user's email to activate the software.

If you have the original backup plan for these files intact please contact our support team.
Overall, if you change the pass for the plan all of the data set needs to be reuploaded.

The link will only work for the administrator accounts. Make sure you're logging in under the right one to check out the link.

This is the repository database. It is used to track all file transfer operations in our software, the backup plans rely on this database to determine if a file needs to be uploaded to storage side.
The size of the repository depends on the number of files in the cloud(or local destination, for that matter).

You can change repository location via tools > Options > Repository menu. Make sure to launch the software as administrator when doing that.

If it's an old database and you want to clear it out you can recreate it by doing the following:
NOTE: this is a time consuming process, especially if you have millions of files on storage side

- Open Backup software and make sure there are no running plans
- In the left bottom corner right click "Backup Service" and choose "Stop Service". Do the same for RM Service if you can see it.
- After that close Backup software interface.
- Navigate to the database location: C:\ProgramData\CloudBerryLab\CloudBerry Backup\Data
- Delete "CBBackup.db"
- Launch Backup software, the repository sync process will be started automatically.
- You will need to start Backup Services back manually - the same way you stopped them.

You can monitor the progress on Welcome tab under the Storage Accounts section
When sync is complete, you can see backed up data on the Backup Storage tab and continue working with the backup.

Can you provide a screenshot of how those files look on storage side? Do you see 2 versions of a file created when you go to the backup storage tab in GUI and click on it?

Sorry, just noticed this post. Yes, it is a valid setup. Just make sure that plans don't overlap in schedule.

You can still do that, but at your own discretion. For now it's only available to the clients who already have OneDrive added in the software.

Yes, local backups are not taken into account in such case.

Thank you, looks like I was indeed incorrect, sorry. Currently there's no such functionality on our software, so I can only suggest to delete the files via automatic Powershell script, or do it manually.

Do you have any files with 0 byte size in the data set? Glacier archive doesn't support such files.

What I meant by "caveat" is that by default we use cache folder to buffer all the data to display, and if you have millions of files in your data set the performance won't be ideal. This is a pretty interesting setup, so the best way to check if our product suits your needs is to install the trial version and check how it performs in your environment.

Currently selecting root is not the recommended course of actions. Most of the files can very easily be recovered from installer packages or are completely useless for restore purposes.
For now CloudBerry Backup for Linux/Mac only features File Backup which does not guarantee that backup/restore would produce a working machine right after restore.
Instead, we recommend running backup of only specific system configurations, production data, and users' data.

We usually recommend to backup contents of:
/home (user files)
/etc (daemons configuration files)
/var/* (only the subdirectories that are needed, like /var/mail, /var/mysql, /var/www etc.)

In some cases, you might also need to backup data from:
/media or /mnt (if there's a mount point containing valuable info)
/root (if there is any important information or settings in the home directory of the root user)

And this is what should not be included in the backup:
/boot
/dev
/var/run
/tmp
/sys

Here's the standard that describes filesystem hierarchy, might be useful to identify what to backup and what not to: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

So the first thing I can suggest is to update your data set, and if the problem persists please open a ticket in our support portal.

Thanks for this info! Yes, indeed, native scheduled VSS snapshots may cause this problem.

There are several reasons for the issue to occur, including connection time outs and network device changes. In most of the cases the issue is indeed related to incorrect time sync, the problem is prevalent in domain machines where there's a problem with syncing time on Domain Controller.

Thanks for the screenshot. This Window simply warns you that you enabled block-level option while actually choosing the backup to be incremental. These simple templates are configured automatically, so during incremental backups VSS is disabled.