Organizations are increasingly relying on Kubernetes to run their production applications. In just the last 12–18 months, there has been a significant shift toward Kubernetes, and many are either now running Kubernetes in production or are planning to in the near future. As organizations begin the process of adopting the platform, many realize that their current data protection tools won’t meet their future business challenges, and they have turned to Portworx to help them navigate these turbulent waters and deliver the single solution that can help them with all their data management and data protection needs.

Portworx Backup is a leader in the Kubernetes data protection ecosystem already, but we aren’t stopping there. Portworx is continuously adding new features and enhancements to Portworx Backup that allow organizations to focus on their revenue-generating applications rather than building something in-house based on open-source components. As part of this continuous improvement and innovation cycle, Portworx released Portworx Backup 2.3, which enhances ease of use and offers more flexibility with pricing options.

In this blog, we will specifically focus on the Backup Sharing feature introduced in Portworx Backup 2.3. Depending on the size of your organization, you will either have developers who are responsible for managing their own applications and creating data protection policies for their applications, or you will have dedicated backup teams that are responsible for managing the data protection solution and ensuring that backups are scheduled to match the service level agreements (SLAs) various lines of business have jointly agreed on.

Regardless of who owns the responsibility of managing backups for production applications, you need your data protection solution to be flexible and secure enough that you can share access to backup snapshots without sharing user credentials between different users in your organization. With this latest release of Portworx Backup, we allow users to share the following types of access with individual users and groups:

  • View-Only Access: This allows other users or groups in your organization to have “Read Only” permissions for all the Kubernetes-native end-to-end application snapshots that you have created. Since this is a read-only role, users with this access can only look at all the backup snapshots that are shared with them without having the ability to restore from these snapshots or even delete an application snapshot. This role really comes in handy when you want the user to only have access for validation or monitoring perspective. For example, if you have an automated script to verify all components of an application have been protected, using this View-Only Role will prevent the script from accidental restore or deletions of the application backup, but could verify all contents within the backup.
  • Restore Access: This allows other users or groups in your organization to not only look at all the different application snapshots but also perform restore operations using these Kubernetes-native backup snapshots. This allows users to take an application snapshot and restore it to a completely different cluster if they want to. This is important in scenarios where the owner of a particular backup snapshot is unavailable to perform the restore operation or another user wants to create a copy of the application in a Dev/QA/staging environment for validation or troubleshooting purposes.

  • Full Access: This allows other users or groups in your organization to have full access to all the application snapshots. This not only allows them to view all the backup snapshots and restore from them if needed, but it also allows these users to delete backup snapshots if they want to. This might be helpful in scenarios where you have older snapshots you might not need anymore or where the original user has created more scheduled backups than needed to meet the SLAs. Since this role also has permission to delete backups, be careful when you are assigning this permission to other users in your organization.

You may wonder what happens if the permission a user is assigned on an individual basis is different from the level of permission the group that he/she belongs to is assigned. In such scenarios, Portworx Backup defers to the highest level of permission that is assigned to the user. Let’s take this scenario for example: If you assign a group “View Only” access but then assign the user within that group “Restore Access,” the user will have Restore Access. And if you assign the group “Restore Access” but a user within that group originally had “View Only” access, the user will now have “Restore Access” to the backup snapshot.

In addition to these different roles, with Portworx Backup, you can use one of the following two ways to share backup snapshots with other users or groups in your organization:

  • Individual Backup Snapshot: Using this method, you can have more granularity and select the exact backup snapshot you want to share with other users or groups in your organization. This is useful, for example, when you have an Object-Lock enabled backup snapshot that you want to share with other users in your organization, so in case of a security breach and a ransomware attack, other users in your organization can restore your application to the previously known good state using this immutable backup snapshot.

BackupSharing2

  • Cluster-Level Sharing: Using this method, users can share access to all existing and future backup snapshots created for applications running on a particular Kubernetes cluster. This is useful when you want to ensure that all the future scheduled backup snapshots are automatically shared with an application owner in your organization, for example. So, when it comes time to restore an application, they can select the latest backup snapshot to complete the restore operation.

BackupSharing3

Once you select either of these options, you will be asked to select an existing user or a group in your organization and the level of permissions you want to grant to the user or group. Then, you will need to hit Submit.

BackupSharing4

Once you share backups with a user, they can navigate to the Portworx Backup Dashboard and find all the shared backups under All Backups.

BackupSharing5

There might be scenarios where you might need to revoke shared permissions around backups or change the level of permission for specific users. Portworx Backup gives you an easy way to edit/delete the level of permission for a specific user or group: You just find the backup job and click the X mark in front of the user or group name.

BackupSharing6

This change will be immediately reflected, and the user will either be reassigned permissions or removed from the access list for a particular backup snapshot or the entire cluster-based snapshots.

Backup Sharing has been a feature that has been requested by many of our existing customers so they can enable cross-user backup snapshot sharing inside their organizations. We hope this feature not only helps our existing customers but also allows new users to start adopting a modern Kubernetes-based data protection solution like Portworx Backup.

If you want to see Backup Sharing in action, check out the YouTube demo below. If you want to try out this feature on your own Kubernetes cluster, start a free 30-day trial of Portworx Backup solution.

Share
Subscribe for Updates

About Us
Portworx is the leader in cloud native storage for containers.

Bhavin Shah

Bhavin Shah

Sr. Technical Marketing Manager | Cloud Native BU, Pure Storage
Explore Related Content:
  • backup
  • kubernetes
  • portworx
  • PX-Backup
link
Screen-Shot
September 15, 2022 Featured
Announcing Portworx Backup 2.3 for simpler backup management and flexible licensing
Janet Wi
Janet Wi
link
green
May 18, 2022 Featured
Fast and Simple Data Protection with Portworx Backup-as-a-Service
Janet Wi
Janet Wi
link
PX-Backup-1d
May 6, 2022 How To
How to protect Kubernetes from Ransomware attacks with PX-Backup
Ryan Wallner
Ryan Wallner