Any specific screens you're having trouble with?

Yes, you can restore as an Azure Disk. However this option is only available when restoring via the agent (it is not available as an option in the management console).

I've used https://www.axialis.com/iconworkshop/ in the past with great success. But there are certainly less expensive options and likely free options available.

in addition to what Steve asked, there should be no reason I can think of to back up an OST file as they are just synchronized from the server data. So if you just recreate a new file it'll all sync from the server. Only PST files really need to be backed up since they are considered local archives.

Maybe you meant to type PST like you did in the title. Can you answer Steve's question please.

So you explicitly selected that folder for backup? Can you check under that folder in the backup plan to make sure you didn't accidentally select a file in that folder. Trying to confirm that folder was backed up.

Are you restoring from the same PC?
Do you see that folder in the Storage tab? If so, any files backed up from that folder?
What are your retention setting in the backup plan?

if you change the backup prefix, then all backups will start fresh under that new prefix. Old backups will remain in the old prefix folder name until you manually remove them as they will not be removed through normal retention because of the prefix change. If you rename the prefix folder on the cloud side then you can resynchronize the repository on our side afterwards to sync up the data to continue backups. That assumes you're able to do that on the cloud in question. I don't have any information about how that could be done but you could look to the vendors tools or knowledge base for guidance. But if you've already started backups under the new prefix then I think you're stuck using it and you should just remove the old backups manually when they're no longer needed.

I do not think you can rename a bucket. Buckets are not folders. Just like folders on a local disk are not really folders in the cloud. Everything in the cloud is an object. Changing a bucket name would require (and probably why it's not supported) changing every object name that sits within that bucket.

Why do you need to rename a bucket? Do you just hate the name? You should create a new bucket and assign. But backups will start fresh. While you could seed the buckets by copying data from the old to the new and then synchronizing the repository, you may find that process is slower and more complicated than simply starting backups fresh. You can remove the old bucket when you're certain you no longer need the data contained within.

No. Please do not do that. Unnecessary. And could be a lot of management especially with large customers.

Think of User Accounts as Customer Service Accounts. I've seen multiple User accounts used, but usually only to better organize Desktops versus Servers or for different locations for the same company.

But let's hear from customers on this one.

Do not change the cloud storage until we understand better what you're seeing. Please answer my first question:

When you change the backup prefix, all subsequent backups should be using that new prefix. Are you seeing both backup prefixes in storage?

If you're backing up multiple computers and using remote deploy, then set up a system required partitions in the deployment and then create a separate image plan for the volume specific for that computer by editing plans for that endpoint.

But will ask about the External Hard Drive issue with the team.

Most customers I speak with use common buckets. Data is separated by the company user account, so customer A cannot see customer B backup data. But if you have a need, you can certainly use different buckets, but I'd encourage against it unless it's a one-off customer use-case. Remember that many cloud services have limits on the number of buckets. Some as low as 100 - which may not scale for you - so check with your vendor.

I think with GFS, you can just keep monthly backups for 1 month if you want. Or keep weekly backups for 4 weeks - although there will be more data stored in this case.

You can delete versions older than 1 month if you want, as that will mostly have the same end result. But you do not need to specify both options if you do not want. It all depends on your full and incremental backup schedules.. If you run the full monthly and run incremental backups 5 times a day, you'll end up with 150 incremental backups over the course of a month. That's more than 30 versions. If you ran a full once a month and incremental backups once a week, you'd end up with 4 incremental backups per month and if you used 30 versions in retention, then you'd be keeping a minimum of 8 months of backups.

I was thinking of a GUI of system drives at the Where to Backup screen

Where are we in the app? In the backup wizard? I need some clarification here.

...making a storage account, then going to users...

If you're talking about onboarding a new customer, the easiest way to do that is:
1 - Create the customer (from the Companies screen) and assign the storage account here
2 - Create the customer's service account (from Users screen) - this can simply be a username / password and assign to customer (no need to assign storage here)
3- Your customer is ready for agents to be installed and assigned using that User account

When you change the backup prefix, all subsequent backups should be using that new prefix. Are you seeing both backup prefixes in storage?

You can rename a prefix from a product like our CloudBerry Explorer, but then you'll need to synchronize the repository so the product is now in sync with cloud storage.

Slowness should not happen, except on rare occasions. If you're seeing this frequently, then I'd recommend reaching out to support or posting here on which screens this is happening. Although we cannot diagnose management console issues on the forum, I can always reach out to the team to see if the servers are running normally.

Remote Deploy is about multi-device deployment. We cannot show a device-driven UI of drives because what device would we show when the deployment is happening across one or more companies. Sure we could just pick one, but I fear that would / might add to the confusion. We do have a paste from clipboard option, so if you're using similar folder lists across multiple deployments, you could save the folders / files in a text file and use it to be pasted into a new deployment. Am I understanding your concern here? If not, please clarify.

Version for images are restore points. Keeping 2 versions when you are running a full every 30 days may not do what you want. You would run:
1 - full
2 - incremental - now you have 2 versions
3 - incremental - need to keep it because you only want two and those two are this one and the previous incremental since incremental backups are chained - but the full is needed for those restores so it needs to stay too
4...29 - same thing

the next set runs and
1- full - now this full and the previous incremental are your 2 versions, but since that previous incremental needs all the backups in that set, everything stays
2 - incremental - now you have 2 versions - this incremental and the full before it and now the previous backup set (full + 29 incremental backups can be removed)
3 - same as previous backup set example

To do what you want, keep 30 versions. You'll end up with 60 backups before the first 30 can be removed and that cycle will repeat.

When you say renamed, do you mean the backup prefix in the Storage Account setting? That's the setting that drives the root backup folder name.

That agent version was just released. Were you using an agent version prior to this or are these fresh installs? If you used a prior agent, then did you have the same problem or did the issue start to occur when you moved to 7.2.1.49?

And please see the other questions in my previous post.

Also, that error may be related to the local repository database we manage. It's not clear the actual source, and the logs would probably point us in the right direction. Are you saying you submitted logs to Support? If so, are you working the case with them or has it been closed?

You can check Options - Repository and make sure the drive where the repository is located is not out of space (or low on space).

Have you made any security changes recently? Does the backup service account have access to the Repository location on those computers with the issue?

What type of backup are you running? And version of the software?