@Geoff Burke @Yongkang @patricio.rcm 

Hi Markus,

As far as I know, there isn’t such a comparison out there for both solutions.  Nevertheless, I’ve been reading a bit about Portworxs and I can see many features are similar to Kasten, but still there are features where Kasten is still a more complete solution, like:

• Kanister blueprints can be used in Kasten to provide consistent backups for data services like relational and no-relational databases.   Maybe I’m wrong but Portworx support here is much more limited.
• Kasten DR feature allows to recover the entire K8s cluster even if Kasten itself is broken after a disaster.  Again, I’m not aware of any similar feature in Portworx which is kind of important for your DR strategy.
• As you already have OpenShift in vSphere, if you eventually use vSphere CSI for PVCs, you can leverage Veeam Repositories also for Kubernetes backups.

If you are planning to migrate your apps to the cloud, or you are planning a hybrid strategy, including DR features, maybe Kasten could be more flexible.

Not sure about pricing, but I assume both can be competitive.

It is an interesting question. I am completely honestly to you. Both are great product having slightly different focus. You might notice Kasten is talking about #1 Kubernetes Backup with no hardware storage offerings while Portworx is touting #1 Kubernetes Storage with Backup as an Add-on. Since you’re an existing Veeam user, it makes more sense to go Kasten since it is now part of Veeam.

Having said that, if you decided to go with Portworx Storage, ask yourself the question, why not Portworx for Backup as well? Portworx will do anything they can to bundle the Backup together or even make the backup free for you. 

Talking about DR, apparently Portworx has a better story to tell but at huge additional cost. I would say if you’re willing to pay $$$ for a better DR solution, no doubt Portworx. If you’re looking for a better Backup solution, cost effective DR, Kasten is the way to go. 

I don’t believe this is comment is correct.

1. Kasten can offload any backup to a Veeam repo, regardless of the k8’s cluster CSI.
2. The vSphere CSI allows the K8’s cluster to dynamically provision new PV’s on the vSphere Datastores, and attach them to the correct K8s node (VM) where the Pod that needs the PV is running.
3. It is not recommended (or supported iirc) for VBR to protect a First Class Disk (VMDK created and used by a VM that is a K8s node), as VBR cannot interact with K8s to tell it, it is protecting the disk.

Point 1 + 2 do not rely on each other to be true, Point 3 is just for anyone considering using VBR to backup VMs that have dynamically attached VMDK files (due to K8s).

.If I happen to be wrong, or misunderstanding the point of the original comment here, please also let me know ]

Good Morning, 

Firstly there was a comment regarding replication and DR in comparison to Portworx (https://www.kasten.io/kubernetes/resources/blog/the-cost-of-zero-rpo-on-kubernetes) this blog post highlights some of the trade-offs whichever way you go. 

Regarding Dean's comment on the support for K10 to offload backups to a Veeam repository (https://docs.kasten.io/latest/usage/configuration.html?highlight=veeam#veeam-repository-location) 

From that link, you will see “A Veeam Repository can be used for exported vSphere CSI provisioned volume snapshot data when using a supported vSphere cluster. “ with additional links to what both refer to. 

Also, another consideration that has been mentioned is that we bring flexibility and freedom of choice with Kasten K10. We also integrate with the PortWorx Storage aspect as an Infrastructure Profile,

My argument here is I want my backups on a different storage to my production and I want this controlled separately as well

TIL

just my 2 cents: k10 does not support Openshift’s Object Bucket Claim, Portworx does (at least I have been told that by a salesman, I did not verify by myself)