This is an interesting question indeed, officially it is not supported, but i think there is a chance for it to work properly. I will need some time to reproduce the scenario i have in mind. Will get back to you shortly when i have the results of my reproduce. Thank you.
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.
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
This is expected behavior. We do not check the targets for the files during backup as that would be an extremely expensive and time-consuming operation (especially when the data is in the cloud). Instead, we track files in a local database. However, you can force CloudBerry to synchronize the repository (via a consistency check) before a backup runs using the technique described in the blog post you referenced above (reposted here):
1. Navigate to the product configuration folder (e.g. C:\ProgramData\CloudBerryLab\CloudBerry Backup)
2. Find and open the .cbb file for the backup plan in question (there is a <name> tag in the .cbb where you can identify the plan)
3. Change the line <syncbeforerun>false</syncbeforerun> to <syncbeforerun>true</syncbeforerun>; save changes
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.
Blog post has been updated. For Windows, there is a newer method posted using the CLI and a Pre-Backup Action. For Linux and Mac, updated instructions are now in post.
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.
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##].