- Notes, cautions, and warnings
- Preface
- PowerProtect Data Manager for Kubernetes Overview
- Enabling the Kubernetes Cluster
- Managing Storage, Assets, and Protection for Kubernetes Clusters
- Restoring Kubernetes Namespaces and PVCs
- Best Practices and Troubleshooting for Kubernetes Clusters
- Configuration changes required for use of optimized data path and first class disks
- Recommendations and considerations when using a Kubernetes cluster
- Support Network File System (NFS) root squashing
- VM Direct protection engine overview
- Troubleshooting network setup issues
- Troubleshooting Kubernetes cluster issues
- Backups fail or hang on OpenShift after a new PowerProtect Data Manager installation or update from a 19.8 or earlier release
- Data protection operations for high availability Kubernetes cluster might fail when API server not configured to send ROOT certificate
- Kubernetes cluster on Amazon Elastic Kubernetes Service certificate considerations
- Removing PowerProtect Data Manager components from a Kubernetes cluster
- Increase the number of worker threads in Supervisor cluster backup-driver if Velero timeout occurs
- Velero pod backup and restore might fail if namespace being protected contains a large number of resources
- Pull images from Docker Hub as authenticated user if Docker pull limits reached
- Application-Consistent Database Backups in Kubernetes
- About application-consistent database backups in Kubernetes
- Obtain and deploy the CLI package
- About application templates
- Deploy application templates
- Perform application-consistent backups
- Verify application-consistent backups
- Disaster recovery considerations
- Granular-level recovery considerations
- Log truncation considerations
PowerProtect Data Manager 19.9 Kubernetes User Guide
Supported database applications
Supported applications include:
-
MySQL, in the following configurations:
- Standalone deployment in one pod.
- Cluster (primary/secondary) deployment with multiple StatefulSets or ReplicaSets. For example, through Helm.
- MongoDB, without shards.
-
PostgreSQL, in the following configurations:
- Standalone deployment in one pod.
- Cluster (primary/secondary) deployment with multiple StatefulSets. For example, through Helm.
- Cassandra, without shards.
Because data syncs from the primary pods to secondary pods, the PowerProtect Data Manager backs up secondary pods first.
NOTE This guide uses primary and secondary terminology. Some databases may use other terms, such as source and replica, primary and replica, or master and standby.
Please provide ratings (1-5 stars).
Please provide ratings (1-5 stars).
Please provide ratings (1-5 stars).
Please select whether the article was helpful or not.
Comments cannot contain these special characters: <>()\