If there is still a client with the described setup with chained backup or if you can set it up on any machine, please try this:
Please open the backup client, expand the backup plan (here we are interested in the plan that kicks off first) on the Backup Plans tab and Ctrl+Alt+left click on "View History". That'll open the configuration file for that backup plan.

In the opened config please search for such string:
<ForceFullNextPlan>true</ForceFullNextPlan>
or
<ForceFullNextPlan>false</ForceFullNextPlan>

Which is it for you? If it's true - please manually edit it to false and save the configuration file.
And lets see if this will do any good in your case.

Also, this is for sure a situation to have a case opened with us in Support, do you maybe have a ticket number or you went only for the Forum?

Hi Sergey, I will take look at that this morning. Also, I didn't create a ticket, but I called into phone support last night, spoke with a tech and got him remotely connected to one of the machines. I provided him with an email address and my information, but am not sure if a ticket was created. I didn't receive an email notification indicating that a ticket was created. Thanks.

I asked the team, please check if #259000 is your case :)
And do let me know, here or in the case, how it goes!

Sergey, Thanks for that. I've just checked one of the machines with this issue and can confirm that <ForceFullNextPlan> is already set to false.

In such case - I need you in the ticket system with the logs to have a look at this in more detail =) Please get us a set of logs from this machine.
Please go to Tools > Diagnostics in the backup client. In the opened window please paste a link to this forum thread into the Description and hit the Send button. That'll be enough for us to get this going further.

Logs sent.

Just wanted to update. I was assisted by support who was able to provide a workaround for the issue. The fix requires manually modifying the backup configuration file from the backup agent on the server, and changing values for 3 different lines of code.

While I truly appreciate the help and temporary workaround, I'd just like to reiterate the importance of a timely fix for this. Having to login to each server and manually update a .txt configuration file for each client's backup plan is very tedious, and a time waste for our limited resources.

Since the tech was able to fix it, I'm assuming you're aware of the specifics and where the problem is occurring? If not, I'd be happy to show you exactly where the issue is happening.

Thanks.

The tech updated me with the details and we have already passed this to R&D for further investigation. We'll keep you and everyone on the forum up to date and will get back once we have anything from R&D.

Just an update to anyone who might encounter the same issue with chained plans,
here's a list of things you'll need to do as a temporary workaround for this:

1)First of all, for your plan that is supposed to run first and start a backup plan chain please make sure no ForceFullNextPlan will be enabled in that plan's config:
Hover your mouse over 'View History' button, then press Ctrl+Alt+Left Click:




-That should open a configuration file for that plan (you can open that with any text editor):



-Find the following string <ForceFullNextPlan>true</ForceFullNextPlan> and change that to <ForceFullNextPlan>false</ForceFullNextPlan> , then save that file.


2)For the second plan(the one which is supposed to run after your initial plan) you'll need to open that plan's config using the instructions above and find a following string <UseDifferentialUpload>false</UseDifferentialUpload> and change that to <UseDifferentialUpload>true</UseDifferentialUpload> :




Also for that second plan config we'll need to disable Block-level schedule(it may be disabled by default but you'll need to double-check that), you'll need to make sure that Schedule > Enabled is set to false:




Then please save that file as well.

Please keep in mind that you need to look for <Schedule> part, not for the<ForceFullSchedule> one.

3) Also please pay attention if you'll edit those plans manuallywith master password enabled,plan runs will fail with 'Plan signature is not valid'.
You'll need to close your backup console, re-launch it again, enter the correct master password and click Accept in the next window for backup software to actually accept those plans as legitimate ones.

Hi, !
Here's another way for you to achieve the same result with no hassle.
1. Install Powershell module according to the steps described here:
https://kb.cloudberrylab.com/managed-backup-service/powershell-module/get-started

2. Adjust the script:
Change Friday to any other day of the week.
Change Backup plan Name "123test" (it should match what you actually have)
From here: https://kb.cloudberrylab.com/managed-backup-service/powershell-module/sample-scripts/Force-Full-day-of-week

3. Paste the script to Post action on the Pre/Post Actions step.
4. Check it out and let us know if it worked.

Thanks

Hi Anton,

Very cool to see Powershell module. However, I'm not sure what you've referenced is what I'm trying to accomplish. Our problem is chained backups running full backups daily instead of block level backups daily.

We run as follows. NAS backup full daily, then chained cloud backup block level daily. Then the cloud backup needs to run a synthetic full once a month.

The method you've described here is just to force a chained backup to run as full correct?

Thanks,

Guys,

Hoping for an update on this as it's been well over a month. We've been taking on and converting a lot of client's lately to this setup with Cloudberry, and I'm growing tired of the manual workaround that I'm having to use each time. Also while it does work, I've noticed that when using the manual workaround correction you have to modify the file twice to get the changes to actually stick.

thanks,

Sorry, no updates on that so far.

Guys, Still waiting for an update on this. We're busier than ever and this is adding additional time and frustration to each new setup we're deploying. Please address this.

Right now I have only target release version, which is 6.3, no date yet.

Last reply almost a month ago, still no fix. We have several techs installing this software for our customers and so of course we created an SOP for how we manipulate this software to do what should be rather easy. Now I need to update the SOP to include editing config files by hand because the settings we need are no longer able to be configured in the web interface.
We setup 3 new customers and instead of doing incremental dailies the chained cloud backup did full backups daily which set off a flag on AWS almost immediately we were way over budget. Why the hell isn't this fixed yet?

On top of that if we need to tweak old plans the "<Schedule><Enabled>true" comes back but I'm not sure what that actually impacts, the gui remains the same if that's false or true.

Is there some published document regarding the xml entries that we can at least consult?
Massive thanks to JamesZ for taking the time to document a work around, you saved a customer for cloudberry because right now Veeam is looking real good if it wasn't for the massive hassle of changing everything.

Luckily already configured clients don't break as long as we don't touch the plan configs. But onboarding new setups is becoming more complex and wasting more of our time, Just unbreak whatever you broke it was working fine not too many versions back.

Not sure if this has been sufficiently addressed since the new scheduling options were implemented but what I found works using a similar Local to Cloud image chain sequence setup was this.

Create normal local image based backup plan with incremental and full options scheduled. Do not enable chain sequence.

Create cloud image backup plan with incremental and full option scheduled explicitly.

Let the backups complete the first full cloud image backup automatically. Once the first cloud image is complete, remove the daily occurrence for the cloud plan, then setup your chain sequence from local to cloud.

This has worked reliably for me for new configurations, editing the config file seems hit or miss, especially since the changes need to be approved next time GUI is opened after a config file is edited.

Hi Matt,
It's been quite some time, hope all is well. I just noticed this morning that version 6.3 has been released. I checked the release notes, but did not see this mentioned. Can you please confirm if this has been resolved in the lastest version?

This issue remains unresolved. If a backup plan is initiated via chain sequence, it's forced to be a full backup by default rather than block level.

Funny enough, the software developers have completely misinterpreted the issue such that they've also included a "Force Full Backup" option during the chain sequencing section of the plan configuration. The fact that it runs full backups every chain sequence is already the behavior and is the problem!

Yeah, I've given up on this issue being fixed at this point. It's been over a year and to this day, I'm still manually modifying text documents on every new setup we do.

I just wanted to chime in... we have a very similar config to the OP that we use for our clients and have been plagued by this.

In our case we use Hybrid (local drive + NAS), with the a Cloud/Online incremental block backup job chained to follow.

An easy workaround that has been 100% successful is to schedule the chained incremental block backup job for some date way in the future. We use Jan 1st 2025. Once we add a schedule to the incremental block backup job it chains correctly and runs incremental instead of a full backup.

I think that we are being impacted by this issue too. All backups appear to back up much too much data and thereby take too much time and consume too much bandwidth. They don't appear to be running as block-level backups, as they are scheduled to run. Is there an update concerning a fix for this issue that does not involve the amount of time that the work-arounds appear to take? We have a fair number of computers being backed up. Most utilize local backups followed by chained local and off-site backups. Not running as block-level causes quite a few issues. Thanks.

Please leverage our Support team for guidance. You can quickly open a support ticket from the Tools - Diagnostic toolbar option on one of the computers experiencing the issue, and they will be happy to review your settings and logs to see if anything is amiss and how you can achieve what you need.