The best place to go for an overview for most releases of the stand-alone version is the online help in What's New section:
https://help.msp360.com/cloudberry-backup/whats-new

An update on this from the information I received from the team:

Synthetic full backups for Backblaze B2 (not S3 compatible) will be available when the new backup format is released in the 4.9 MBS version. At this time, we are not planning to support Backblaze B2 Synthetic Full backups using the B2 S3 API. I can't go into details as to why, but I believe it has to do with some limitations in the Backblaze's B2 S3 API implementation.

It's currently scheduled for the 5.0 release of the Managed Backup console. That a couple releases away, so I'm trying to get some confirmation from the team if that's still the plan or if it might be out sooner. You can add B2 storage using the S3 - Compatible connector, but we have not certified synthetic backups with that configuration - I just wanted to mention that just in case you were going to try it (don't :-))

Please open a support case from the agent using the Tools - Diagnostic toolbar option and please reference this forum post when submitting the logs. Thanks.

Thanks for the update. Your other option which I think will work, is to expose the local folders as a share and then you can back up without the need to copy the files to the NAS. But whichever process is easier for you...

With network shares, you're not using the file system directly - you're likely using NFS. You can expose the local files as an NFS share if you want. You do lose some low-level functionality with network shares as opposed to direct file-system access (VSS on Windows, Block-Level Backups on Windows / Linux to name a couple). But doing so should allow you to back up these local files.

ZFS support has not been scheduled (and in all honesty, the requirement has been open for some time). We are not yet seeing much (if any) ZFS use with our Linux customers. I have added your comments and desire for ZFS support to the thread. If I hear anything from the team, I'll reply here.

ZFS is not supported. Ext 2/3/4 are supported and so is BtrFS, I will add your comment to the open feature for ZFS.

Can I ask what drove you to chose ZFS over something like EXT4?

Thanks for the update. Happy it's now working.

You're going to have to provide more detail about what exactly what type of backup you are trying to run and what the issue is that you are seeing. Also, please upload any images using the "Upload Files" icon in the forum reply area as the previous image is not rendering properly.

[EDIT] I was able to see your image by going to your image share URL directly, but I do not see any errors in the image. It looks like the backup is running, so any further description will be helpful.

A requirement is already in the system. I have added your request to the queue. The feature has not been assigned to a release at this time.

I do not think that module is supported by Wasabi. It was designed for AWS IAM. Having said that, I will check with the Explorer team and enter a requirement on your behalf to investigate whether the current AWS functionality could work with Wasabi.

Could you provide more detail about what you are trying to do? I read over this article on the Wasabi site: https://wasabi-support.zendesk.com/hc/en-us/articles/360000016712-How-do-I-set-up-Wasabi-for-user-access-separation-. I am not sure if this is what you need, but it seems if you set up bucket access policies, you can assign sub-users to those policies with their own access/secret keys they could use in Explorer to see only what they are supposed to see.

But any additional details from your end would be helpful.

Look forward to your reply.

You *could* be wrong, but there's no easy way to tell. Let me illustrate:

Let's say you use a 6 Month Retention with unlimited Versions and daily backups and you had 100 GB of files to back up (and we'll assume no compression or block level backups in this example). Your storage is now 100 GB. You change 1 GB of files a day for the first 3 Months and you back up 1 GB * 90 or 90 GB. You then start changing 10 GB of files a day for the next 3 months for 10 GB * 90 Days or about 900 GB. . Your total storage is now 100 90 + + 900 or about 1.09 TB.

You then change your retention to 3 months and what are you left with? About 1 TB as you only removed the oldest files which accounted for less space than the newer backups.

The way to avoid this if it works for you is to limit the number of versions. In the Retention Policy in the backup wizard, check the option to keep a number of versions to a number that works for you. If you change a file every day and do not need 90 backups of that file, then change it to a number that works for you personally or your business.

Also, if you're using Block-Level Backups, then you need to make sure both the blok-level and incremental backups are scheduled on the Schedule tab (Recurring Pre-Defined or Recurring Advanced)..If you're not using block-level backups, then ignore this.

Also, keep in mind that if you manually unchecked a folder for backup that was previously a part of the backup plan, the backups for those files remain in storage indefinitely. If you no longer need them in backup storage, you should remove them using the Backup Storage tab in th product.

If you still have questions, please let me know.

So, I confirmed, and as I suspected, you cannot continue image-backups once you perform a restore to a new system or VM. Backups are block-based and tied to hardware IDs of the disks and that means you'll need to start fresh on the new server VM. You can, however (and obviously), keep the original physical server image backups around as long as needed until you are ready to remove them permanently.

Can I assume you're talking about the image backups? I assumed you had file backups as well. I'll check with the team, but I'm pretty sure there's no way to preserve the image backups on the new system since the drives are structured completely differently from their physical counterparts.

You may want to check and make sure both TLS 1.0 and 1.1 are enabled on the system according to this article: https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings#tls-10

If that doesn't work then I'll have to ask you to open a support case since it's very tough to diagnose these types of issues on the forum.

Where are you sending the backups? What version are you using?

I'm checking and will hopefully have a reply later on Tuesday.

Can you confirm you are using the latest release on both ends? There was a similar issue that was fixed in 2.4.0. 8. I believe the latest release is 2.4.1. 19

The script error should have been fixed in v6.3.1 according to Support:

But if you're seeing the same issue in 6.3.1. or later or in version 7, it may be unrelated. Just a note that in version v7.0, you can only use Service Account authentication:


Also, you need need to make sure you have <ShowAllAccounts>true</ShowAllAccounts> set to True in the enginesettings.list in C:\ProgramData\CloudBerryLab\CloudBerry Backup.

To use the Service Account, follow the instructions below:

• Go to your Google APIs dashboard:
• https://console.developers.google.com/apis/
• Click "Enable APIs and Services":

• Go to the "Credentials" and to see the Service Accounts you can use for authentication in the CloudBerry Backup.
• If you don't have any Service Accounts, please create it and make sure it has the "Owner" role.

An important note: Google Drive support was dropped a little more than a year ago. You can enable the service so it's visible in the product using the instructions above, but you should consider moving your cloud storage to one of the other supported cloud storage vendors.
https://www.msp360.com/resources/blog/consumer-storage-is-going-to-be-deprecated/