Yes, that option is only available for the standalone backup. Since you posted this in the standalone section I presumed you were using it.

There's a known problem when using old creds. Service account authentication should work fine. The issue is related to some minor changes on Google's side and it will be fixed soon.

Try using custom mode, that will allow you to select a subfolder and put your data without any changes to the folder structure. Note that versioning is disabled in that mode.
It can be selected while creating your backup plans.

More info on backup modes can be found here: https://help.msp360.com/cloudberry-backup/backup/cloud-to-local/step-5-specify-backup-mode

Just checked and o365 notifications are in the testing phase, no target release yet.

Sorry, no info. New archive mode for Windows should be out in Q2, we'll gather feedback and the developers will implement that functionality based on the Windows feedback.

Ok, got it. Please create the log archive locally by this command(please note case sensitivity):
"/Applications/CloudBerry Backup.app/Contents/MacOS/cbb" saveLog -p ~

The archive file will be placed in the home directory of the user currently logged in.
Please create a ticket regarding the problem and send the archive to us attached (if it is too large - upload to any file hosting and send us download link).

There was a minor problem with our download page, everything should be ok now.

Better to send us the diagnostic information via the application menu, since Mac and Linux products have dedicated support team.

The first log snippet you posted is from version Version: 4.8.0.180.

Were all of your backups made using this build? It's been in deprecated status for about 4 years now and the issue seems to be strictly related to SFTP setup, Windows uses different wording for EOF error.

Did you use compression during the backup?
Can you open that file outside of our software by simply copying it from the storage?
What is the backup time difference between the data that can be restore and the data that can't be?

We currently don't support native Windows deduplication, support for it should available in v. 6.4.

If you're referring to our dedup version of the software, it's been deprecated, so please use it at your own discretion.

Maybe I misunderstood you, but I meant to actually update our software, the procedure shouldn't take longer than 5 minutes.

As for the Linux version, image-based backup is currently in internal testing, there will be a global announcement regarding that, so feel free to test it upon its release.

You can click "I don't have the code" button and enter any email you deem suitable for that purpose.

In case of self-hosted storage being used make sure you're on the latest version and if the problem persists we'd need the logs from the machine(tools > diagnostic menu)

Without encryption password and the original backup plan the is data unrecoverable, so there's nothing we can help you with.

Happy to report that most of the things you mentioned will be in version 7.0. It's too early to talk about the beta, the build is in internal alpha testing now, but things are going fine, we'll try to release it in Q2.

As for the problem with file restoration, I would suggest to send us the diagnostic logs via tools > diagnostic menu after reproducing the issue one more time.

Encrypted data without the password can't be restored. If you have the original backup plan that was used to transfer the data to the cloud you'd need to open a support ticket and explain the situation. Can't guarantee that data will be 100% restored, especially if you also changed the password previously, but that's the best way to try and restore your files.

Try syncing the repository first via tools > options > repository menu. If that doesn't help please open a ticket regarding the problem.

Also, if the files were previously selected for the plan and then de-selected after performing backups then this is actually expected, such files are "orphaned" and will never be purged from the storage side until deleted manually.

No topics regarding that were deleted, as far as I'm aware.(Except the duplicate thread)

A lot of things changed during this time, but GFS and client-side deduplication are on our road map. Client-side deduplication should be available first, with GFS to follow after that. That's all the info I got from the R&D.

The procedure is automatic, it only takes a few seconds to complete.

Most likely there's a problem with connection to the cloud, so make sure your cloud provider endpoints and our executables are white-listed on your side.

You can also send us the diagnostic logs for investigation via tools > diagnostic menu.