NetBackup™ for Kubernetes Administrator's Guide
- Overview of NetBackup for Kubernetes
- Deploying and configuring the NetBackup Kubernetes operator
- Configure settings for NetBackup snapshot operation
- Deploying certificates on NetBackup Kubernetes operator
- Managing Kubernetes assets
- Managing Kubernetes intelligent groups
- Managing Kubernetes policies
- Protecting Kubernetes assets
- Managing image groups
- Protecting Rancher managed clusters in NetBackup
- Recovering Kubernetes assets
- About incremental backup and restore
- Enabling accelerator based backup
- Enabling FIPS mode in Kubernetes
- About Openshift Virtualization support
- Troubleshooting Kubernetes issues
About NetBackup Accelerator support for Kubernetes workloads
NetBackup Accelerator reduces the backup time for Kubernetes cluster backups.
For Kubernetes backups, the Accelerator feature is activated when you select a storage type that supports Accelerator. For example, MSDP, OpenStorage, CloudStorage, and MSDP-C (Azure and AWS), and Kubernetes clusters that support Accelerator-enabled backups.
Note:
Accelerator enabled backup is supported only for the file mode PVCs.
The NetBackup Kubernetes Operator values.yaml
has an entry acceleratorTracklogPvcStorageClass: None
To enable Accelerator, specify a valid storage class name to generate the track logs for Accelerator backups. Storage class helps to create a file mode volume which is usable on any of the worker nodes within the Kubernetes cluster.
Note:
If the acceleratorTracklogPvcStorageClass is set to None and an Accelerator-enabled storage is selected, then the Accelerator backup jobs do not run. After upgrade to NetBackup 10.4 release, the default value of acceleratorTracklogPvcStorageClass is None.
For more details, refer to the Validating accelerator storage classsection in the NetBackup for Kubernetes Administrator's Guide.
The default value for the number of Backup from Snapshot jobs per Kubernetes cluster is 4.
If 4 Backup from Snapshot jobs with Accelerator run to back up 4 PVCs simultaneously, these jobs consume some storage.
As per this calculation, each PVC requires some space for track log creation. Track log size in Bytes = 2*((Number of files in PVC * 200) + ((Total used disk space in PVC KiB/128KiB) * 20))
The storage that is required to run 4 Backup from Snapshot jobs simultaneously = Sum of track log size of 4 PVCs.
Therefore, the storage requirement changes if the number of Backup from Snapshot jobs per Kubernetes cluster is changed.
Ensure that a sufficient storage is available before running the backups jobs. To avoid storage issues, elastic storage can be used.
NetBackup Accelerator creates the backup stream as follows:
If the namespace has no previous backup, NetBackup performs a full backup.
For the next backup job, NetBackup identifies data that is changed since the previous backup. Only the changed blocks and the header information are included in the backup, to create a full backup.
Once the backup is done, bpbkar on the data mover updates the track log. Track log path inside data mover - usr/openv/netbackup/track/<primary server>/<storage server>/<k8s cluster name>_<namespace uuid>_<pvc uuid>/<policy>/<backup selection>
This track log is then transferred to primary server in the inline style at the following location:
/usr/openv/netbackup/db/track/<primary server>/<storage server>/<k8s cluster name>_<namespace uuid>_<pvc uuid>/<policy>/<backup selection>
When the next Accelerator backup job is initiated, the track log is fetched from the primary server to identify the changed files. Then it is updated with the new content and transferred back to the primary server.