Looks like you need to assign storage destination for that user after adding cloud account, that should be enough.

We need the full diagnostic archive to investigate that.
Send us the logs via tools > diagnostic menu and mention this forum thread in the issue description.

It's currently not possible to utilize VSS on network shares, so you need to back up those files when they are not in use.

Ok, that looks like a bug. Escalated this case to our devs.

You just need to send us the logs like usual via tools > diagnostic menu. I'll take it over from there.

Is that a cloud to local backup? I need more info on your setup and diagnostic logs mentioning this thread sent to us. Can't guarantee that the issue will be resolved since we provide FTP functionality on "as is" basis, but I'll try to do everything I can.

The software will be able to only perform image-backups of the host, but not the VMs on it. VM edition is preferable when you have several VMs and you want to back them up using 1 instance of the software instead of installing the application on each VM manually.

That step was required for old versions of the software because local and cloud backups used different delimiters( the ":" characters). Now the folder structure is identical in both situations, so you don't need to modify it for the purpose of migration/seeding.

Make sure you're doing everything according to this guide: https://help.cloudberrylab.com/cloudberry-backup/miscellaneous/seeding-data/step-1.-backing-up-data-to-external-storage except the "Modifying Data Structure in the Storage" part, it's only relevant for older versions of the software.

The issue itself seems to be related to using Cool storage class in Azure, so for hot blobs it should work fine. There are currently no news on the release date for version 6.1, unfortunately.

The procedure would be similar to the one described here: https://help.cloudberrylab.com/cloudberry-backup/miscellaneous/seeding-data/step-1.-backing-up-data-to-external-storage

Make sure that you're at least on version 6.0 when doing that, and you don't need to perform additional steps from "Modifying Data Structure in the Storage". You just need to synchronize the repository on your original machine after transferring the data manually.

Also, since you're using S3 I suggest to edit the plan after initial local upload and enable synthetic full option, that will speed up the backup process significantly and actually allow you to perform proper full backups which are required for purging the old data.

Sorry, priorities shifted and our developers want to include more fixes in that version. This came pretty much unexpected, so now we don't have any ETA.

The issue usually happens sporadically without any pattern, that's just a daemon crash. It's one of our top priority issues to fix it for Linux/mac software.

VM edition will allow you to back up all VMs on that host and if you install just a regular version on the host it'll allow you to only perform backups on that machine, that's the main difference.

I can suggest trying to set thread count to 1 via tools > options > advanced. If that doesn't help we need to add logs to our database, so send them via tools > diagnostic menu.

Currently I can offer the following setup:
1) Clone that machine(maybe even by restoring vmdk preemptively)
2) Install our software in restore only mode and point it to the same storage destination while the backups are running on the original machine
3) In case of disaster recovery perform file-level restore on that clones VM and continue working on it.

It's not really an optimal solution, but as of now we don't have the exact functionality you want.

Sorry, at this point we're not allowed to provide early builds, that's QA decision. I hope there will be no more delays with 6.1(there's already been 2), I'm afraid you'll have to wait for the official release, which hopefully happens next week.

"start again for-failed-files" is a generic message that means some data was not restore. In case of file restore the software will retry restoring the files that are filed(well, that's self-explanatory), but for image-based restores the procedure will start from scratch.

Sending diagnostic logs(tools > diagnostic) from bootable USB to our support team should shed some light on why the operation failed.

That'll be a separate web dashboard update, they are released more quickly. This is planned for version 4.5, which will be a pretty big update. ETA is the beginning of August +/- a couple of weeks.

If you're just referring to physical to virtual migration currently you can restore that backup as a virtual disk file and mount it anywhere you want. The procedure is described here https://help.cloudberrylab.com/cloudberry-backup/restore/restore-an-image-based-backup/step-5-specify-the-restore-destination/restore-to-virtual-disk

Brandon is correct here, but we're already working on global auto-update feature that will allow you to do that.