both algorithms are very low overhead and should not impose any noticeable load on the machine. could you let us know what type of machine you're running it on virtual or physical, how many CPU sockets and and whether you have hyperthreading, and also how many threads you're using for the backup. You'll find that last option in the Options dialog. And lastly when you say IO operations, do you mean CPU? Or something else?

This is being tracked on the other thread.

I am unaware we use that type of temporary space when uploading directly to the cloud, which I believe you are doing. I do not know what files you are seeing int he temp folder. How much space are we talking about? Do you happen to have logging enabled to High?

BTW, I am checking with Support.

The suggested workaround from Support is to either purchase an Essentials VMware license or to install our backup software on each virtual machine.

See here: https://kb.msp360.com/standalone-backup/esxi-&-hyper-v/current-license-or-esxi-version-prohibits-execution-of-the-requested-operation

For a one-off, you might be able to use a commercial license trial to complete his restore. As far as Support can tell, the missing component in VMware freeware (VADP) is used in the process of export and import operations. Once imported, they believe the VM would function with the free license. Obviously this is not a long term solution. Here is more info about VADP: https://kb.vmware.com/s/article/1021175

I believe the free version is missing the Storage APIs and that’s likely what you’re running into. But I need to check with Support.

Are you certain there is no remote desktop installed at all on the machine where you are using Quick Support? If there is, Quick Support may launch the previously installed version. You'll be able to see Quick Support when it launches to verify.

You didn't state how you're setting the schedule, but there are two options you should be looking at: either recurring predefined templates or recurring advanced schedule. In either case just make sure that you have an incremental and block level scheduled if you want to use block level. You don't have to use block level if you don't want to. Block level only allows us to backup changes within large files. So if you don't think you'll need that feature because you don't plan on changing large files then you can avoid scheduling the block level. Incremental backup as we call it now in the product for the last few versions is really all that you need. That option will back up all the files the very first time, and then after that only files that are changed or newly created will be backed up. And that's all you have to worry about. Every file is managed individually, so there is never a reason to back up all files at once after the initial backup.

You need to schedule those backups for full and block level if you're using block level. If you're not using block level then you just run the same type of backups over and over and every file is backed up in its entirety every time when it changes, making retention very simple. If you always want to make sure you keep the last backup of a file just in case it hasn't been touched in more than 6 months and you don't want it deleted from backup storage there's an option for that. The only chains that exist are the full backup of a file and its block level backups if you have that option on. And if your retention demands an older version be removed but there are block level backups that exist in backup storage that require it, the full backup of that file will not be removed until it's safe to do so. So most customers will schedule nightly backups as an example and say once a month or once every two weeks run a backup that'll back up the block-level backed up files in full. But there are no backup sets as I've already discussed. files exist within a universe to themselves and have no relationship to other files.

if you're talking about file backups there's no such thing as a full backup as it pertains to the entire set of data. A full just means each file is backed up in its entirety. All retention should be handled by our product. You should not use any kind of retention settings available with the cloud storage providers to remove data independently of retention settings in our product. when you run a backup for the first time all files are backed up in their entirety; each file is backed up as a separate object. When you run any backups after that they're always incremental in nature, meaning, that only the files that changed or are new will be backed up. if you use the block level backup option, all that means is if the file is large enough and only a small amount of that file changed we will only back up the changes. That can help with large files like Outlook PST files that may only change 10 or 20 megabytes per day, but might be many gigabytes in size. With regard to retention and for block level backups, everything happens at the file level, not at the backup set level. If you let our product manage all the retention nothing will ever get removed in an unsafe way. Meaning, we will never remove a full backup of a file and leave incremental block level backups in storage, because that would not allow you to restore. We will only remove the full and related incremental backups when it's safe to do so based on your retention settings.

what kind of backups are you running? Image or file / folder?

Change the settings from the UI if you can (https://help.msp360.com/cloudberry-backup-mac-linux/settings/advance-settings) - should be similar in the web client.

You can try changing the threads as they appear in Settings - Advanced higher and see if that helps. I can't tell from what you posted from the config file if it's set at 5 or 10, but try setting to 20 and see if it helps throughput.

The issue isn't directories and files as such. With object storage they are in fact the same thing anyway. But what you are going to see is latency issues as each file that needs to be created, whether that's a object folder or the object file itself is going to have latency as a result of the round trip out of AWS to Backblaze. One way to reduce the effects of the latency is to increase the thread count. You didn't reply what you have it said to in the backup product, so please reply with that number. Also keep in mind that this is a one-time trip, and even if it takes a few days that may not be a problem for you. But in the interim let's find out what your threads are set to. You can also set the logging to off if it's turned on. But even with it turned off I don't suspect that's going to make much of a difference with NVMe drives.

Thanks for letting us know!

Performance depends entirely on bandwidth variables like: Disk read speed, CPU cores available, threads used in the backup product, network speed, data egress speed from AWS, data ingress speed at Backblaze. It's hard to say what is causing the 16 Gbit speeds you're hitting. Both services can support faster speeds than that, so it's more than likely a VM performance issue.How fast can you read data in the VM? What network speed do your virtual adapters support? How many threads are you using in CloudBerry Backup (in Options | Advanced)? What about file sizes of the files being backed up? Are they small, large?

If you're concerned about the time needed to resync the data, then I would recommend you reach out to Support directly as they may be able to provide you manual instructions on how to preserve the existing repository without the need for a resync. Also, make sure you tell them if you're doing an upgrade in-place or if you're really using a new server / fresh install of the OS.

I sent you a DM with instructions. Let us know if you have additional questions.

what are you looking to use cloud storage for? What region are you located? What's your budget? Do you require very long-term retention? If you're in the United States or the EU then you have access to not only the big three Amazon, Azure, Google, but also access to Backblaze B2 and Wasabi. If you provide more details about what you're looking to do we may be able to make some suggestions for you.

Also check out this white paper: https://get.msp360.com/whitepaper/how-to-choose-cloud-storage/

according to support, this issue should be addressed in the 7.0.2 release, which is tentatively scheduled for release tomorrow or early next week. however if you feel you need to open a support case in the interim for better tracking, please do that as soon as possible using the tools diagnostic toolbar option. Otherwise, I'd wait for the new release and see if it addresses the issue you're running into.

Can you describe what you need to delete from backup storage?

Have you tried changing the cache location in Options - Advanced?