Glossary

Air-gapped environments

An environment of Kubernetes clusters consisting of components such as nodes, load balancers, firewall, and other components of Portworx Backup that lie within the on-premises corporate network and physically isolated from external networks or public internet.

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.

For more information, refer to Create a backup.

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. A user can get information for any backup target for which they have READ access. They can either specify the name of the backup location for which they want to retrieve the details or get the information for all backup locations that they have access to. Backup locations are object stores or file stores you have added to Portworx Backup. 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. Similar to clusters, an administrator or user can create a backup location. The Portworx Backup server stores information about the create request in the Datastore.

For more information, refer to Configure a backup location.

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.

For more information on how to add clusters in Portworx Backup, refer to Add clusters.

FACD (FlashArray Cloud Drives)

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)

Volume level integration where Portworx creates a volume in the backend FlashArray for each incoming PersistentVolumeClaim (PVC) that user designates as FADA. Refer FADA configuration and supported FlashArray models for more information.

FBDA (FlashBlade Direct Access)

Volume-level integration where Portworx creates a volume in the backend FlashBlade for each incoming PersistentVolumeClaim (PVC) that user designates as FBDA. Refer this topic for more information.

Internet-connected hosts

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.

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

Self-owned cluster

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

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.

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 to pick the required projects and map their namespaces and resources to specific projects during restore.

For more information on restores, refer to Restore from a backup.

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.

For more information, refer to Create a backup rule.

Schedule Policies

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.

For more information, refer to Create schedule policies.