Yes, that can be achieved. Just follow this guide: https://kb.cloudberrylab.com/kb1051/

Thank you for this link.

I hoped there might a more straight forward way to achive this:
1. Creating a Backup Plan which stores the Backup in a folder on an external Harddisk.
2. Uploading the content of the folder to the cloud storage.
3. Creating the Cloud Backup Account
4. Performing a repository synchronization
5. Changing the Backup Storage in the Backup Plan from Harddisk to cloud storage.

But it seems that this is not possbile, Cloudberry seems to use absolute pathes including the path to the backup storage instead of relative pathes?

Thanks,
Florian

You can actually do that too, just make sure you're renaming "$" characters with "%3A". This is how we replace colons for storage destinations, since that character is forbidden. So you will see C%3A on cloud storage side instead of C: when looking at the folder path.

In short: colons are replaced with $ for local destinations and with %3A for cloud destinations. If you perform the procedure keeping that in mind everything should be fine.

Thank you for your help, it has worked as expected. There is still one little problem, perhaps you can give me a hint. When browsing the cloud storage the "versioning" folders are displayed in the Cloudberry Client. This does not happen on the local storage. What can be the reason for this, see:



Thanks,
Florian

Looks like you might have missed something.
Make sure you've replaced all colon symbols in those folders with %3A and the folder structure is the same as on the source.

I think there is an encoding confusion. The NAS is using en_US.UTF-8 as encoding. If I replace : with %3A the images are not regonized anymore, see the following image:


I performed the renaming directly on our Backup NAS, using the default linux command mv.
Therefore I need to replace %3A by :, then the images are regonized, and I can also make a revovery, depite that the image folder are displayed as in my posting before.

Thanks,
Florian

It is better to perform such oprations in the cloud after upload using Cloudberry Explorer to avoid conflicts like that.

Hi thank you for your help, but I am still suffering of this problem.
I uploaded the backup from the external harddisk with the Cloudberry Explorer. Then I renamed manually all $ synmbols by %3A, see this image:

Then I updated the repository:

As you can see, the same problem as above, but the images are not even recognized.

Thanks,
Florian

thanks for providing these screenshots. Consulted with my colleagues, and it seems some of the things were changed regarding the "adoption" of the files.

As a workaround it is better to use the method described in the article I posted earlier, with uploading the files using the backup software.

I'll consult with our R&D regarding adoption of the files and will let you know the results.

Thank you for the clarification, event if these are not good news for our use case. The method of the blog entry is nearly impossible to realize in our use case, because we will have dozens of users, medicins, lawyers, small companies who have internet contracts with low upload rates, where it would take several weeks for the first backup to the cloud.
You have a really good backup solution esspecially with the possibility of managed backup, but I would really suggest you, to integrate a "local to cloud backup" mode into your Cloudberry Explorer, because I think, we are not the only one, which habe this problem.

Thanks,
Florian

That's actually what we're going to discuss with our R&D. Basically a certain functionality to "adopt" the files with a press of a button in Cloudberry Explorer.

I just want to add, that the "file folders" (from each file a folder is created in which the different versions of the file are stored) will be displayed when exploring the backup storage after deleting a connection, creating a new one and than performing a repository synchronisation. They are displayed in combination with the files, therefore you can recover or update each file. Probably this is depending on the endoding the object server uses.

To clarify: In this scenario I made a cloud backup, deleted the connection, created a new one with the same settings and performed a repository synchronization.

You can see it on the image:


Greetings,
Florian

Yes, that is a known issue. In one of the future updates we'll use $ signs for all types of storage destination universally to avoid problems like that. Currently the "adopt" feature is flawed.

I'm wondering what will happen to backups on cloud storage (like B2 in my case) that currently uses colons for their "special delimiter". Ideally, the change will not require fresh uploads of data. Any ideas yet on how you'll deal with data already backed up?

This will only affect new uploads to local destinations, the implementation itself is still being discussed, but you won't have to re-upload your whole data set.