My educated guess is that you are using Wasabi as your storage provider. In such case, please check out this article: https://help.mspbackups.com/billing-storage/storage-providers/wasabi/min-retention-policy

In a few words: this is indeed intended. Wasabi has early deletion fees that are by default 90 days. To avoid the extra costs there is an Intelligent Retention that postpones the deletion. With FFI it becomes a tad more complex, but still the right way to go to avoid the extra costs.

Also, after switching the minimal retention in both Wasabi and MBS (as per the above article) - there will be a "move over" period, as in: the 30 days work for new data only, data already on storage still has 90 days min. retention.

First of all, .list configuration files were never used for backup plans. So no point in looking for an older agent version.

If you have an exported configuration (a .cbbconfig file) - you should be able to import it in any latest version of the backup agent. If that fails - please create a case with our Support team via the Support portal: https://support.msp360.com/

That's great to hear. I guess it finished fine too :)

Try this:
1. Download Nartac IIS Crypto from:
https://www.nartac.com/Products/IISCrypto
2. Go to Cipher Suites and turn off these 2 cipher suites:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
the click Apply button as on the screenshot
3. Reboot the server for changes to take effect.

Cause:
1/256 connection attempts made with DHE_RSA the key length may differ, resulting in SSL error. It is possible that this occurs only on Win2008/2012 and is fixed for later Win.
I really like this article: https://jnbrex.wordpress.com/2016/09/08/microsoft-schannel-tls-bug/

I hope this helps!

Important, when disabling a cipher suite:
First - make sure that it doesn't affect anything in your environment!
Second - make sure you have cipher suites that will work with B2. To see what cipher suites B2 uses - check for example here: https://www.ssllabs.com/ssltest/analyze.html?d=api.backblazeb2.com&s=206.190.215.15&latest

I was going to get in to lengthy explanation about chain and dependency and etc, but you got there with the second glance at the screenshot :)
So yes, once ALL the increments in a chain fall under the retention settings only at that point we can remove them all. This is because without prior incremental parts the later parts are just bytes.

Also, I really like your schedule. So unless something on your end comes up - weekly fulls on Sundays is very good.

This looks like it needs a check with the Support Team. If you could please submit us a set of logs from either of the machines describing the situation. Or go ahead and create a case in our Support portal: https://support.msp360.com/, Support techs will advise you what data to collect.
We also need to know what version you were on previously, so please add that to the description.

I have checked and I can confirm that your domain got the maintenance notifications. I'll PM you the details.

Gents, the portal is up from the maintenance. Please check it!

My guess you are speaking about the MBS portal: https://mspbackups.com.
There is a planned maintenance ongoing, so should be back up shortly. It was announced as 2.00 AM - 6.00 AM PT and so far so good.

Another moment, can you please let me know if you did not receive the mails with announcement about this? Should be sent on Friday 23d and there was a reminder sent out yesterday (on 27th).

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.

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.

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

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?

While the suggestion is interesting there is one but: if someone knows the User password (and get his hands on the installer package) he can do stuff on a fresh installation of the backup client.
So the Master PW is bypassed anyway if the User creds are known.
Master password is to prevent unintended access if someone gets his hand on the machine, not on the creds.
So I don't quite understand what does it give you, having the "please contact provider"?

What RCS wrote is absolutely valid. Or, if we are speaking about Mac, here is a link: CloudBerry Backup for Mac download page.

And regarding not hearing back from us in the support ticket - I just found the ticket and it is replied. Can you please check your Spam folder to see if our reply wound up there?

Also, you can go and sign up on our current ticket system portal. That way you can see all the tickets you submitted in one place and interact with them.

Do you see the files there in Glacier outside of the backup client?
What happens if you try to delete a single file, not a whole folder?

Good to hear that you found a workaround for it! Just as a bit of insight - this situation you encountered, most probable it's caused by locale settings. We already plan to fix that in 6.1. Can also sometimes happen on configuration import.

In short: you can use the very same IBB in the very same blob you already have. Just doing item-level restore from IBB will work just fine if you need some folder or file.
For the longer and more detailed version I'd ask you to check this article and let me know if it helped:
https://www.msp360.com/resources/blog/how-to-recover-individual-files-from-image-based-backup/

I would ask you to please use the direct link in such case for now, while we are working further to improve our site.
The links are:
mspbackups.com for Service Provider Login
cloudberrycentral.com for Customer Login.

Sure thing, added!