Hello Gordon,

First of all, I can assure you that the Block-level works. Please check that you have enabled it on the first step of the Backup Wizard.

Secondly, yes. Backup works with block-levels to the local file system, whatever the destination file system is but the thing is that we don't work with their features (yet). So if you'd ask for whether we support BTRFS snapshotting - no, we do not. We simply upload the file, and in case of block-level, the changed part with it's map (cbbitmap).

So yes, the Backup would work, but we'd recommend to have a second copy in the cloud.

- James

Hi James

I did some further testing and documented my steps here:
Backup log with comments

Going from the bottom of the list up, first to last..

The first to the third backups worked as expected.

Then I enabled compression, which resulted in a complete full file backup. I can see how this may be the case because the compressed file "looks" completely different to the original 1st uncompressed backup.

A slight file change was made, and the next block level incremental worked OK at 112.06KB

The part that I don't fully understand is that the last two test backups were "Forced full backups", just to test what would happen.
Prior to this I've read somewhere about CBB's synthetic backups. But it looks like there is no synthetic full backup on Linux, it is indeed a full file backup with no links to previous unchanged files.

If my testing is working as you expect, then is there any way CBB can efficiently deal with one particular use case I have in mind. Being DATA of approx 6TB, backing up to 8TB USB drives.
In this scenario, only one full backup will fit on a disk, though many block level incrementals could be catered for. But at some point the disk will fill, and none of the old data would be purgeable due to blocklevel chaining.
Would this scenario be better served with compression=ON and blocklevel=OFF?

Regards
Gordon