Glossary
3-2-1 backup strategy
The 3-2-1 backup strategy is a data protection best practice that recommends keeping 3 copies of data, on 2 different types of storage media, with 1 copy stored offsite. Portworx Backup supports this strategy through CSI local snapshots combined with KDMP offload to a backup location, producing three distinct copies of your data across two media types with one offsite copy.
Active Directory
Active Directory is Microsoft's directory service for Windows domain networks. Portworx Backup can integrate with Active Directory through LDAP or OIDC protocols to enable user authentication and group-based access control.
Air-gapped environments
An air-gapped environment consists of Kubernetes clusters with components such as nodes, load balancers, firewall, and other components of Portworx Backup that lie within the on-premises corporate network and are physically isolated from external networks or public internet.
Application-consistent backup
An application-consistent backup is a backup that captures data in a consistent state where all application transactions are completed and the application is in a stable state. This is achieved by using pre-exec and post-exec rules to quiesce the application before the backup and resume it afterward, ensuring that the backup can be restored without data corruption or inconsistency.
Auto-delete after retention period
Auto-delete after retention period is a feature that automatically removes backups once their retention period expires. This feature is mandatory for locked schedule policies associated with object lock enabled backups and helps maintain compliance with data retention policies.
Backup locations
Backup locations specify the target where a replica of applications is created and acts as a registry. Backup locations are object stores or NFS shares (both on-premises and cloud-based shares) you have added to Portworx Backup. These object stores can reside on private or public cloud environments. Similar to clusters, an admin or a user can create a backup location and the creator becomes the owner. Portworx Backup stores backups on any compatible object store or NFS-based backup locations based on the below cloud providers:
- AWS S3 or compatible object stores
- Azure Blob Storage
- Google Cloud Storage
A backup location is not tied to any particular cluster, and can be used to trigger backups and restores on any cluster.
Backup sharing
Backup sharing is a feature that enables users to share backups with other users or groups, granting them specific access permissions. Users can share individual backups or all backups associated with a cluster. When sharing a single backup, the collaborator gains access only to that specific backup. When sharing all backups in a cluster, the collaborator can access both existing and future backups of that cluster.
Backups
Backups in Portworx Backup contain replica images and configuration data of the protected namespaces and applications. Before backing up your namespaces, you need to determine where your backups will reside, when they should run, and how they should occur. You can either create a manual backup or automate your backups with schedule policies. You can attach schedule policies to run them at designated times and keep a designated amount of rolling backups, and attach pre-exec and post-exec rules to perform actions before or after a backup for application-consistent data.
Cloud credentials
Cloud credentials are authentication credentials required to access cloud storage providers for backup locations. These credentials allow Portworx Backup to authenticate with cloud providers such as AWS, Azure, Google Cloud, and others to store and retrieve backup data. Cloud credentials are securely stored and managed within Portworx Backup.
Classic mode
Classic mode is the default Portworx Backup operation mode in which the central Portworx Backup server maintains direct connectivity to all application clusters and backup locations. In Classic mode, cloud credentials are stored centrally on the Portworx Backup server, and all backup operations — execution, deletion, sync, and validation — are orchestrated by the server and executed through Stork on application clusters. Classic mode supports all certified Kubernetes distributions and all backup location types (Azure Blob, GCP, AWS S3, and NFS). For a comparison with Federated mode, see Operation Modes.
Clusters
A Kubernetes cluster comprises a group of nodes that host containerized applications. Portworx Backup allows you to add different types of clusters from the web console to take backup of data from that cluster or to restore backup data onto that cluster.
Collaborator
A collaborator is a user to whom a Portworx Backup resource (such as a backup, cluster, or backup location) has been shared. Collaborators receive specific access permissions (read-only, restore-only, or full access) to the shared resources based on the sharing configuration set by the resource owner.
Crash-consistent backup
A crash-consistent backup is a point-in-time copy of data that reflects the disk state after an unexpected shutdown, without application-level coordination. This type of backup does not use pre-exec or post-exec rules and may require application recovery procedures upon restore.
Cross-cloud backup
Cross-cloud backup (also referred to as direct KDMP backup) is a backup type where Portworx Backup utilizes the KDMP driver to create backups that can be restored across different cloud environments. This backup type allows you to back up namespaces or VMs from one cloud provider and restore them to a different cloud provider, enabling cloud migration and disaster recovery scenarios across heterogeneous cloud environments.
CSI (Container Storage Interface)
Container Storage Interface (CSI) is a standard for exposing arbitrary block and file storage systems to containerized workloads on Kubernetes. CSI enables storage vendors to develop plugins that work across different container orchestration systems. In Portworx Backup, CSI drivers are used to create local snapshots on storage arrays, which can then be offloaded to backup locations using the KDMP driver.
Entra ID (Azure AD)
Entra ID (formerly known as Azure Active Directory or Azure AD) is Microsoft's cloud-based identity and access management service. Portworx Backup supports integration with Entra ID as an OIDC provider for Single Sign-On (SSO), enabling users to authenticate using their Azure AD credentials.
Extent-based snapshots
Extent-based snapshots are a Portworx-specific snapshot mechanism where Portworx compares block metadata (called extents) to determine the difference between the local snapshot and the previously uploaded cloud snapshot. This approach reduces the footprint of locally stored cloud snapshot data by uploading only changed blocks and metadata.
FACD (FlashArray Cloud Drives)
FACD (FlashArray Cloud Drives) is a cloud drive integration where the Portworx cloud drive layer communicates with the FlashArray to provision and manage disks used for storage pools, forming the backend disks and pools.
FADA (FlashArray Direct Access)
FADA (FlashArray Direct Access) is a volume level integration where Portworx creates a volume in the backend FlashArray for each incoming PersistentVolumeClaim (PVC) that user designates as FADA. See FADA configuration for more details.
FBDA (FlashBlade Direct Access)
FBDA (FlashBlade Direct Access) is a volume-level integration where Portworx creates a volume in the backend FlashBlade for each incoming PersistentVolumeClaim (PVC) that a user designates as FBDA. For information on using FlashBlade as an NFS backup storage location in Portworx Backup, see Backup and Restore with FlashBlade.
Federated mode
Federated mode (also referred to as Managed Service Provider mode or Workload Identity mode) is a Portworx Backup operation mode designed for service providers and managed platform environments such as Gardener.
In this mode, the Portworx Backup server is deployed on a dedicated Kubernetes cluster (backup cluster) and does not run backup operations directly. Instead, it sends instructions to Stork, and all backup tasks—creation, deletion, sync, and validation—are handled locally by Stork on each application (shoot) cluster.
Cloud credentials are not stored centrally. Each application cluster uses Azure Managed Identity to authenticate directly with Azure Blob Storage.
Full backups
Full backups are complete backups that capture all data in the selected namespaces or volumes, regardless of previous backups. Full backups serve as baseline backups and are typically followed by incremental backups to optimize storage and performance.
Garden Linux
Garden Linux is a Debian-based Linux distribution used in Gardener Kubernetes environments. It serves as the host operating system for nodes in Gardener-managed shoot clusters. Portworx Backup Federated mode is validated on Garden Linux as part of its support for Gardener deployments.
Gardener
Gardener is an open-source Kubernetes management platform designed for operating and scaling large numbers of Kubernetes clusters across multiple cloud providers. Gardener manages many application clusters (shoot clusters), each representing a customer or tenant workload environment. Portworx Backup Federated mode integrates with the Gardener API to automatically discover and onboard shoot clusters without manual kubeconfig import. For more information, see Manage Gardener Clusters (Federated mode).
Gardener cluster configuration
In Portworx Backup Federated mode, a Gardener cluster configuration refers to the per-cluster settings stored in Portworx Backup for each onboarded Shoot cluster. This includes the assigned backup location, Stork status, and cluster-specific operational options. Each Shoot cluster has a dedicated Cluster Configurations page in the Portworx Backup web console where administrators can view and manage these settings. Unlike Classic mode, where cluster configuration involves a kubeconfig and cloud credentials, Federated mode cluster configuration is managed declaratively through Custom Resources (CRs) pushed to the Shoot cluster by the Portworx Backup server.
Incremental backups
Incremental backups are backups that only capture the changes made since the last backup (either full or incremental). This backup strategy reduces storage space requirements and backup time by avoiding duplication of unchanged data. For Portworx volumes, you can specify the number of incremental backups between two full backups when creating schedule policies.
Internet-connected hosts
Internet-connected hosts refer to a cluster consisting of a node where Portworx Backup is installed and the other clusters of the complete Kubernetes environment physically connected to the public internet.
Job pods
Job pods are Kubernetes pods created by Job controllers to complete finite tasks successfully. In Portworx Backup, job pods are used across both the backup cluster and application clusters to perform various operations including backups, restores, pre-install hooks, post-install hooks, and maintenance tasks. These pods run once and exit after completing their designated tasks.
KDMP backup
KDMP backups are generic backups that Portworx Backup supports utilizing the KDMP driver. Here are few trigger scenarios of KDMP backup:
- Portworx Backup without Portworx Enterprise or a storage system that does not support CSI snapshots
- Portworx Backup and storage system that supports CSI snapshots, if you want to offload the backup to S3 along with the selection of volume snapshot class during creation of backup
- Regardless of the CSI snapshot support by the storage system, if the user updates the parameter
BACKUP_TYPE: "Generic"in thekdmp-configConfigMap
Keycloak
Keycloak is an open-source identity and access management solution that provides user federation, identity brokering, and social login capabilities. Portworx Backup uses Keycloak for managing user authentication, authorization, and integration with external identity providers like LDAP, Active Directory, and OIDC providers.
KubeVirt
KubeVirt is a Virtual Machine management add-on that provides a unified platform for VM workloads in the Kubernetes environment. It allows VMs to run parallel with containers on Kubernetes, OpenShift, and other environments. With KubeVirt, you can run VM workloads and Kubernetes native workloads without requiring additional management tools or dedicated pipelines. Portworx Backup supports backing up and restoring KubeVirt Virtual Machines running on Kubernetes clusters.
LDAP (Lightweight Directory Access Protocol)
LDAP (Lightweight Directory Access Protocol) is a protocol used to access and manage directory information services over a network. In Portworx Backup, LDAP is used as a central identity provider for user authentication and group management. Both Rancher and Portworx Backup can be integrated with LDAP to provide consistent user and group data for access control and RBAC enforcement.
Locked schedule policy
A locked schedule policy is a schedule policy designed for object lock enabled backups that automatically deletes backups after the retention period expires. When creating a locked schedule policy, the auto-delete after retention period option is enabled by default, while the retain and incremental count options are disabled to ensure compliance with object lock requirements.
Managed cluster (Gardener)
A managed cluster is a shoot cluster that is actively tracked and lifecycle-managed by a Gardener cluster configuration in Portworx Backup Federated mode. A shoot cluster is in the managed state when it has been discovered through the Gardener API and its Kubernetes labels match the label filter configured in the Gardener cluster configuration. Portworx Backup includes managed clusters in Auto Sync cycles, newly created clusters whose labels match the filter are added, and clusters that no longer exist in Gardener are removed. For more information, see Cluster states.
NFS (Network File System)
NFS (Network File System) is a distributed file system protocol that allows users to access files over a network as if they were on local storage. Portworx Backup supports NFS-based backup locations as an alternative to object storage, enabling backups to be stored on NFS shares both on-premises and in cloud environments.
Non-owned cluster
A non-owned cluster is a group of nodes that a user uses but did not create and does not own, manage, or fully control.
Non-RBAC resources
Non-RBAC resources in Portworx Backup include clusters, namespaces, virtual machines, backups, and restores. These resources are not governed by role-based access control in the same way as RBAC resources, but can still be shared with specific users or groups.
Object lock
Object lock is a security feature for compliant object store backup locations that prevents backups from being deleted or modified for a specified retention period. This feature helps secure critical data by implementing Write-Once-Read-Many (WORM) protection, ensuring compliance with regulatory requirements and protecting against accidental or malicious deletion.
OIDC (OpenID Connect)
OIDC (OpenID Connect) is an authentication protocol built on top of OAuth 2.0 that allows clients to verify the identity of users based on authentication performed by an authorization server. Portworx Backup supports OIDC integration for Single Sign-On (SSO) with identity providers like Azure AD (Entra ID), enabling secure user authentication.
Owner
An owner is the user who created a Portworx Backup resource. The owner has full control over the resource and can share it with other users, modify it, or delete it. Ownership is automatically assigned to the user who creates the resource.
Parallel backup schedules
Parallel backup schedules is a feature that ensures scheduled backups happen consistently at every scheduled interval, even when a prior backup process is still in progress. This feature is designed to address scenarios where larger volumes or limited bandwidth cause delays, leading to schedule violations. It applies specifically to backups containing only Portworx volumes where all snapshots are completed within the backup interval, allowing the next backup to start even if the previous backup is still uploading.
Post-exec rules
Post-exec rules are backup rules that run after a backup operation is performed. These rules help to resume or unfreeze IO operations after creation of backup. Post-exec rules are used to restore normal application operations after the backup process completes by executing commands or scripts.
Pre-exec rules
Pre-exec rules are backup rules that run before a backup operation is performed. These rules help to pause or freeze IO operations before creation of backup to ensure that the data being backed up is consistent. Pre-exec rules are used to take application-consistent backups in production environments by executing commands or scripts before the backup process begins.
Proxy support
Proxy support in Portworx Backup enables deployment and operation in proxy-enabled Kubernetes cluster environments where all external communication must pass through an HTTP/HTTPS proxy server. This feature allows Portworx Backup components and job pods to route external communication such as backup uploads, registry access, and SMTP alerts through a designated proxy. Proxy settings can be configured using Helm values directly or via a Kubernetes Secret for secure handling of credentials and custom CA certificates.
Rancher projects
Rancher projects are organizational units in the Rancher management cluster that group multiple Kubernetes namespaces together. Each project can have multiple namespaces associated with it and provides a way to manage access control and resource quotas across related namespaces. In Portworx Backup, Rancher projects can be mapped to LDAP groups to control namespace visibility based on user permissions.
RBAC resources
RBAC (Role-Based Access Control) resources in Portworx Backup include backup locations, cloud accounts, schedule policies, rules, roles, users, and user groups. These resources can be shared with collaborators and are managed through role-based permissions to control access across the organization.
Restores
Restore your backups to the original cluster or different clusters, replace applications on the original cluster or restore to a new namespace. Perform partial restores to selected namespaces from the backup.
Default restore
This is the default behavior for Portworx Backup restore operations. The default restore option allows you to choose the source and destination cluster for restoring the backup, but does not provide the option to choose a namespace, storage class, or projects to restore the backup to.
Custom restore
In addition to allowing you to choose the required source and destination cluster, this option also lets you select custom namespaces, storage classes, and projects (only for Rancher clusters) on the destination cluster to restore backups to.
Storage class mapping
During restore, you can choose a storage class that is different from the original storage class with which the PVC was created. Storage class mappings allow you to choose a specific storage class to restore the PVC. Based on the storage class of the backed-up PVC and the type of backup taken, Portworx Backup populates the destination storage class.
Namespace mapping
Maps the source namespace (the namespace that holds the data you want to restore) to the destination namespace (where you want to restore your data).
Project mapping
You can also map a source cluster project to a destination cluster project for custom restores on selected cluster types. This project mapping lets you pick the required projects and map their namespaces and resources to specific projects during restore.
Retention period
Retention period is the duration for which backups are kept before being eligible for deletion. In Portworx Backup, you can configure retention periods in schedule policies to automatically manage backup lifecycle. For object lock enabled backups, the retention period determines when backups are automatically deleted.
Rules
Backup rules are scripts or commands that run before or after a backup operation to ensure data consistency. Rules are classified into pre-exec rules (run before backup to pause IO) and post-exec rules (run after backup to resume normal operations). Rules can target a single pod or all pods in an application. After creating a rule, it must be associated with the required backup. For more information, see Pre-exec rules and Post-exec rules.
S3-compatible object store
S3-compatible object store refers to any storage system that implements the Amazon S3 API, allowing it to work with tools and applications designed for S3. Portworx Backup supports various S3-compatible object stores including AWS S3, MinIO, Dell ECS, and others as backup locations.
Schedule policies
Schedule policies automate the creation of backups by scheduling them to run at a stipulated time or on a specific schedule. You can create schedule policies and attach them to backups of namespaces to run them at designated times and keep a designated number of rolling backups. Portworx Backup provides the option to create backups at periodic intervals, every day, every week, or every month, and allows you to choose the required timings for these options. You can choose the number of concurrent backups to be retained during the creation of schedule policies and also specify the number of incremental backups between two full backups for Portworx volumes.
Secret-less architecture
Secret-less architecture is the security model used in Portworx Backup Federated mode. In this model, cloud credentials — such as Azure storage account keys or access tokens — are never stored on the central Portworx Backup server. Instead, each Shoot cluster authenticates directly to its assigned backup location using Workload Identity (Azure Managed Identity in this release). This ensures that even if the central server is compromised, no cloud credentials are exposed. Secret-less architecture is a key design principle that differentiates Federated mode from Classic mode.
Self-owned cluster
A self-owned cluster is a group of nodes that a user creates, manages, maintains, and owns completely.
Shoot cluster
A shoot cluster is a Gardener-managed application cluster (also called a tenant cluster) that represents a customer or workload environment in a Gardener deployment. In Portworx Backup Federated mode, shoot clusters are the application clusters managed by the Portworx Backup server for backup and restore operations. Each shoot cluster runs a Stork agent that picks up Custom Resources (CRs) pushed by the Portworx Backup server and executes all backup operations locally, including backup execution, deletion, sync, and validation, without any direct execution by the central server. Shoot clusters are onboarded to Portworx Backup automatically through the Gardener API; no manual kubeconfig import is required. For more information, see Manage Gardener Clusters.
Snapshot class mapping
Snapshot class mapping is a feature that allows you to map storage provisioners to volume snapshot classes during backup creation. This mapping controls how CSI snapshots are created and enables you to offload local snapshots to backup locations. Snapshot class mapping is particularly useful for non-Portworx provisioners and CSI-based storage systems.
SSO (Single Sign-On)
Single Sign-On (SSO) is an authentication method that allows users to access multiple applications with a single set of credentials. Portworx Backup supports SSO integration with various identity providers including OIDC, SAML, LDAP, and Active Directory, enabling seamless authentication across enterprise systems.
Stork
Stork (STorage Orchestrator Runtime for Kubernetes) is an intelligent storage orchestrator for Kubernetes and a cloud native storage operator runtime scheduler plugin. Stork is one of the major components of Portworx Backup and translates decisions of a scheduler orchestration system in such a way that an external cloud native storage solution can act upon. By doing so, Stork extends Kubernetes capabilities with the help of the underlying storage provider, making it more stateful aware. Stork acts as an abstraction layer between the underlying storage provider and Portworx Backup, enabling it to trigger and execute backups and restores on target clusters, push Kubernetes resources to configured object storage locations, and integrate with storage providers for taking snapshots.
Super administrator
A Super Administrator (super admin) in Portworx Backup is a role with extensive privileges designed to provide unified control over all backup-related resources within a Portworx Backup deployment. This role grants the ability to manage clusters, namespaces, cloud accounts, backups, restores, and more, regardless of the user who created them. Super admin has visibility and full access to all Portworx Backup resources including clusters, namespaces, virtual machines, cloud accounts, backup locations, schedule policies, schedules, backup rules, backups, and restores.
Unlocked schedule policy
An unlocked schedule policy is a standard schedule policy that allows you to configure retention settings, incremental backup counts, and other scheduling options without object lock constraints. This is the default policy type for regular backup scheduling operations.
Unmanaged cluster (Gardener)
An unmanaged cluster is a shoot cluster that was previously discovered and onboarded through a Gardener cluster configuration in Portworx Backup Federated mode, but whose Kubernetes labels no longer match the Gardener cluster configuration label filter.
When Auto Sync is enabled, Portworx Backup periodically checks cluster labels. If the labels of a shoot cluster are changed or removed, the cluster is marked as Unmanaged.
Unmanaged clusters remain visible in the Portworx Backup web console but are no longer managed by the Gardener cluster configuration. You can remove them manually from the Clusters > All Clusters page.
A shoot cluster that no longer exists in Gardener is deleted from Portworx Backup entirely. It is not marked as Unmanaged. Backups already stored in the backup location are retained in both cases.
For more information, see Cluster states.
User federation
User Federation in Keycloak is a feature that allows Keycloak to connect to external user directories like LDAP or Active Directory. This enables Portworx Backup to authenticate users against existing corporate directory services without requiring separate user accounts.
VolumeBlock mode
VolumeBlock mode is a Portworx Enterprise volume configuration where a persistent volume is exposed to a pod as a raw block device (that is, volumeMode: Block in the PersistentVolumeClaim spec) rather than as a mounted file system. In Portworx Backup, VolumeBlock mode is used with the extent-based snapshot mechanism for Portworx cloud snapshots. Portworx Backup currently supports VolumeBlock mode only on Portworx Enterprise.
Volume snapshot class (VSC)
Volume Snapshot Class (VSC) is a Kubernetes resource that defines how volume snapshots are created by a CSI driver. It specifies the snapshot provisioner and parameters for creating snapshots. In Portworx Backup, you can map storage provisioners to volume snapshot classes during backup creation to control how snapshots are taken and stored.
Workload identity
Workload Identity is the authentication mechanism used in Portworx Backup Federated mode to allow Stork on each Shoot cluster to authenticate directly to a cloud backup location without storing credentials centrally. Instead of using explicit cloud credentials (such as access keys or service account JSON files), Workload Identity binds a cloud identity to the Stork Kubernetes service account, enabling token-based authentication scoped to the cluster. In this release, Portworx Backup Federated mode supports Azure Managed Identity (MI) as the Workload Identity mechanism. Azure Managed Identity is provisioned per Shoot cluster and annotated on the Stork service account, granting it the permissions needed to read and write to the designated Azure Blob Storage backup location. For more information, see Configure Backup Locations in Federated Mode.