In this case this functionality serves the purpose of restoring your data disks.
To perform full system recovery you need to create bootable USB

Yeah, there's unplanned server maintenance currently going on, so you may experience some connection issues. Everything should be in order soon.

Known issue. Some things changed on OneDrive's side after some recent updates. Our R&D is working on this, but in general we don't recommend using OneDrive of Google Drive for reliable backups.

Currently the files can only be deleted from the backup storage tab via software GUI. This might change in the future.

To delete everything that was backed up by a certain machine follow this guide: https://mspbackups.com/Admin/Help.aspx?c=Contents%2Fhelp_drop_users.html

By the "folder name" I presume you're referring to the backup prefix. You can also do that by manually typing it. Note that all backups from the old folder need to be transferred to the new one manually after that. Or you can start from scratch.

You can delete files via the backup storage tab, that would be quicker.
if you delete it from the storage outside of the software you'd need to run sync again.

That's the change we introduced with version 6.0. Starting from this version all backups are stored under "$" delimiter, the software will continue functioning as before and should not affect how data is displayed on the backup storage tab. Overall, data is not being duplicated and no additional charges will incur.

This change has been introduced to streamline the data set migration between local and cloud backups.

Currently we don't have such option but I created a feature request on your behalf and forwarded your feedback to our R&D.

In 99% of the cases it takes about 5-10 seconds to list the data once you launch it on USB in regular mode since we only list image-based backups. In case you want to troubleshoot this further we'd need the logs sent to us from bootable USB so we can check why data is not being listed.

No ETA yet, but it shouldn't take long to fix that.

I checked the status of the ticket and it seems to be a pretty unusual issue. The problem is being investigated with the help of our R&D and level 2 department. You should expect a reply soon.

After some investigation I escalated this case to our R&D. In case anyone experiences the same behavior do not hesitate to send us the logs via the instructions above.

The software rebuilds local repository during this process. The speed depends on the amount of data in the cloud.
Try switching storage account to "restore-only" mode by editing storage account and under advanced setting selecting "restore only" instead of regular mode.

What OS do you use? Try reproducing the issue and send us the diagnostic logs(tools > diagnostic) so I can create a task in our bug-tracker.

Most likely you're trying to delete backups that were made using a different backup prefix(i.e. different machine).
You need to navigate to Online Backup account menu, go to advanced settings and switch prefix so it matches the one you see on the backup storage tab.
Also, if my assumptions are correct it's actually quite likely that those backups no longer exist, since the info about the data under inactive prefixes is not updated automatically.

I see that ticket has "Escalated to developers" status, and steps regarding integrations/checkpoints are a part of a standard troubleshooting procedure. I suggest to continue conversation in this ticket.

First thing to try is to specify your RAID drivers when creating bootable USB.
As a workaround you can also try installing full version of the software in your Parted Magic USB environment and retry operation. Can't guarantee that this'll work but work, but worth a try.

Were'aware of these issues. For now please send offline activation service keys to supportatcloudberrylabdotcom as a workaround. Our licensing department will generate activation keys on our side.

We received the logs from Marc and it seems to be a known issue related to image-based backups to Azure. Fix is planned for version 6.1. You can send us diagnostic logs via tools > diagnostic menu with reference to this thread so we can confirm that.

Your retention policy will work for use cases 1 and 2, for 3 you need to tick the option to keep 14 versions of each file.

Note that in the third case the software will purge files according to the first triggered rule, i.e. even if you don't have 14 versions of a file old versions will still be purged based on time-based retention and vice versa.

Most likely there were no files matching your selected criteria for restore.
Check if you receive the same error while selecting versions manually.