> Essential

Protecting Kubernetes with Commvault

Commvault provides granular, application-centric, Kubernetes-native protection (backup and restore), application mobility (recovery and migration), and disaster recovery for containerized applications. Commvault protects Kubernetes data, including persistent volumes, for all CNCF-certified Kubernetes distributions.

Commvault has extensive support for Kubernetes applications, distributions, and storage:

Kubernetes_ovw

With the following Commvault features, you have the flexibility to use the Kubernetes distribution and deployment locations that are best for your organization and to scale and adjust technology and environments over time:

  • Flexibility in deployment:

    • Fully managed cloud services (Azure AKS, Amazon EKS, Google GKE)

    • Self-built on fully managed cloud infrastructures (Azure VM, Amazon EC2, Google VM)

    • Self-built on-premises

  • Auto-discovery and protection of Kubernetes applications by namespace or label selector—for integration between development and operations—or granular selection by name, label, or volume

  • Application-consistent snapshots of PersistentVolumes by using pre- and post-execution scripts, with scripts provided for common applications such as MySQL and PostgreSQL (supported only for on-premises access nodes)

  • An exception-based approach to data protection that uses SLA-based plans, artificial intelligence, and machine learning to automate backup, replication, and retention according to business policy

  • A multi-petabyte, scalable, distributed, modern architecture that protects all your Kubernetes clusters, regardless of location

  • A self-service administrative portal with single-sign on (SSO), role-based access controls (RBAC), and encryption

  • Fully programmable with REST APIs and extensive workflow engine for integration with orchestration systems and automated deployment practices

Backup and Restore

Data You Can Back Up

  • Kubernetes-orchestrated clusters, including namespaced and non-namespaced API resources and objects

  • Applications, which includes supported API resources/objects (such as Secrets, ConfigMaps, Namespaces, and StorageClasses) that can be listed, created, or re-created using the Kubernetes API server

  • Annotations on Pods, DaemonSets, Deployments, and StatefulSets

  • Helm chart-based applications, including helm configuration and annotations (supported only for on-premises access nodes)

  • Configuration-related volumes (configMap, downwardAPI, projected, secret)

  • Persistent storage objects (PersistentVolumeClaims, PersistentVolumes)

  • PersistentVolumeClaim volumes created from a VolumeSnapshotClass

  • Container image registries (containerized, virtualized)

  • etcd Kubernetes backing store and SSL certificates (on-premises environments and self-managed cloud environments only)

For detailed information about the resources that you can back up, see the following topics:

Data You Cannot Back Up

For more information about data you cannot back up, see Restrictions and Known Issues for Kubernetes.

Backups You Can Perform

  • Full backups

  • Incremental backups

Data You Cannot Restore

  • System namespaces (kube-system, kube-node-lease, kube-public) that have the overwrite option enabled

  • Namespaces that provide system-level shared services (such as ceph-rook, calico-apiserver, calico-system)

  • Out-of-place application or namespace recovery (another namespace, another cluster) of helm chart-deployed applications

  • Out-of-place application or namespace recovery to another Kubernetes cluster that is running a different major revision than the source cluster

  • Out-of-place application recovery with API resources/objects that have cluster-specific networking configuration (Endpoints, EndpointSlices, Services, Ingresses)

For more information about data you cannot restore, see Restrictions and Known Issues for Kubernetes.

Application Recovery and Migration

Restores You Can Perform

  • Restore a complete application to a previous point in time, to the original cluster or a different cluster

    You can restore an application out of place to any Kubernetes cluster that is added to Commvault, for application migration or disaster recovery. You can migrate Kubernetes applications between different Kubernetes distributions, clusters, and StorageClasses. Commvault requires the source and destination cluster to use the same major release of Kubernetes. For example, you can restore Kubernetes 1.23 to Kubernetes 1.23.

  • Restore application files to the following:

    • The original PersistentVolumeClaim

    • A different PersistentVolumeClaim

    • An access node file system (supported only for on-premises access nodes)

  • Restore application manifests to an access node file system (supported only for on-premises access nodes)

  • Restore a complete application with associated persistent data volumes to a different storage class, for a storage lifecycle, cluster consolidation, or cluster separation

  • Restore control plane etcd snapshot and SSL certificates (on-premises environments and self-managed cloud environments only)

Destinations You Can Back Up To

  • Cloud storage products (over 40 products, including Amazon S3, Azure Blob Storage, and products that are compatible with S3 and/or OpenStack Swift)

  • HyperScale X scale-out storage

  • Disk (block, file, object)

  • Tape

Disaster Recovery

  • Specify a cloud or on-premises DR site to store backups, with no need for a data center or infrastructure

  • Transfer DR backups between cloud providers or clusters, with deduplication and compression for reduced network egress charges

  • Recover your critical applications on demand

  • Perform scheduled replication of critical Kubernetes backups to off-site DR locations

  • Recover from control plane failures with etcd snapshot and SSL certificate recovery (on-premises environments and self-managed cloud environments only)

  • Recover from cluster-wide events with full cluster recovery and namespace recovery

Loading...