The backup prefix must match exactly. The B2 storage folder in the bucket in question will have the prefix name if you want to check that way.

Are you using the same backup prefix as the original computer? If not you'll need to change it. Check Advanced Settings for the storage account in question.

The suspect some of the difficulty with implementing that feature is that the API for network shares to manipulate the data is not ideal compared to cloud APIs. But I have asked the team for their thoughts - the request is already in the system. I'll report back when I know more.

If you want to continue using the legacy backup format, you can. We have only added the new backup format - we have not replaced the old one. Just use the drop-down on the File / Image-Based Backup toolbar options and select the style you prefer.

If you want to take advantage of the new features, including client-side deduplication, faster performance, synthetic full backups, integrated consistency checks, and GFS style retention, then you need to start using the new format.

All file backups are incremental once the initial full is completed. GFS retention is about how much granularity in restores you need over time. Generally, you need less granular restores as data get older. So, you may want Weekly backups saved for 8 weeks to provide more options for file versions that may need to be restored, but you only need Monthly backups kept for 6 months, and then annual backups kept for 3 years. That allows the product to delete backup data that is not needed to meet those requirements - as compared to the legacy backup format that was version-based. Version-based retention makes it difficult or impossible to keep old versions without the risk of increased storage of needing to keep all versions. More about our GFS implementation is available in Help:
https://help.msp360.com/cloudberry-backup/backup/about-backups/gfs/gfs
https://help.msp360.com/cloudberry-backup/backup/about-backups/gfs/gfs-assignment-examples

What is the exact version of Windows Server Essentials you are using? What version of remote desktop is installed on that server and your main computer?

Can you let me know which license you own of CloudBerry Backup and where you are sending your backups (the cloud vendor and / or local)?

this is hard to diagnose without any relevant log information. Since you're using managed backup, I recommend you open up a support case and send the logs from that machine so they can review what's going on.

I recommend, if you have not already done so, that you open a support case on this issue. I have seen a few customers report similar issues and the Support team is tracking and can work with you on quick resolution. Thanks.

If you set the retention to 7 days, then the first backup set will delete at the end of the second set / week, leaving you with 7 days. There is no way thought to keep the first full as that would be a week earlier and be missing the 6 incremental backups that followed it.

In this scenario with 7 day retention:
Day 1: Full
Day 2 - 7: Incremental
Day 8: Full
Day 9-14: Incremental
Day 1 - 7: Deleted after Day 14 backup

Then the process repeats. On the next day a new Full will run, followed by 6 incrementals. In this case, you would only have 1 day where you only have a single full as a second one will be created on the next chain.

Can you go into a little more detail about your use case so I understand it better?

Thanks.

You need to use Advanced Mode. What backup mode are you using?

enabling that option doesn't send any emails. It just makes available the options to do things like report to the Windows event log.

The option is current there in the agent for both the legacy and new backup formats. To enable this option in the agent, you need to make sure the management console - Settings - Notifications - "Allow users to receive backup and restore notification emails" option is checked. Once that is done, the event log option will show up in the agent when editing the backup plan. It should also be available from the management console for the new backup format when that release is available in October.

I recommend you open a Support case for instructions on how you may be able to address that issue. The Support team would need to review the logs and version of the software.

The Oct 5th release will add support for the new backup format to the management console. We released the completed agent a little early for those customers who were planning to test via the agent itself. I understand your concern about trying to sync the agent -management console releases, but sometimes we release the agent a little early. We'll try to do a better job next time communicating this to customers to avoid any confusion in the future. Regarding your question on Windows Event Log notifications, I am checking with the team, but expect that feature to be available when released. I will report back once I have confirmation.

You cannot do what you're proposing exactly as you want it - but you can get very close. If you run full backups once a week and block-level incremental backups on other days of the week, then you have a 7 day schedule (1 Full + 6 Incremental backups). You can keep backups as you want for 14 days, but you cannot delete that first 7 days until the 21 day mark when the next backup set is complete. That's because you want 14 days of backups and we cannot delete the first backup set and leave 14 days on disk for restores until the next backup set is complete. If you only want to keep 8 days of backups, then once the full in the 3rd backup set completes, we can remove the entire first set. But at that point, unless the system is very active and the block-level incremental backups are very large, you might as well keep them using a 14 day retention.

I think it would be best to open a support case so the team can help you address this issue.

Also have a look at this knowledge base article. https://kb.msp360.com/standalone-backup/esxi-&-hyper-v/avhdx-files-not-merged-after-created-checkpoint

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

That feature is there, sans enforcement. Go to Administrators logged in with the account you want to change, click on the sub-admin account and enable 2FA. My guess is the confusion happened because you can’t change a different account other than the one you’re logged in as. That’s because the 2FA requires access to a mobile device, so we leave it to the sub admin to enable 2FA on their account. On the other hand, if you were already aware of that and you’re just asking about the ability for the master account to enforce 2FA on sub-admin accounts, then I’ll have to check with the team to see if that’s on the roadmap.

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.

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.