Skip to main content
Version: 2.9

Glossary

3-2-1 backup strategy​

The 3-2-1 backup strategy is a best practice backup approach that recommends keeping 3 copies of data, on 2 different types of media, with 1 copy stored offsite. Portworx Backup supports this strategy by allowing you to create multiple backup copies across different storage locations and media types.

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 want to reside, when your backups should run and determine how those backups 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 some actions before or after a backup occur 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.

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 Portworx cloud drive layer communicates with the FlashArray to provision and manage disks used for our storage pools. In other words, this forms our 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. Refer to 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 user designates as FBDA. Refer to Pure reference for more details.

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.

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 the kdmp-config ConfigMap

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.

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 has not created or own or 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 cloud-based S3 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 PXB 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 for restore operation. Default restore option allows us to choose the source and destination cluster for restoring the backup, but this option does not provide the option to choose namespace, storageclass or projects to restore the backup.

Custom restore​

Besides allowing the user to choose the required source and destination cluster, this option allows the user to even select the custom namespaces, storageclasses and projects (only for Rancher clusters) of the destination cluster to restore the backups onto them.

Storageclass mapping​

During restore, you can choose a storage class that is different from the original storage class with which the PVC was created. The 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 storageclass.

Namespace mapping​

Allows you to map the source namespace (namespace that holds the data that you want to restore) and the destination namespace (where you want to restore your data)

Project mapping​

You can also map a source cluster project with that of the destination cluster for custom restores for selected cluster types. This project mapping facilitates picking 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 help to pause or freeze the IO operations before creation of backup to ensure that the data being backed up is consistent. In other words, rules help to take application-consistent backup in production environments. Backup rules are further classified into pre-exec and post-exec rules to run before and after creation of backup respectively. Rules can either run on a single pod or on all pods associated with your application. You can create rules to perform a single task or a bunch of tasks to be executed before and after taking backup. For example, for Cassandra, you can create a custom flush, compaction, or verify rule to ensure a healthy and consistent dataset before and after a backup occurs. Use rules to create commands which run before or after a backup operation is performed. After creating rules, these rules should be associated with the required backup.

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 help to automate the creation of backups by scheduling your backups to run at stipulated time or 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 amount 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.

Self-owned cluster​

A self-owned cluster is a group of nodes that a user creates, manages, maintains controls and owns completely.

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 PXB 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.

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.

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.