and this is using the stand-alone CloudBerry product and not Managed Backup, correct?

Are you running image backups? If so, I'm not certain we ever supported searching with that backup type. I'd have to check but image backups do not back up files and because of that there is no real time inventory. But I've been wrong before...

It seems to be working for me. I don't know what the difference is, but I can search and use wildcards. This post was for stand-alone. Possibly there are some issues with Managed. Maybe the OP posted in the wrong section.

I m not having trouble searching on that version. Can you elaborate on the type of backups you are running? I know there was an issue searching with early 7.0 releases, but this was addressed and I can search for exact file names or use wildcards.

I know the requirement is in the system, but no date yet. Someone will report back when it's scheduled for release.

See if anything in this post helps. If not, you may need to open a support case. Hard to diagnose VSS issues on the forum. https://www.msp360.com/resources/blog/troubleshooting-vss-volume-shadow-copy-issues/amp/

Which backup format are you using? Legacy or the new backup format? And this is a File based backup, correct?

any updates on your testing?

Yes, you got it. Just remove the storage account.

If you're only using file recovery, then I would recommend you use file / folder backups and not image backup. Especially with the new backup format which is much more efficient than the legacy format for file / folder. It has synthetic full support for most cloud storage options, client-side deduplication, automatic consistency checking, and synthetic full backups. If you're happy with the performance of legacy file / folder backups and prefer the version-based retention in that format, as opposed to the new GFS style, then you can stick with that format as well. I know some customers use image backups even when all they need is file restores, but my recommendation is to use the appropriate format based on backup and restore need, unless your file-level restore needs are infrequent. Or use a combination of file and image as I do. If you do want to use image, then I recommend using the new backup format for best performance.

To answer your question, a FLR from an image backup will create the target folder if it's not already created.

Just so you know - file-level restore is done a little differently with the new backup format. You drill into the disk from Backup Storage and find the files / folders to restore - as opposed to doing that from the restore wizard.

did you test your speed to Virginia from your current location? Make the other changes as well with the log file and consider using the new backup format and maybe you can avoid the additional S3 transfer acceleration charges from AWS altogether

A few things to consider:
1. Just because you have a 2 Gbit upstream connection, does not mean you are going to get close to that speed when backing up. You can use this Amazon test page to see what your performance is with and without transfer acceleration: https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html
2. You are backing up to a region far from the source data which introduces additional latencyand reduces performance. if you can, I'd recommend you consider using either a local region or use S3 Transfer Acceleration if all other recommendations below do not result in the desired performance
2. I see you have Logging set to High, which is not recommended unless you are instructed to do so by Support for logging purposes. It will generate a lot of local IO as it writes out detailed log information. Please return to the normal level
3. You are backing up a network share, which introduces additional overhead when compared to backing up locally attached storage.
4. You did not mention how many files are being backed up and their average size, but you will find performance to be much better when backing up many files if you use the new backup format as opposed to the legacy format. The legacy format backs up each file as single cloud objects. The new backup format combines files into larger archives which reduces IO considerably

supports recommending you upgrade to the latest version of the product, as that version has resolved similar issues with other customers.

Let me check with Support.

check this post to see if the solution helps. https://forum.msp360.com/discussion/2386/page/p1

Thanks for all the updates Steve.

Yes. Unfortunately, that's the case. A new full backup would currently need to back up the entire set again since synthetics are not available for Google Nearline. I could make the case that staying with the legacy backup format with Google Nearline might be a better option, for now, depending on data size and bandwidth.

according to the latest tests by support even if you show the password, and then save the plan the password doesn't change on the plan itself. They were unable to duplicate the scenario you're running into where it actually changes. Are you sure you didn't modify the password in any way even if it was retyping the one that it was showing incorrectly? I think they want to see the logs for that particular plan execution where it backed up everything again, so I would send those along on the open support case.

I'm currently speaking to support about this, but I think the solution is not to show the password until the fix is in place.

Sounds like a minio configuration issue. I see you're not using HTTPS, which would normally be recommended for encryption, but I doubt that is the reason. Have a look at this post as someone else trying to use minio had reported this issue. https://stackoverflow.com/questions/68678953/error-when-configuring-minio-in-c-sharp-the-authorization-header-is-malformed

But I think since you're using managed backup, the best course would be to open up a support case as I'm not able to provide comprehensive minio support on the forums.