I see Debian 10 isn't listed as a supported OS https://www.msp360.com/download/rn-standalone-for-macos-linux-3.0.pdf

Hi Arfa, How is it all going for you? Is your Centos setup now working flawlessly?

The SyncBeforeRun jobs going to an empty USB drive don't seem to be working right. The log tab shows zero files being copied for two consecutive days. I've raised a ticket [##150650##].

Linux testing: I swapped my USB drive and set the SyncBeforeRun value to true. The plan starts and displays "Repository sychronization!" on the screen, so it looks like it should be OK, but the previous sync over the weekend hung with a status of Running but there was no activity, and the disk space used was at 3.1T when I was expecting around 7T. I'll see how this one runs over night.

A full file backup is only a backup of the files that had new incremental versions created during the month. So if you have a Quickbooks file that gets modified and backed up incrementally 20 times in the month, the full backup will simply include the entire QB file again. We have over 1TB of data with over a million files and the monthly "full backup" is only about 50GB in size. That is because only a small percentage of the files on the server actually change during any given month. Files that don't change only get backed up once and never again. — Steve Putnam

Very well put Steve! It should be copied to the CBB docs! :-)
Are your observations relating to linux or windows backups?

Thanks for the tip David!
When I read the blog article I saw that it was for the Windows version of CBB so I didn't think it was applicable to linux. But after checking further I found that the .cbb plan files can be found here /opt/local/Online Backup/etc/plans and they have the <syncbeforerun> tags, so this is at least workable for us.

Not being able to backup to multiple USB drives, or more generically, empty backup storage targets (folders) is actually a show stopper for us, so I hope someone has some ideas before our trial runs out... :-D

I ran a simple test and it appears that the software doesn't support rotating drives at all at the moment.

For instance:
I successfully backed up just three files to a local folder "test bu storage folder".
Then I renamed the folder to "test bu storage folder-orig", and created a new empty folder ""test bu storage folder"
Re-ran the backup job and it backs up 0 files.

I was expecting the software to see that the backup destination folder was empty and so simply start copying all the files again, like an initial backup.

Has anyone managed to get this to work?

the 4th full backup will purge the oldest full + blocks. — Matt

In this example, would the purge occur before the 4th backup starts, or after it completes?

This could have a big bearing on local backup storage when dealing with multi TB data sets.

Hi Sergey

I did more searching on this and found this Windows based article.
https://www.msp360.com/resources/blog/how-to-use-rotating-drives-strategy/
Where it was answered in the comments section that support is coming for rotation drives on linux in a future version.

Is there any indication on when this may be?

--
Gordon

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