You can back up Kubernetes applications and application groups automatically or manually.
How Backups Work in Metallic
In Metallic, backups function as follows:
Initial, full backups: The first backup of an application is always a full backup.
Scheduled, incremental backups: The server plan that is assigned to an application group includes a schedule for incremental backups. You can recover application data, even when the most recent backup was incremental.
Manual backups: You can back up applications and application groups on demand.
If a backup cannot start, it is queued and will automatically resume when the blackout window, resource constraint, or network limitation is resolved.
Important: If you use Metallic to protect a Red Hat OpenShift environment as a hypervisor, migrate backups to Kubernetes in Metallic, so that you can back up and restore more data types.
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 backup gateways)
Persistent storage objects (PersistentVolumeClaims, PersistentVolumes), including CSI-enabled out-of-tree volume plug-ins
Container image registries (containerized, virtualized)
etcd Kubernetes backing store and SSL certificates (on-premises environments and self-managed cloud environments only)
Data You Cannot Back Up
Deprecated out-of-tree storage plug-ins (flexVolume)
Annotations on API resources/objects, excluding Pods, DaemonSets, Deployments, and StatefulSets
Kubernetes PKI certificates stored in /etc/kubernetes/pki
KubeVirt.io-managed virtual machines
Robin.io-bundled applications and metadata
Windows containers in Kubernetes