I'm not expecting some magic solution. Of course the EFS certificates would need to be backed up. In a Windows domain scenario, the best solution would likely be backing up the recovery agent's private key (since the default recovery agent is the admin account on the first domain controller).

While it might be possible for backup software with sufficient privileges to handle this key backup automatically, I'm certainly OK with having to do a one-time manual export of a recovery agent key to a file that could then be backed up along with all the other files.

But all of that is moot if the software refuses to backup EFS encrypted files at all. There are certainly other apps that have successfully backed up EFS files without decrypting them. The trick is using an EFS specific API from Microsoft. Bvckup2 is one such software (great software, but only supports local network source/destinations). You can google "bvckup2 efs" and the top result should be a forum where there are details and a link to Microsoft's EFS API.

You ask why I am using EFS. I'm not, nor do I like it. I'm actually about to disable support for it domain-wide with GPOs for most of my clients. The problem is that, unless it is disabled in the domain, any domain user can choose to use it. So any clients with users that already have EFS-encrypted files will still have those files. It is what it is.

In regards to the image backup, there is a lot more flexibility for a variety of things (like retention) that you can do with file-level backups, so I don't see an image backup as being a viable workaround at this point. Bottom line, it doesn't seem like it would be that hard to just back up the files as-is using Microsoft's EFS API in a file-level backup (along with warnings for any EFS files in regards to the need for a recovery key).

@Matt Is there any update to this now that v7 is out? There never was a v6.4 release. I only point that out because that is the version you stated would include a fix. I see nothing about any EFS related fixes or updates in the "What's New" release notes going back to version 6.3.2. I don't typically complain, but Cloudberry is supposed to be an enterprise-level backup solution and isn't super cheap either. The basic server-capable license for Cloudberry also at some point recently increased in price to $180 from $120 (a 50% increase).

That's unfortunate. Version 6.3 is not even out, so when is 6.4 expected? I was under the impression that this would be resolved in months, not years.

Thanks for the update. I look forward to the solution, as I'm using the server (i.e. more expensive) version to back up a Windows server that contains network shares. The EFS encrypted files in question are coming from multiple users, so neither of the workarounds are viable options at this point in time.

I'm on 6.2.0.154 and have this same problem with EFS files. It gives the same error both with local and cloud backups (to B2). I don't want to use the SYSTEM account "workaround" as that somewhat defeats the purpose of EFS encryption to begin with. Other backup software like MozyPro has supported backing up EFS files and certificates.