Hi Henke, 

Volumes using BitLocker encryption are backed up if the volume is unlocked. You must not run scheduled backups unless the volumes using Bitlocker encryption are unlocked.

Hope this helps. 

@Blaine Williams is there any checks on the agent part to determen if the volume is locked/unlock.

I think your best best is to exclude the volumes from Backups.

@dude So if a file server have bitlocker enabled on it’s datavolumes best bet is to exclude the volume? Sounds a bit counter productive though.
I would think that all volumes would be in an unlocked state, if a volume is in a locked state something is wrong I would guess. I’m not that experienced with bitlocker though.

@Blaine Williams What happens if a scheduled backup runs against a drive that is locked by mistake or error?
 

@Henke I guess what I was trying to say is that you can still get the VM backed up and restored if needed, however when it comes to the datavolumes, my understanding is that you would not be able to backup that up while the volume is locked. 

As for the schedules, it will fail as it can open the disk.

https://documentation.commvault.com/commvault/v11/article?p=30816.htm

• Logical volume manager (LVM) metadata processing for volumes encrypted using BitLocker is currently not supported. Decrypting contents of such volumes may not be feasible during browse or restore operations because decryption requires a recovery password or a decryption key. Because enumeration for the volume fails, a file-level browse operation for the encrypted volume cannot display file information.

For VMware or other VSA style backups, you can backup the volume no problem, but file level browse wont work since that would require the decryption key and code to process bitlocker volumes. You could still do a full VM restore or restore/attach the volume back to another VM to decrypt it

Thanks @dude and @Damian Andre  for the clarification.