@kelvin koh Thanks for posting the question.

Is you environment Vsphere and the PVC that you use are vsphere CSI provisioned ?

As of today, VBR profile is supported only for Vsphere CSI provisioned volumes.

https://docs.kasten.io/latest/usage/configuration.html#veeam-backup-repository-location

@jaiganeshjk yes i only have 1 storage class which is CSI, i hope the below information can confirm it.

thanks for the details.

Actually, I misunderstood the question earlier. I see that you are trying to use VBR profiles for collection in the policy right ?

VBR profiles doesn’t support collections as of now. You will have to have an alternate S3/compatible storage for metadata storage

https://docs.kasten.io/latest/usage/protect.html#backups

• When the destination is a Veeam Backup Repository Location then the data is uploaded to a Veeam Backup Repository. This location type does not support metadata storage.

 

@jaiganeshjk, sorry if my question make you confused, may i know what is mean by metadata storage? i did use nfs storage or sobr as the repository but still receive same error.

thank you,

i configured s3 storage for the backup and it work well. just wonder what kind of backup supported in VBR Profiles?

i finally figure out what going on here, veeam vbr profile location only supported persistent volume data, which not supported for “Export Location Profile” and “Location Profile for Kanister Actions” and i need to use S3 location profiles.  At the “export snapshot data in block mode” i can select the VBR profile to backup the persistent volumes. 

Yes @kelvin koh I missed the notifications from the thread.

Yes you are right. VBR just supports Block mode export from the PVCs. It doesnt support backing up the metadata/configs/manifests etc.

All the configs/specs/metadata everything needs to go to another location.

:) just a related question @jaiganeshjk Is there any time frame available for when full export might be available to VBR, considering V12 will support S3 direct repositories? Thanks

@Geoff Burke 

We don’t have the timelines yet. I will let you know if I get to know about it later.

Thanks @jaiganeshjk 

We’ve been exploring K10 and Veeam recently and just came across this same issue on the latest release.  Here it is a year later and it doesn’t seem like there’s any change.

I’m sure we’re not alone in the fact that we don’t use cloud storage for backups, or any object storage for that matter.  Yes, we do have off-site backups, etc. but not everyone wants to do it with cloud storage.  Object storage isn’t an option for everyone.

I really wish there was some better options here.  Some examples:

1. We don’t actually care about backing up the Kubernetes configuration.  In our case we have CD/CI pipelines, etc. in place so we could rebuild the cluster from scratch if needed.  Really, we just need to be able to snapshot and backup the volumes themselves.
   1. It sure would be nice to just have an option that only backs up the storage itself.
   2. One work around here might be to drop K10 entirely and use traditional Veeam snapshots to just grab the Kubernetes nodes at the VM level.  However, I worry that this could be very troublesome for Kubernetes itself.
2. What about using something like the Configuration Backup storage for holding the Kubernetes configuration files?  It’s this already a kind of metadata storage anyway???
3. What does this “have to be object storage”???   It’s really just a bunch of YAML files anyway.  Sure, object storage can give some efficiency in indexing, etc. but any old file system can hold text files.  Heck, I’d be happy with just putting them all in the TAR archive and calling it a day.  That can then be placed on any of the Veeam storage, or Configuration Backup location.

For those that are still struggling with this, we are going to try out my last suggestion here.  We’re not sure how this will work out with the other Veeam integrations, but it should work for our purposes.  That is this:

1. We run our Veeam server on Windows, and have our storage mounted through iSCSI.  We’re running ReFS on the storage itself for efficiency.
2. We are going to try running a small instance of MinIO, which has a Windows executable, and have it write to a different directory on the same iSCSI mounts.
   1. I’m not sure how MinIO will interact with ReFS, but we’re going to find out.
3. This should give us a small object storage to satisfy K10 requirements.
4. In theory, since we’re on Veeam 12+, we should be able to make this a “S3” object storage within Veeam and manage it’s contents through the same mechanisms.