You can restore files / folders from an image backup. https://www.msp360.com/resources/blog/how-to-recover-individual-files-from-image-based-backup/

That's not currently possible. Objects in the cloud generally cannot be moved as they are write-once. You would have to perform a cloud copy and a delete for the objects in the cloud that moved locally - which is not something we support.

Are you using the new backup format? The new backup format includes client-side deduplication which would prevent the need to send all the matching file data a second time.

This is what they just informed me:

The feature has been added and will be out with the the 3.2 release. The approximate ETA is mid-May, together with MBS WEB UI 4.8 release.

The active folder is probably the one that matches the current backup prefix in the product. If the incorrect backup prefix were initially used, then it stands to reason that all of the data was backed up to that prefix. If you then changed the prefix to the original name then it's likely the data was synchronized at that time and then updated accordingly. But if I were you I would reach out to the support team and see if they can assist.

Did you submit a Support Ticket and Logs with us? That's what I meant - not AWS. If you're using the Pro version I assume it's a paid version, and you should have some support.

We switched to using S3 Glacier last year (or 2019?) when it was released by Amazon. S3 Glacier leaves some metadata in S3 so inventories are automatically managed. It's possible that this is older data and the inventory is out of date. Regardless, support should be able to assist in the reason for the slow inventory completion on the AWS side.

I would reach out to support as they may need to examine the logs for more detail about what's going on on the AWS side. I assume this is Glacier and not S3 Glacier - as S3 Glacier vaults are automatically updated once a day by Amazon.

Either way, can you confirm your Explorer version?

Great. Thanks for the update!

I recommend you examine the backup history for that plan to see what file is causing the problem. It could be an EFS encrypted file or some other security issue causing the inability to back up that file. It may be something you can address without changing the service account.

You can run the service as an admin, but you may want to consider running it as a member of backup operators instead. https://www.msp360.com/resources/blog/support-for-backup-operators-api/

correct

because you want to keep 30 days, you would have to wait till the next full backup set is complete before you can delete the oldest set in order to retain the last 30 days worth of backup. You can't delete old incremental backups without deleting the phone and the phone would be the oldest backup within each set.

if you want old backups deleted then you need to set up the retention in the retention settings section of the backup wizard or in the management console. If you do as you suggest, and do a synthetic full every two weeks and want to keep 30 days of data, you'll end up keeping just about 6 weeks until the oldest back upset can be deleted, leaving you with 30 days.

Synthetic backups work exactly the same as regular full backups in the context of retention. Their advantage is that they are able to leverage all of the data that's already in the cloud in order to help create the next full backup, without having to send all the data to the cloud again. So they run much faster and require less data transmission to the cloud storage provider.

So schedule exactly as you mentioned: full backups every 30 days, incremental backups in-between, and keep the number of versions / duration that you need. Feel free to post more specifics about the actual settings you're using and I can help explain anything that is not clear.

you'll need to reach out to support for assistance. I just do not have the expertise to help you with an uninstall issue on Linux.

I think you posted about Oracle Cloud earlier. It's not really supported anymore. We have reported issues with some other S3 compatible clouds that kick back that error you're seeing but we don't have any resolution for it because we believe it's an incompatible S3 implementation by the cloud storage vendor. But if you want to open up a support case, that's what I recommend you do. So the team has the logs and can see what's going on. As far as getting help on the forum, I don't think I'm going to be able to provide any assistance for that error, since it's coming back from the cloud storage vendor. So you might want to reach out to Oracle and check their website to see if you can find any information on that error number and what might be triggering it.

You are not using Seeweb S3 Compatible storage, are you?

Where are you backing up to - cloud storage and vendor?

What version of the product are you using?

I do not believe the Export and Import do anything with cloud storage accounts. At least from what I see in the product - only local accounts are exported since they have no credentials. It's backup / restore plan focused. The prefix is not a part of the backup plan. It's a part of the storage account.

So, let me ask: Where are you backing up - storage type?

There's a backup storage option on the left in the Linux UI.

As far as uninstalling, many ways in Mint. Find the item in the start menu and right-click uninstall, use software manager, use the command line. Your backup plans will be preserved on uninstall, but if you are concerned, simply export them first.

Please provide details. What you are providing is completely insufficient for anyone to assist. What part of the backup process, what do you mean "it already deletes the credentials.." - what is "it"? Explain the issue in excruciating detail please.

Let's have you provide more detail first.