Yeah, my mistake, sorry. Stay tuned for future updates regarding that, we'll provide the info here as soon as anything comes up.

Quick update: the Warning indicator for files to be deleted is removed in version 5.9, so feel free to update to fix that.

Quick update for anyone interested: the issue was fixed in version 5.9, so please update to resolve the problem.

In case anyone else encountered this issue: it was fixed in the newest 5.9 version. Let us know if it still occurs after update.

When uploading files with such symbols you should always take into account what's actually supported on storage side. The only current workaround is to rename these files.

We're planning to rework how the software treats colons in 5.9.6, so by Autumn this should work as expected.

Yes, only the first backup in chain needs to be scheduled, the rest will be triggered one by one upon finishing.

1) Linux version is in very active development, we're planning to introduce block-level and image backups this year. We have a Linux section in the forum where you can provide your feedback.

2) Yes, our primary focus is on cloud service, so for Windows version of the product FTP/SFTP is considered to be in a legacy status. For Linux FTP/SFTP will be supported in version 2.6, it is not available yet.

3) Judging by my personal experience, any connection has its vulnerabilities. Still, if you're just going to upload backups to the cloud you just need to make sure the files are locally available if you don't want to use SMB.

You can simply set schedule just for the first plan in the chain without setting up schedule for subsequent plans, that way you won't have to worry about schedule, all backups will run one by one without overlapping.
Of course, you need to make sure that there is a certain time window between the chains.

Thanks for providing the logs. I've added you to the list of people for this particular feature request. Basically, the software will continue upload after such connection errors normally. Target release is version 5.9.6.

Hi!

Regarding your questions:
BIG QUESTION: What's a best backup recipe that will enable file versioning (like Time Machine)? And which has BOTH a local NAS backup server AND a cloud backup?
You can install the software on A Windows machine, specify that NAS as a source network share, and that's basically it. You can set any number of versions to keep on storage side as you like, even base it on time/date and not the number of versions, so there are many possibilities to keep as many versions as you like.

CONCERN: We had a nice NAS device on SMB LAN networking. And we could put CloudBerry directly on the NAS. However, with the threat of ransomware, there's the danger that a problem on any member of the LAN desktops could propagate to the shared files NAS.
We've discontinued NAS software last year, so I don't think that config would suit you.

PROPOSED SOLUTION:
1) DESKTOP BACKUPS: Considering doing rsync (or if there's a W10 GUI version of this) or other backup software to the BACKUP NAS over SFTP. Full near real-time backups but no risk. Important that VSS is working.

2) FILESHARING NAS: Same as desktop backups, SFTP to BACKUP NAS, with no risk.

3) BACKUP NAS TO CLOUD: Put CloudBerry (re-purposed license to Linux) on Linux in a VirtualBox Guest on the BSD NAS. Use CloudBerry to pump versioned files to some cloud host. 2.5 TB total without duplication for versioning.

1) Can't really comment on 3rd-party software usage and how it could affect our software's functionality, but if you're just syncing files and it works for you to transfer the data to another device and then back them up using our software that should work. Make sure there are no VSS conflicts when doing such operations.

2) We consider FTP/SFTP to be a legacy protocol and this functionality is provided "as is" within our software.

3) Yes, that should work. You can use Windows client for that, since functionality-wise it is a bit better than Linux version.

BEST PRACTICES QUESTIONS

a) VERSIONING - How can we do file versioning, rather like TIme Machine on Mac? This is essential for protection against ransomware.

b) THRASHING With four or five clients pumping files into the NAS Backup NAS, plus Cloudberry pumping files up the Cloud, will this create disk thrashing on the Backupu NAS? Or is the server smart enough to queue things, and it just takes longer? Probably there won't be that many files eligible for backup in any given hour or two anyway.

c) DIRECTORY CHANGE PROPAGATION -- If a directory name change takes place, or even if a directory is moved, this can create cascading unnecessary changes. How does CloudBerry deal with this? And similarly, how would Cloudberry deal with deletions, as the propagate from desktop to Backup NAS to cloud?

d) ARCHITECTURE -- Is the above plan the best architecture? Let's just ignore the file sharing NAS, and think of this recipe as A) first, backup local clients to local backup NAS and then (B) backup local backup NAS to remote Cloud.

A) You can simply specify the number of versions to be kept on storage during creation of any backup plan and that's it, no additional actions required, the software will do the rest.

B) The software is smart enough to queue the files during upload, so you should be fine on that front.

C) There is an option called "delete files that were deleted locally", so the software will remove deleted/renamed files/folders, so if you enable it you won't have to worry about that.

D) Yes, you can use 2 separate plans for that with different retention for each(if you want, of course), or set up a hybrid plan that will first upload data to local destination and then to the cloud one.

Let me know if I misunderstood you regarding some of the points.

The setup should actually be very simple: Install the software on a Linux/Windows machine, connect to your NAS, select the files for backup and their destination, that's it.

Yes, that should work without any problems. You can chain those plans in whatever order you want.

Thanks for bringing this up, this is most likely due to local backups not being taken into account for that free edition limit. We need to check if it can be reproduced internally.

Feel free to activate the trial version with 15 days of full functionality to test the software before you buy it.

Yes, full backups are important to keep the data consistency and ensure proper versioning for image-based backups. Running them once or twice a week is generally a good decision.

It is technically not possible to run full backup and in the process run block-level backup simultaneously, since every block upload needs full. It is natural for block-level backups to be skipped since the software didn't finish previous upload for this plan.

If you're using Amazon S3 the best choice for your environment would be to use synthetic full functionality, this will reduce the upload time significantly during full backus.

The backup will skip the chain if it's not finished by the time the chained run is triggered.

As a rule, any plan will skip scheduled launch if it's still running by that time.

When you de-select backed up VM from the plan you would need to delete it manually. You can do that from the backup storage tab.

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.

Thank you for the feedback!
I've created a feature request on your behalf and our R&D will consider it for one of the future versions of the dashboard.

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.

Yes, Linux-hosted Minio works as intended.