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.

If you want to use the new backup format, you'll need to reupload. Consider using it for new customers / endpoints once you play with it a little and get a feel for the new features.

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.

What version is that?

6.4.0.35

Do you know if the Management Console will in the future be able to create or edit the new backup format?

Do you know if Remote Deploy will in the future support the new backup format?

Just to corroborate, we're also seeing in the warning banner in our MSPBackups portal that all 75 of our clients are out of date as of today--as opposed to 3 or 4 clients last week.

I assumed it was accurate in our case, since we're still mostly on 6.3.5.29, but did think it was kind of strange since apparently 6.4 has been out since August 18. Maybe it only counts agents that are out of date by at least a major version?

Edit - @Steve Putnam - Just noticed that if you hover over the little "information" icon in the middle of the warning banner, it says "Only 3 latest versions are supported."

I think you're fine. I think 6.4 was the last version before 7.2, so 6.3 should be fine. I'll check with the team to see why you're getting that message.

Much appreciated, thanks for looking into it. I was thinking the banner could still be correct because 6.3.6, 6.3.7, and 6.3.9 were also released since our last update, but that wouldn't explain why our agents on 6.3.5.29 would only have become "unsupported" as of 7.2.

I’ve confirm with the team that this is in fact a bug and it has already been reported and is being worked on to be fixed in an upcoming release. You can ignore the message for now.

That's all well and good for new clients, but we have nearly 800 backup plans at this point in time running on the "legacy" backup format. I agree with Steve Putnam in re-uploading hundreds of clients data is hardly a viable option. When is this supposed to be enforced? This is something that would take us an unbelievable amount of man hours to complete as the change would need to be individually handled on each machine which is just crazy to even think of.

Also, in the new backup format, there's no option to run full only backups? you have to first enable incremental backups to allow for full image backups, but then have no option for exclusively running a full image backup.

To start using the new format you have to start with a full backup. I am going to create a new job to use the new format just before a full backup is scheduled to run.

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.

October 5th is the 5.2 management console release date with support for the new backup format.

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.

Couldn't agree more. We have no problem setting up new client's on the updated backup format going forward, but forcing widescale retroactive adoption and placing the burden onto your customers seems to be strongarm tactic that doesn't sit well with us. You guys are selling almost exclusively to MSP's now, not individual businesses. You must understand that a complete systematic change like these has huge impact on us. We have hundreds of terabytes of data that would need to be reuploaded to cloud storage to accommodate the new format. Also, we'll be the ones to incur the additional cloud storage costs if switching to the new format since it would be a different backup plan, and therefore separate storage. We've been with you guys for a few years now, and there really seems to be a disconnect between the company and your clientele. From our perspective, there's a high level of focus placed on "what's the next new feature" vs. making your existing software bulletproof and gradually improving it over time.

Unrelated, but having a "current bugs" or "known issues" tab in the management console would be immensely helpful. I also saw the "backup client's out of date" bug this morning, and end up having to drill down into the forums to find information regarding this, or I have to call your support just for them to tell me it's a known issue, it's just doesn't seem very efficient for you or us.

Started a new Image Based Full backup using the new backup format. This full backup will take many days to complete. Does anyone know if the backup were to get interrupted, will the backup pick-up from where it left off or will it need to run again from the beginning when it restarts?

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

Thanks Steve.

Just wanted to confirm that the banner about unsupported clients is gone. Thanks again!

Did console release get pushed back? Cannot edit new format backup plans today and your post indicated Oct 5 should have been a new web console release.

Yes. It's now scheduled for Oct 19th.

The dreaded "two weeks" software eta.

Thanks for the update.

Yep. It's a bit of a moving target unfortunately. I would have preferred we release everything at the same time. I know many customers are eager to try out the new backup format, but do understand that without management console support, testing is more difficult.

Hi,

For what reason did you remove the advanced schedule options, in the new backup format. If I want to make a image backup, I can choose for daily backup off course, and only "execute full backup" monthly, weekly or daily.

A synthetic full backup, is a full backup, that is re-using the storage that's already in the cloud. It's saving upload time, but in the cloud himself they put all blocks together as a new full backup. So 10 GB backup, next month again 20 GB, and next month same story 30GB.

Wasabi is having a minimum of 90 days storage, I had it set to a full backup every 45 day's and keep 45 days. So the storage needed to be 2 full, and all diffs. But I maybe wrong, now there one more full backup space needed in for 3th month, because you decided that we can't set other option then daily, weekly or monthly.

I guess I am not exactly clear on what you are asking - maybe the question relates to some missing options in scheduling when compared to the old format like # of days between full backups. The new backup format allows you to schedule the Incremental backups and then optionally set the Full backup schedule - which is synthetic, if supported. Yes, it's true that Full scheduling options are currently limited to specific days of the week or a specific day of the month (e.g. Second Tuesday of every Month). There is already a request to have this part enhanced to allow you to put in a number of weeks or a number of days between full backups to make it more like the legacy backup format option.

The new backup format uses deduplication to make backups run more quickly. Synthetic fulls also run substantially faster than traditional full backups. But your assessment about full backup storage is correct. After the synthetic full is complete, you have the equivalent of a full backup in storage. It just took a lot less time to create than the previous format.

Is there any plans on improving the web management and making it faster? Very slow at times. Where are consistency checks in remote deploy? Is there anyway you could make remote deploying local backups better? Maybe like a GUI to select the drive? Having to go off drive letter kinda stinks and it's just very clunky to manage through Remote Deploy. Probably poorly explained but I'm sure people who have used remote deploy know what I'm talking about.

Slowness should not happen, except on rare occasions. If you're seeing this frequently, then I'd recommend reaching out to support or posting here on which screens this is happening. Although we cannot diagnose management console issues on the forum, I can always reach out to the team to see if the servers are running normally.

Remote Deploy is about multi-device deployment. We cannot show a device-driven UI of drives because what device would we show when the deployment is happening across one or more companies. Sure we could just pick one, but I fear that would / might add to the confusion. We do have a paste from clipboard option, so if you're using similar folder lists across multiple deployments, you could save the folders / files in a text file and use it to be pasted into a new deployment. Am I understanding your concern here? If not, please clarify.

It's a tad slow, like not instantaneous, but its usable at times. Too impatient haha.

I definitely wrote the part about local drives wrong. I was thinking of a GUI of system drives at the Where to Backup screen when creating a new plan for a computer and not relayed to Remote Deploy. I'm not really a fan of making a storage account, then going to users, adding a backup destination, etc, etc, seems like a very long and arduous task but I understand if its left as is.

While were on the topic of Remote Deploy, there is a bug on the Web UI with partition selection. As someone in the support ticket I made said about a month or two ago, to keep it short, the settings are applied correctly in the app, but are not shown properly in the MBS wizard via remote deploy. Hope you guys can fix that up with the new cloning format.