Bnkr vs KubeSphere Backup

Bnkr is a free, open-source Kubernetes backup and migration application focused on valuable data inside a cluster rather than the whole cluster. It backs up files in Pods, Deployments, and StatefulSets, plus MySQL, MariaDB, PostgreSQL, and MongoDB databases. Schedules can run hourly, daily, weekly, monthly, yearly, or through a cron formula, and manual backup and restore are available. Email notifications report successful or failed backups and migrations to multiple recipients. Bnkr describes bidirectional migration of files and supported databases between Kubernetes, servers, and S3. The project runs as a single-binary web server and can be deployed in Kubernetes with a service account able to access backup data. Its README recommends the official image because some dependencies are external tools. Bnkr is available on the web or for self-hosting, uses the MIT license, and lists more than 20 themes. The free plan is listed at free, with no usage limit stated.

KubeSphere Backup is a cloud disaster-recovery service for hybrid-cloud Kubernetes environments. It backs up and recovers data across clusters, clouds, and Kubernetes versions, and supports different Kubernetes distributions and S3-standard object storage. CSI snapshot backup covers stateful applications such as MySQL, MongoDB, and Redis. Users create and run data-protection tasks through a web console without needing expertise in Kubernetes backup tools such as Velero. Listed uses include recovery from hardware or system failures, configuration errors, and improper operations, as well as multi-cluster protection and moving application data between clouds. The free plan covers 2 protected applications, 3 days of retention, and a 10 GB hosted repository. Basic costs $65 a month and includes 100 protected applications, 14 days of retention, and 100 GB of hosted repository. Direct cluster connection requires the Kubernetes API server address in kubeconfig to be reachable over the public network; agent connection is an alternative. The repository access domain must be compatible with AWS S3 standards. For Copy Volumes backups, the vendor advises disconnecting the database beforehand to preserve data consistency and integrity.