It was. We are tracking the requirement and adding customer requests as they come in.

Are these File or Image backups? Are you looking to restore the operating system or just the needed files from those 3 original drives?

Assuming Image:
You can perform a file level restore of the main folders you need and specify the target folder as needed. You will probably get better performance if you use physical connections to the router on both ends (computer and NAS). Just make sure you're using the right cable (CAT 5e, 6, etc.) to avoid and unnecessary network speed issues.

You can also restore to a virtual hard disk and move the files as needed.

Assuming File Backups:
Nothing to really consider here. You select the target folder and files will be restored there.

No news yet. I’ve added your request in the system. I’ll speak with the team.

Thats version is old and long out of support. For a list of supported versions, please refer to this list: https://www.msp360.com/productlifecycle.aspx

But it sounds like the error is related to your credentials not being correct. Please check your Access and Secret keys in the AWS Management Console to ensure you are using the correct information.
https://aws.amazon.com/premiumsupport/knowledge-center/access-key-does-not-exist/

I am thinking what you are now saying is that Backblaze B2 S3 support is not available yet for Managed Backup customers.. and that is true. I am trying to get an ETA and will reply back as soon as I hear.

The Support team is waiting for the ticket. Please open as soon as possible so they can investigate. Thanks.

it's a known issue with 7.0. There is a work-around, but you'll lose history and you'll need to re-sync your data. Since it's in Glacier, if the backup is working, I'd recommend waiting for the 7.0.1 release which is planned to address the issue.

Feel free to ask questions about the calculator. I am no expert using it, and agree that it can be very confusing, or at least unclear about what number should be typed in where. But if you have questions feel free to ask them and I'll try to answer them here.

Reply clarified in next post

I am verifying, but I know it's supported in 6.x and everything I have for 7.0 says the new backup format also supports Synthetic Fulls for Image as well as File and Virtual. You would need to use the Backblaze S3 Compatible connector to see the Synthetic Full option.

That's correct. They passkey is needed to start the restore.

You cannot move files without first copying them to S3 for staging (by initiating a restore) or working with Amazon to have the files moved at their end (assuming they do that). And since Glacier is designed for archiving and not general access, you may find that an expensive proposition. The best (and likely least expensive) way to is to back up file again to S3 Glacier. You can leave the existing Glacier backups in place as long as needed. To avoid backing up old files which are already securely in Glacier, you can use one of the backup "Modified Date" or "Day" filters to ensure you are only backing up files that were changed more recently.

I would not do as you suggested in your post and use Explorer to copy the files. If you are not aware of Glacier restore costs, I would hit up the AWS Calculator and type in some numbers: https://calculator.aws/#/

As an example, you could find a charge of more than $150 to export 1 TB of data from Glacier to your local machine.

And you are positive you have the correct passkey used for encryption? If so, I will recommend you open a support case using the Tools | Diagnostic toolbar option - do this immediately after trying a restore. Please mention this post in the submission and also make sure to say that I instructed you to open a support case. I will reach out to support from my end.

Currently, the answer from support is that Glacier Direct is no longer supported, except in the case of an existing backup which can continue to be used in 7.0. However, editing of those legacy plans is not supported. I am still waiting to hear from the engineering team to see if this was planned and a necessary limitation or if there is some way to edit.

Our recommendation is to plan to move new S3 Glacier storage class. Here are differences: https://kb.msp360.com/cloud-vendors%2Famazon-aws%2Fs3-glacier-legacy-glacier-difference

Sorry for the delay. I am checking with the team on this issue now and will report back here once I hear from them. Thanks.

The feature is marked as "in-progress". No assigned release date yet, but I will add your comments to the open feature request.

Some terminology clarification: If you are using an image-based backup, then there are no file-level backups performed, as is. The entire image and subsequent incremental backups are encrypted as blocks of data. But you can restore files from image-based backups using the same encryption password used for the image backup.

Clarification questions:
1. Are you using the new backup file format? Or, is this a pre-7.0 image backup plan that you simply continued to use in the 7.0 version?
2. Did you initiate the restore from the Backup Storage tab and then right-clicking the image backup and selecting the "File Level Restore" option? If not, and you used a Restore Plan or browsed Backup Storage using Drive Letters instead of the "Image Based" folder, then you are trying to restore files that were backed up using a File-Backup Plan and would need to specify the encryption password for that plan - which may be different than your image backup plan.

Thanks. I'll wait for your response.

You can create a Lifecycle Policy that removes the incomplete multi-part uploads using this AWS guide as a reference: https://docs.aws.amazon.com/AmazonS3/latest/dev/mpuoverview.html#mpu-stop-incomplete-mpu-lifecycle-config

You can do this from the S3 Management Console in AWS, under the bucket in question, on the Management tab. And then under Lifecycle Rules. Check the "Delete expired delete markers or incomplete multipart uploads" option. Then check the "Delete incomplete multipart uploads" option and I would add a couple days to the entry to avoid accidentally deleting objects that are backing up.

I believe we attempt to remove these incomplete parts for you automatically. I will verify with the team, but it's possible that parts can remain if the backup terminates unexpectedly.

What you’re asking for (GFS Retention) is already well into development and the new backup format was only the first stage of new features. In the meantime, if you need the options for versioning, continue to use the older format. That format will be around for some time. When GFS retention is ready for release, you can move to the new format and you’ll get that fine level of daily, weekly, monthly, annual control you’re looking for. Thanks.

Are you saying you need to access files from other utilities without having to restore them first with CloudBerry Backup?

That's a Windows-only option. So back to my original question: What's your use case that the backup format is important?