, not really. It still takes a user to access any file including the automounted drive

It is a known issue that moving the database does not function properly. The investigation is ongoing, during this period the button will be hidden (with the next update). One of the consequences of the malfunction is that the History tab shows no info. Synchronization will not retrieve the History (because it's not saved anywhere except the database), but it helps if Backup Storage section is empty.

not yet - but I will file a request on your behalf to our R&D.

, the app will run backup of any changed files with filename encryption enabled. Files that have not changed since last backup are not re-backed up.
I assume you would expect it to re-backup everything, right?

, repository synchronization will NEVER delete anything in the storage, it just can't. Your ECBB data is there because there was no delete operation - you can do it manually or by a retention policy.

From your description I thought you want to clear all the ECBB data now and continue running backup with file name encryption off, is this correct?
In this case you should:
- delete the ECBB directory
- sync repository
- continue backup - everything will be reuploaded.

, when the feature is disabled, CloudBerry Backup will reupload everything from scratch (the software considers it different data).

I'd suggest to just delete the ECBB directory and then synchronize repository under Tools > Options > Repository (reference link) and then continue running backup with File Name Encryption disabled

I personally want support for other OS - most preferred is MacOS

, it should work fine if you use the Linux OS to run backup of both Linux and Windows partitions (provided that your distro has NTFS driver updated). Keep in mind, however, that our Linux Backup is younger than our Windows Backup and many features available in the latter are not yet available in the former - for example, running one backup plan to 2 destinations. You can still run two separate backup plans to different destinations though, just make sure to not allow them cross in time.

Glad to see you on this forum, hope you're well!

<joke>is this ok if CBL employees vote as well?</joke>

Backup plans that do not cross in backup source items AND backup destination are supposed to go fine (well, resource usage is a separate question).

If an MSP leaves the burden of managing and fine-tuning the software on the end-user, the latter may make mistakes and the MSP will be to blame.
If it is the MSP representatives who keep track of the settings, they should be planning the backup jobs in each environment so to ensure the same data is not backed up to the same storage simultaneously by several plans.

Frankly speaking, if you have 500 (ok, it's 2+) backup plans for the same data running at the same time - maybe you're doing it wrong. I mean, does anyone really need to have the same data in more than 2 places?

Anyway, the checks for overlapping are on our roadmap now but currently some troubles may occur in this scenario

your plan seems to make sense!

Should you need any assistance in the process - feel free to drop an email to supportatcloudberrylabdotcom, our guys will hopefully know the answers to whatever questions you ask!

, two plans running to different destinations simultaneously is perfectly fine if they don't backup the same data (except for increased reading load to the HDD and increased network usage).

Two plans for the same data to different destinations might still cause troubles because of concurrent write operations to the database (long story) and is generally recommended to avoid.

Hybrid backup will not stop the cloud backup part to let local backup part start again. It's a sequential backup - first local, then cloud - with no deviations allowed.

, check this out: https://forum.cloudberrylab.com/discussion/121/backup-for-mac-v2-4-0-17-release-notes#Item_1

We are releasing the new version in hours from now.

Hi.

The .Net warning is irrelevant to the issue in question and means no threat - apparently, the Framework version you use is newer than the one our software needs; but they are backward compatible so just ignore it.

For the main issue - please send diagnostic logs to our Support Team (from the Tools > Diagnostics menu). Thanks in advance!

https://drive.google.com/file/d/1oO5H3mo1HD9MM8whTrLxFctIJtkAKB9h/view?usp=sharing

It does exist for a long time now.
Terminal command to enable it: ./cbb option -set wa -http on
HTTP port 43210 by default, can be set.

An ok solution would be to mount an SMB share (aka usual network share) over VPN and use that.