Is there a plan to allow Synthetic fulls for Local backup accounts?

Well, the short answer is, we don’t need the feature.
We run three backups of client data each night- local, Cloud 1, and Cloud 2.
They can all run at the same time, and sometimes do, but we typically spread the start times out.
Unless there is a specific dependency that file x has to be backed up prior to file y, I see no reason to bother with chained backups.
It maybe that I am missing something , so I am open to suggestions as to why I should be using it.

”I only want the second backup to run at the completion of the first backup and never independently on its own”
We too have separate backups/ retention periods for pst files, but do not use chained backups at all. The plans are scheduled to run at different times of the night, but even if they overlap with one another it does not cause any problems as they are backing up different files/folders.

An image backup will have to restart any uncompleted partitions from the beginning.

That works fine, thanks. Per my other post, we will not be reuploading 50TB of data just to get to the new format. We will use it for VHDx files and Images, where the synthetic full adds a lot of value and we only keep one version so switching formats is a no brainer.
But please impress upon upper management that you can never deprecate the legacy format, without negatively impacting all of your MBS customer.

Surprised that you would release an MBS version that does not allow editing of backup plans that are in the new format using the admin portal. We will not roll out the new format until we can manage the plans from the portal.

Thanks,
I participated in the beta and was given the indication that at some point, the only supported format would be the new one. That would be a problem. That being said, for image and HyperV/VMware backups, the new version is fantastic.
Concerned that the banner is telling me that All of my clients are running an unsupported version.

Does this require a re-upload of all data to conform to the new format? If that is the case, we will need to keep the old format indefinitily, as re-uploading everything is not viable.

For our clients in the Accounting/Tax fields we sell an "Extended Retention" option which keeps versions and deleted files in the backup location for 15 months (vs our standard of 90 days retention). We price this option under $10/month, but it has become very popular as it addresses the situation you described, and generates more revenue.

I apologize, I failed to specify the issue is with Backup History on the MSP portal, not the client console.

Individual endpoint. The search box does not appear to support wildcards, unless the "*" is not the right character for wildcard search :)

There are ways to do migrations of S3 backups to Wasabi or BackBlaze, but they are complicated and expensive. For a 3TB client, we took a USB Hard drive MSP360 backup of the client data and brought it to our location where we have 100mbps upstream bandwidth. We then uploaded the backup to BackBlaze (took 7 days), but we were able to keep running the S3 Backups until we were done with the upload. We then connected the client's server to the BackBlaze Bucket - did a repo sync (that took over a day itself) and ran the backups. Since we had 90 days of version retention in the Amazon Bucket, we did not delete the S3 bucket until 90 days after the cutover.
The extra cost was maintaining the two buckets for 3 monthgs plus the tech time to oversee the migration, but very low compared to a Snow/Fireball method.

I find that every install defaults to the Server version. I always go back and change it to the appropriate license as part of our installation process.

From the agent console storage tab, I select the “Capacity” view which sorts by folder size. Typically what chews up a lot of space are pst files, and if you keep a lot of fulls, the storage can get chewed up fast.

We don't disable the agent console on the client devices as there times that we need to utilize it.
Here is what we do:
1. Protect the agent/CLI with a password (as David suggested)
2. Disable the ability to delete backups from storage from the console (it is now disabled by default in the latest version). This necessitates using Cloudberry Explorer or the BackBlaze web portal to delete unwanted backups, but it is significantly better from a security standpoint.
3. Disable the ability to change backup/restore plans (which protects retention policies) using the console. There are rare times when we need to edit plans on the device console itself, so we change the company agent settings to allow it and push/install an updated agent on the machine. 99% of the time we edit the plans from the web portal.
Prior to these features being implemented in MSP360, we had that worst case actually happen. What saved us is they forgot to delete one of our three backups.

Thanks David. We did a test of Option #4 and it worked great.

This has been happening to us, particularly for SQL Backup Plans, for over a year.
If I open the plan and save it, the overdue goes away.

Thanks for the update. We don't have a lot of Image Backups as we have moved to Hyper-V virtuals for the bulk of our clients. But I just moved all of the Image/VHDx backups from Standard Backblaze to BB S3 so that I can use Cloudberry Explorer to manage it (vs the awful Backblaze Web Portal that takes several minutes to load the list of files).
On an semi-related note, how is the new Backup format going in the Standalone product?

Another option is to utilize Backblaze S3 Compatible storage. Cost is $.005 per GB per month and there is no minimum retention period. Since we only keep one monthly version of images/HyperV Vhdx files in the Cloud (vs. 90 days for files), Backblaze is ideal. We keep local Daily image/VHDx copies, and consider the monthly VHDx/Image to be a Disaster recovery solution.