+7
Our admin has said rather than us backing up all apps or namespaces in OpenShift, we should go after only PV’s. I don’t see any way to filter for those in the guided setup for k8s nor in the UI, so, is this even possible without elaborate scripts to dump out of the various clusters and feed directly to a job?
Sorry if that’s a bad way to explain it but they don’t want or care about “us” backing up OSC’s, only the PV’s.
thanks
Best answer by Mathew Ericson
View original
+23
I doubt there is an option to only backup the PVs. Perhaps you could script access to the PV location and use a FS agent to grab them - but how will you recover? If there are a lot, it may be very time consuming to reconstruct the applications and re-attach the PVs after restoring them.
I know that you can choose to restore PV’s only - so perhaps that is an option?
It would be interesting to know why the admin considers backing up the metadata associated with the app as undesirable?
+14
Hi
When configuring an Application Group in the Command Center interface, You should be able to drop down the content selector and pick Volumes (Instead of Applications or Labels).
From here you can then select which Volumes you’d like to protect.
Best Regards,
Michael
+7
Hi guys,
I cannot explain the reasoning behind targeting volumes only, but this is what I’m tasked with. For instance, there’s no way to wildcard “persistent volumes” as content? It doesn’t do us any good to manually go in and check boxes for PVs - how is that sustainable? So is the assumption (usually) that people decide which apps to protect, then those automatically contain the volumes? The other thing was is it possible to only label PV’s which are required to be protected thus excluding everything else?
thanks!
+23
Tagging
+6
Tagging
This is possible today and the previous answers identify the correct method.
Now if your looking for a more dynamic approach, we recommend you use Label selector
+7
Hi Mike,
Yes, I think after we played around a bit we realized that the reason I wasn’t seeing more PV’s showing up when simply selecting those was “there weren’t any” 
. I had the incorrect impression based on what I saw in the storage array there were “piles” of volumes Cv was missing or failing to detect. Come to find out those were stale, unclaimed, etc.. Mostly orphans I guess. However, along this same topic, when I do try to backup those it discovers, the backup fails. Maybe someone can link a drawing or something here if it’s not easily explainable. The situation:
Access node is the MA. It has no presence on the iSCSI network the controllers or OCS cluster nodes do. Snapshot is for sure created but fails with obscure network disconnect error apparently when trying to have the access node mount the snap. Can anyone confirm that A) every PVC being backed up must be accessible over iSCSI just like OCS does or B) can’t it just pull the files directly from OCS to the access node? Maybe there’s other permutations of this but the docs I’ve read seem to obscure this actual flow.
thanks!
+6
A) every PVC being backed up must be accessible over iSCSI just like OCS does or
Commvault leverages the Container Storage Interface (CSI) to perform backups of Persistent Volumes (PV). The requirements are dependent on your storage vendor and their CSI prerequisites - I would suggest logging a support call so Commvault can validate your storage configuration.
B) can’t it just pull the files directly from OCS to the access node?
See previous statement - Commvault effectively asks the Kubernetes scheduler to create a snapshot via the CSI sub-system.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
