You would have to examine the details of the backup in History - select the plan and make sure the File button on the toolbar is selected. See what is being reported. If a file was in use and locked on the NAS, it likely would not be backed up as there's no support for VSS on NAS devices.

What Steve says is correct, if you're looking for the GUID. But whether that's the best way to remove old data depends on how you have things configured. If you are certain you are removing all computers for a specific user authentication account, then yes. But, if you are only removing some of the computers under that account, then you may want to selectively delete from the user account using the method I described earlier.

If you use the Delete Backup Data Only option under Users, you can selectively remove data from specific machines. https://mspbackups.com/Admin/Help/administration/users/delete-users

You can also delete from the a Storage tab in the Agent. Folders should be named in the bucket using the computer prefix you have assigned to each machine. We don’t name buckets automatically, so not sure what or who created the random character buckets you’re seeing.

I cannot really tell from that message what the actual problem is other than the product is unable to authenticate. Verify your user name, API Key, and Authentication Service on the IBM Cloud web site. Let me know if that helps after verification. If not, look at the detail in the message and report back what it says. Thanks.

Chuck, it looks like the team says you're working with Anna on the Customer Success Team and your licensing issue may be resolved. If there's anything else you need help with, please let me know.

I'll check with Support again for an update.

What's the error then on the SQL Server side?

Are you sure you have the correct license type applied to the SQL Server. It needs to be SQL Server Edition (or equivalent). You can check this from Remote Management in the portal in the Product Version column.

I do not know if it will solve your particular issue, and I am only suggesting solutions based on other public posts regarding the same error. That particular error is not logged in our system, but it's possible Support has seen it before. I would recommend you open a support case with them so they can review logs and diagnose 1-on-1 with you. If you are not comfortable trying any of the proposed solutions in the posts, then I would defer to your judgement and wait for some guidance from a support engineer.

From most of the posts, the indication is that this is an NTFS fragmentation issue. Are you using NTFS compression, by chance? Is the volume formatted using LargeFRS? https://docs.microsoft.com/en-us/windows-server/storage/file-server/ntfs-overview

See if either of these help:

https://social.technet.microsoft.com/Forums/en-US/e0d55018-cf06-43ca-8e20-dd2bb8494c96/8220the-requested-operation-could-not-be-completed-due-to-a-file-system-limitation8221?forum=winserverfiles

https://stackoverflow.com/questions/197162/ntfs-performance-and-large-volumes-of-files-and-directories/291292#291292

Yes, the backups stay in cloud storage. You would need to remove them from the Storage tab if they are no longer required as they will not be removed by deselecting the folders, nor will they be removed through retention since they are no longer being tracked. You can do this from the folder list by right-clicking and selecting Delete.

The 41 GB is just the raw versions and the data is not pulled from storage, but from the local repository. It also does not account for multiple versions of backed up files (you would see all the versions if you clicked on each file). If the consistency check and the repository sync did not help, then you need to check and see what you have directly in Google Storage. Plus, you have a sub-directory "C" under Outlook files and you could have files in there as well as the plethora of other files / folders I see in the list.

How large is the source data you are backing up? Are you using backup compression? The screenshot would indicate you might not be.

We are going to need more information to be able to assist. Are you using the OpenStack version of Explorer? What error are you receiving?

Cloud storage. You already have a lot in storage according to what you provided. Are you saying when you view the Documents folder in Google Cloud, you are not seeing the 2,000+ files? If the files were removed, how did you remove them from cloud storage? Did you use the Storage tab in the product? If not, then what you have is an inconsistency in what the product thinks you have in storage versus what's really there. The product does not know, nor can it detect, when the storage is manipulated directly. In order to fix that, you need to run a consistency check and if that does not address, then you can re-synchronize the repository:
https://help.msp360.com/cloudberry-backup/restore/about-restore/performing-a-consistency-check
https://help.msp360.com/cloudberry-backup/restore/about-restore/repository-sync#:~:text=To%20sync%20a%20repository%20without,is%20logged%20in%20the%20console.

The Free Edition limit is storage use across all backups. I can only guess that your set of files being backed up and 3 versions of each you are keeping along with a 31 day purge delay (which could mean you have 30+ versions of files changed daily) are causing you to exceed the freeware limits. Desktop Pro is $49 and has a 5 TB limit if you need more storage than freeware provides. Or you can try to adjust your file lists being backed up or adjust your retention setting to see if you can being the storage down a bit.

See if this post helps: https://www.reddit.com/r/exchangeserver/comments/9rtyji/suddenly_cant_back_up_large_database_26tb_due_to/

S3 is object storage and not hierarchical storage like your hard drive on your PC. Object storage is flat file storage. S3 simulates folders to add some organization to the objects that are stored there - effectively creating a 0 Byte File to simulate a folder. S3 is not designed for active file management - meaning, you do not create and actively edit files right in S3. You create and edit them locally and copy to S3 as needed and then copy back to the PC when they need to be edited. Your users can copy a folder (event an empty one) from their hard drive to the S3 bucket and it will show up. But you cannot create a folder directly in S3 as far as I'm aware.

If you want your users to work on files locally, but have them stored automatically in S3, then maybe our Drive product would be a better fit.

I do not have a date yet on when you'll have the ability to obfuscate file names. The reason stems from some exciting architectural changes that are in the works for the products that, among other things, will automatically prevent file names from appearing in storage. So, the obfuscation you're after will simply be a condition of the changes rather than an explicit feature as it exists in the Windows product today. I realize the longer wait to have this feature in the macOS version is not ideal, but the file protection you're after is coming. Hopefully, I'll be able to communicate some dates in the near future.

If you have a backup plan that you are no longer using and you have no need for any of the data that has been backed up, you can delete the data from storage using the Storage tab. Then you can either delete the backup plan or remove the schedule so it does not run.

If, on the other hand, you are looking to free up space on existing backups, then do what Ivan posted and check your retention - you may be keep more data than needed. Feel free to reply with your retention needs and a screenshot of your retention settings if you would like us to review here.

No word on TLS 1.3 yet but I'll add your request in the system. regarding your other question, I'm not aware of any man in the middle attack vectors with TLS 1.2 and we do not support SSL 2.0 and 3.0. also, if you're concerned with actual backup data, that data is fully encrypted at the source, so even if they were a man in the middle attack looking at the data stream, the backup data goes directly from your clients to your cloud storage fully encrypted and would be useless to anybody looking at those data streams.