I am going to have to get clarification from the team on what is actually backed up for folders. I know you're using an image backup where that metadata exists, but I see the same restore behavior for file backups. I sent this over to the support and engineering teams for review and I'll reply here when I hear back - might not be until Tuesday because of the US holiday.

All I can think is maybe there's some file permission set on those files that do not allow the backup service account to see them at backup time. You can check your backup service account in the agent to see what you're using and make sure that it could see those files.https://help.msp360.com/cloudberry-backup/backup/about-backups/backup-service-account

Short of that, I think you're going to have to open a support case. You could also try creating a second backup job just for that single OST file as a test to see what happens.

I answered this question in the other post. Sometimes, hitting the remote machine is easier and may avoid other issues to expedite log creation and submission. But if it's too time-consuming for your setup, then you can try using the procedures I posted in the other thread about management console access to those settings.

You can do it from the management console:
* You can change the logging level from Remote Management - gear icon - Edit - Edit Options - Logging
* You can send logs from Remote Management - gear icon - Send Logs - select Backup

The password was likely a Master Password for access to the agent that you have defined for that customer.

Agent version?

If you had VSS selected, it would not matter if the OST were open. All I can guess is that you do not have that folder selected for the backup. Please verify the folder location from Outlook (right-click top-level folder, Data File Properties - Advanced) and verify that location is selected. If you have explicit file selections in that folder for backup, then you may have missed the OST file. Or, you may not have the folder selected at all.

If you're positive the whole folder is selected, then check other backup settings:
* Do not back up hidden and system files - if selected... files can be flagged as system or hidden and would not be backed up. You can check files from File Explorer by showing the Attributes column or running ATTRIB on the file from a command window.
* Do not back up locked files - should be unchecked
* Do not back files of these types (make sure if used that OST files are not entered) - best to use the Backup all files in selected folders

If that does not work, go to the History tab in the backup agent:
* Click the files toolbar button
* Select the plan in question from the drop-down list
* Select the Period in the toolbar
* Look for the OST file (you can try the Operation: Failed to start, but look at the full list sorted by file to see if the OST file is in there with some message)

Next, go to the Backup Storage tab and navigate to the storage in question and then to the OST folder. Make sure you do not see the OST file in backup storage.

Other questions: What is the storage target for these backups?

I do not why they are skipped. Possibly they are open in Outlook (is Outlook running?) and you have not selected the VSS option for the backup plan. If that's the case, the OST files will be skipped as they are open in Outlook. If you're not sure what has the OST file locked, then download Process Explorer from Microsoft and type in the OST file name in the search bar and you'll see who has the file open.

But...

There is usually no need to back up OST files. They are offline files and unless you've marked items as local only, they will only contain cached data from the server. If you lost an OST it would be recreated automatically. If you tried to copy an OST to another machine and set up a the Gmail connection, you'd likely get an error and need to recreate anyway.

PST files, on the other hand, should be backed up as they may contain information not available on the server. You can archive older items from the OST / Server to a local PST if you want.

Either way, if you want to back them up, you should be able to using the directions above.

There's an open requirement for that particular feature with S3 compatible storage. I added your request to the item, and have also noted your workaround. I'll report back here if the feature gets scheduled.

Still would contact Support, but Managed Backup Windows 7.6 is scheduled for next week.

Thanks for the update. If you have further questions, please let me know.

Jackie, This would be best directed to Support. I do know there are some items related to restore verification that are being addressed in agent version 7.6, which should be out soon. But Support can see if the issue you're running into is related. Please submit the logs to Support using the Tools - Diagnostic toolbar button on the agent in question. Thanks,

Just out of curiosity, what agent version are you using?

This sounds like a case for Support. They’re going to need to look at the logs, what agents are installed, and what encryption options were used, and if you rotated encryption keys. Please submit the logs from the agent using the Tool Diagnostic button.

I would try unplugging the keyboard and plugging back in when on the BMR screen. Also, try using a wired mouse if you have one (assuming you're not already using one). If all else fails, I can reach out to Support (or you can open a Support Case yourself).

No keyboard functions are working at all? Have you tried TAB and ENTER? Is this a wired keyboard?

With Image and VM backups, retention always applied to the backup set / generation. You mentioned you are performing Hyper-V backups. Those backups would consist of a Full and zero-to-many incremental backups. Together they are treated as a complete set since none of the backups can be removed without invalidating the set for further incremental use. This is no different between the legacy and new backup formats. Is it possible you were running daily full backups or were you running more than one backup a day?

Can elaborate on what you would like to see so I understand better. What would you like to happen after you run 7 days' of backups and then on the 8th day, a new full is executed?

The only way to ensure you always have 7 days' of backups for restore is to keep 7 days in storage at all times.

I look forward to your reply.

I don't think the new backup format works differently than the legacy format in that regard. If you perform weekly fulls, and you need to keep 1 week of backups, then you'll always end up with two weeks in storage before the first backup set can be removed. Then you'll have 1 week in storage, building up to two weeks again until the next purge. The only way to change that would be to run fulls more frequently (not the best option for many). Are you seeing something different than what I'm describing?

Also, please confirm your software version.

Unfortunately, what you're trying to do is unsupported. There's a feature request in the system, and I've added your comments and request. The feature has not been scheduled and at this time.

Let me send this over to the team for review.

Just to confirm: You have Signature 4 Selected when you registered the S3 Compatible storage account with Managed Backup? If so, Support is requesting you do the following as a test:

1. Download and Install CloudBerry Explorer: https://www.msp360.com/explorer.aspx
2. Add your S3 Compatible Account from File - Add New Account
3. Select Signature 4
4. Click the "Test Connection" button and send us a screenshot or text of the results of the test