There's already a requirement in the system to be able to copy empty folders and / or create new ones in Azure. I've added your request to the requirement. Thanks.

So, here's the lowdown with Azure and some other cloud storage providers. In cloud storage, there is no such thing as a folder. Everything is an object stored in a flat file structure. While empty objects can be represented in the user interface as folders, the way to create a folder is to create a file that has a prefix folder name (e.g. mysubfolder\myfile.txt). If that's done, Azure can show it as it's in a folder in a more traditional file system. Or you can copy a file that is already in a folder from a local drive. If you really need to create the "folder" in advance, you need to place a small file like a temp.txt a few bytes large in the local folder and then copy over the folder. Once the file is copied, you'll see the folder and the file - which you can delete and leave the "folder" object in place.

I'll have to ask the team why copying an empty folder doesn't create the necessary object in Azure, but my guess is it's a limitation on the Azure side.

What happens?

then what I'd do is copy over an empty folder from a local drive and create it that way. I'll have to check with the team to see if the azure explorer works differently than the S3 version I was looking at.

You can either click on any object already in the folder you are looking at and select the New Folder option. Or, if you do not have any objects yet in the folder, use the New Folder toolbar option.

Can you DM me with your registered name, email, and company please. Thanks.

And you're positive that you have at least one Windows Desktop license available when you check the Licenses screen, correct? Can you also confirm the version of the agent that you have deployed to that particular endpoint?

Same bucket is perfectly fine. Consistency Checks are run at the Backup Prefix level for the agent in question. So only the files local to the agent are checked.

Are you sure you are not using MSP360 Managed Backup. You posted in the stand-alone product section. I can move the post if needed, but I need confirmation on your product in order to help. If you're using Managed Backup, you can see your licenses from the Licenses tab in the management console. Are all the licenses allocated to endpoints already? You say there are 4 available. What platform are you using the trial on? Windows? Desktop or Server OS? If it's Windows Server, then you need a Server license - the Desktop license will not activate on Windows Server.

If you are using our non-managed products and bought 4 perpetual licenses, then you can see your licenses from https://cloudberrycentral.com

Sorry, but I need additional clarification on the product and your endpoint in question.

So, you're using our stand-alone CloudBerry Backup, correct? Are you looking to grant one of the 4 licenses you purchased to a new installation of CloudBerry Backup?

I need additional detail to understand what you are trying to do.

https://help.msp360.com/cloudberry-backup/product-licensing

Yes. We continue to support the legacy format. But I'm not sure exactly what you mean by proprietary. The legacy format is proprietary as well. You always have to use the product to restore backups. The only exception was a Simple file backup method option which is nothing more than a form of file sync and not backup.

That edition “Desktop” is an old, legacy edition that did not support image backups. You need Desktop Pro. I would check with sales and ask them about upgrading to Desktop Pro.

https://www.msp360.com/backup/windows.aspx

you’d have to reach out to Support and they can check your licenses.

You need to use the legacy backup format in the drop-down on the toolbar for file backup.

You must have used the simple backup format in the past. Create a new backup plan using the legacy format and make sure you select the simple backup type in the wizard. https://help.msp360.com/cloudberry-backup/backup/cloud-to-cloud/step-5

Unfortunately, that version is very old and no longer supported. Please consider upgrading to a supported version. If you have to use this old version, then check your TLS versions installed and which protocols are enabled. I think you may need to have TLS 1.1 enabled. If you have a maintenance contract, you can reach out to Support for guidance on upgrading or solving the issue. I do not see anything in the system for this error other than a .Net upgrade need (which you checked) or TLS related issues.

Can you verify your backup version?

Please try updating .Net on that computer to the latest version 4.5 version.

I'm still waiting on some additional information, but I meant to add in the previous reply that in the new backup format, we process files and physically group them together to reduce I/O and improve performance when backing up large numbers of files, especially to cloud storage. We call them "parts". These parts are not large.

In case an upload does not complete because a laptop is shut down, the product will restart (and re-upload the last incomplete part) and then continue with the remaining parts. In that sense the backup effectively continues from where it left off.

If you're performing a file / folder backup using the legacy backup format (which is not going away), the only real full backup is the initial one and that backup can be continued as needed to complete. The "full" as I'm referring to it here is not a a logically linked set of files, but simply a backup of each file. That's why continuing the backup is easy - the product just detects which files have not been backed up yet and backs them up. Subsequent backups, whether they are incremental or full are only backing up changed files. We never back up all files again. Any backups run after the initial full generally run much faster since the breadth of files that are changed is normally low compared to the initial set of files backed up. These subsequent backups also can be continued the next day.

For image backups, however, it's best to have the machine running until completion.

I'm not trying to convince you we are the best solution for you. Just trying to clarify how we work.

If you're using the new backup format, then as I understand it, there may be a bit more work involved to create the synthetic full - compared to the legacy format. I've asked the team for some guidance if my understanding is correct and what customers should expect on duration. But what I would say is that you can use the legacy format and schedule as needed, even multiple times a day since only changed files get backed up, and only the changes within files if you use the block-level option, as that would not be an issue for machines that are not running at all times.

I'll reply back with details on new backup format full backups once I get an answer on those details.