if you check the option to always keep the latest version, then even if it's beyond the 30 days that version will be kept, so you'll always have one version to restore even on those files that have aged out. If you set your versions to 10 any versions older than the 30 days will be removed. Only versions within the 30 days will be kept. After the 11th version is created within those 30 days the oldest version is removed leaving you with 10 within those 30 days. I hope that helps.

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.

Can you post the error? I just tried changing a user password and then running the backup from the agent and it worked. I then closed the agent, changed the password again, and started the backup plan from the portal and it ran. Please reply with the exact error (post an image as well) as well as the exact steps you performed that you think triggered the issue.

Thanks.

That feature is in the product now. I don't recall exactly when it was added, but if you edit the master administrator account there is an option there to Force 2FA for all administrators.

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.

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

That message was changed from "Error" to "Information" in the 6.3.3 release. But I'm guessing from your post that even that change has not been enough to ward off questions from customers. Would you like to remove the message altogether?

Can you post (an edited) version of the email you are generating or send to me directly along with the template you are using (you should have my email address from previous email conversations).

Please see my reply in this post. https://forum.msp360.com/discussion/2365/job-still-running-but-success-in-the-result

The reason I was asking is this post is not in the managed backup section. It's in the standalone backup section which is why I needed to confirm. According to what I received from the team, this is a known issue because of a delay in processing by one of the server processes. However, it should right itself in a few hours. If you continue to see this status issue and lack of email notifications, please reply back here and I'll check back with the team.

I moved the post to the managed backup section.

Can everyone confirm they are using the stand-alone CloudBerry Backup product and not our Managed Backup solution?

Can you verify the version you are using, which backup storage you are using, the type of backup, and whether you are using the new backup format (released in 7.2) or the legacy backup format?

Two things you can try. First, try cloning the plan and then editing the cloned version of the plan.

Second: if that doesn't work then can you tell me if you are trying to edit a plan in a different edition of the software? Meaning, are you trying to edit a SQL Server plan on desktop edition or something similar? If not you'll need to submit a support case from the tools diagnostic toolbar option and reference case 00110489.

I have not seen that reported before, so I'm checking with support.

Thanks for your update Steve. Much appreciated.

What version of the software are you using?

Try uninstalling. Download the needed version from the management console. Install. And after installing, authenticate the User account from the management console. But if you get the same error, it sounds like the agent cannot see the service. You could try temporarily disabling the local firewall as a test.

It's available for stand-alone users in the 7.2 agent release. It's also available, by request, for Managed Backup users with Windows agent version 7.2+. Please contact Support to request the feature be enabled if you want to play with it from the agent-side. It's not yet configurable from the management console. We are planning to officially release mid-October. You can read more about the feature as implemented for stand-alone users here: https://help.msp360.com/cloudberry-backup/backup/about-backups/gfs/immutability

https://help.msp360.com/

The only way a second backup prefix would have been used is if somebody manually changed it on the Mac after the initial backups were performed. But you would see the backup prefix right on B2 in the bucket as I mentioned previously. If you're having trouble restoring, then I'd recommend you open a support case for fastest assistance. It's not easy to diagnose over the form what the actual issue might be. And if this is pressing that you get this restore completed, please open the support case as they can review the logs and see what's going on.

Support responded with the following ideas:

Based on some old cases where similar issues were reported, I would say that there is no specific solution for this issue and according to the info in old tickets, getting stuck on "Established, waiting for incoming data" happened from time to time in different systems and it was usually resolved by completing some common troubleshooting steps like rebooting the server or checking the Firewall or Antivirus settings and whitelisting the Remote Desktop tool.

It looks like something may be preventing the Remote Desktop tool from establishing a connection, so I would start with suggesting to make sure that RD is whitelisted on the machine he's trying to connect to.