With those settings, you'll eventually have 60 days' of backup in storage (2 sets of 30 days each) and then the oldest backup set of 30 days can be removed, leaving you with 30 days. And the process starts again. There will be some early delete fees for the oldest set when removed since it's under the 90 days' of retention. But since the old full backup is likely the largest file and is also the oldest, there's only about 30 days left in retention. If you only need 30 days saved, then I would not worry about the early delete fee. But if you want more backups saved, you can keep 60 days instead of 30 days (use same 30 versions though) without any major impact in storage fees.

Yes, we see that as a delete of the original files in C:\Data and new files created in C:\Data\A - so the data will be re-uploaded to the cloud. You can copy files within AWS from bucket to bucket and stay within the AWS cloud using the technique here: https://aws.amazon.com/premiumsupport/knowledge-center/s3-large-transfer-between-buckets/
https://aws.amazon.com/premiumsupport/knowledge-center/move-objects-s3-bucket/

Or you can download our Explorer for S3 and check the Options - Copy / Move Inside Cloud option and make the "Inside' option is selected.

If you do that, you can then synchronize the local repository after the copy and edit of the backup plan to sync up the source and target.

But depending on the amount of data, it may be easier to re-upload.

I'm asking anyone on this thread experiencing email issues to open a support case so your issue can be investigated and tracked.

I need to ask again, is this stand-alone Backup (which is where this post was created) or Managed Backup? I get the sense this is Managed Backup, and if so, I'll move the post to the proper section, but please let me know.

Can you please verify that you’re using our stand-alone Backup product and not Managed Backup?

Planned maintenance. It's complete now.

If you opened a support ticket from the product Tools - Diagnostic toolbar option, please make sure the auto reply is not in your spam folder. As an alternative, you can open a ticket here: https://www.msp360.com/support/create-ticket.aspx?prod=backup

• Use a custom retention policy
• Check Delete Versions Older Than and set to 3 Years (Modification Date or Backup Date - you decide based on how you want to handle older files)
• Check Always Keep the Last Version if you want to keep at least 1 version of every file beyond the 3 years - if not, leave unchecked
• Uncheck Keep Number of Versions
• Uncheck Delay Purge
• Uncheck Delete Files that Have Been Deleted Locally

That should keep all versions of every file for 3 years

I'll have to double check, but I believe that's the case. You would have to do it from the agent either on site or by remoting in.

No need to apologize. Thanks for the update and glad your issue is addressed.

Likely because you deleted the objects from the AWS console. In the future you should only remove backup information from the storage tab within the agent. That way we can update the local database with the deletes. Because you deleted in the cloud, the product is unaware of the object deletion, and you'll need to re-synchronize the repository so the product knows about the removal of those objects from AWS. Thanks.

I see. So a specific folder was selected in the plan, and that folder was renamed, and therefore you got an error. Can I assume that you were able to figure this out from the history of the backup plan? If so, just let me know. Thanks.

support went ahead and tested this scenario and cannot reproduce. So, they are asking you to send in the Logs using the Tools - Diagnostic toolbar option (please reference this post and mention I asked you to open a case). Also, can you confirm if Bitlocker is enabled on your Windows 10 PC?

Are you using the Free version of Explorer? If so, that's why as the free version does not include multi-threading. You can try the full version in trial mode to see if it addresses your needs along with other features: https://www.msp360.com/explorer/licensing/

Here's the AWS calculator to estimate storage and retrieval costs: https://calculator.s3.amazonaws.com/index.html

Thanks for the update.

Stay tuned. I'm waiting for some info from the engineering team.

Can you verify your backup version?

We do not back up unused space, so the error message is likely related to something else. Please check your TEMP location in Options (Memory Options). If there is no path explicitly set, then open a command window and type in %TEMP% to see where temp files are going. Please verify that location / drive has sufficient free space. If not, consider moving your temp location in Backup in the the Options screen.

This could also be related to retention and a new full backup. On an existing plan that has been running for some time and needs to perform a new full backup according to the schedule and retention settings, the full backup needs to complete before the old backups are removed based on retention settings. So if you had 500 GB space in backup storage, 400 GB was in use from previous backups, and the new full needed 150 GB, the backup would fail even if there were 200 GB of backups that would have been deleted after the successful backup. Not sure if this applies to you.

Can you post the exact error message as written in the History tab for that plan.

As far as your second question (that I missed on initial review) about deleting a Glacier vault: I believe you can only delete a vault if it is empty. S3 Glacier is for archiving and long-term storage. It's not designed for general purpose object storage like S3 Standard and similar storage classes. If your use case is about long-term archival storage, then S3 Glacier is a great option, as it's very low cost for storage and can protect data from accidental deletion with things like Vault Lock. But if your goal is driven by cost alone, you might find other options like Wasabi or Backblaze B2, which offer hot object storage at very low prices, to be better options. Restoring data from S3 Glacier can be expensive, but that's fine for most users who use that object class and need to restore data in an emergency. But if your goal is being able to access objects in real-time without a 3-5 hour standard wait like S3 Glacier or you need to restore frequently, you might find an alternative service better suited to your needs. That may depend on your region as the other services mentioned are in the US and Europe only.

Under Options - Connection - Queue Thread Count

You can check the Threads setting in Options. I'm not sure if that setting affects deletes, but worth a check.