Skip to main content
Version: Next

Back up stateful applications

The topics in this section include instructions for users on how to use pre and post backup rules with Portworx Backup to achieve application-consistent backups.

📄️ Back up Elasticsearch on Kubernetes

This topic provides a step-by-step guide for setting up application-consistent backups for Elasticsearch on Kubernetes using Portworx Backup. It explains how to create pre-exec and post-exec rules that ensure data integrity by performing Elasticsearch actions like freezing, flushing, and snapshotting the index before backup, and unfreezing it after backup. The process involves using the Elasticsearch internal snapshot API and storing backups in shared volumes.

📄️ Back up Jenkins on Kubernetes

This topic provides step-by-step instructions for creating pre-exec and post-exec backup rules with Portworx Backup to ensure application-consistent backups for Jenkins on Kubernetes. Jenkins stores critical data in the JENKINS_HOME directory, which contains configurations, jobs, plug-ins, and more. By setting up pre-exec and post-exec rules, users can ensure that important Jenkins jobs are stopped before and restarted after the backup, preventing any disruptions during the backup process.

📄️ Back up MongoDB on Kubernetes

This topic provides instructions on creating pre-exec and post-exec backup rules with Portworx Backup to take application-consistent backups for MongoDB on Kubernetes. It explains how MongoDB stores data in the dbPath, typically /var/lib/mongo, and the role of the MongoDB Oplog in database recovery. To ensure data consistency during backups, the topic guides users on how to use the db.fsyncLock() method to flush writes to disk and lock the database before the backup. It also includes steps for unlocking the database with db.fsyncUnlock() after the backup, and how to handle Oplog dumps for recovery.

📄️ Backup RabbitMQ on Kubernetes

This topic provides instructions for creating pre-exec and post-exec backup rules with Portworx Backup to take application-consistent backups for RabbitMQ on Kubernetes. RabbitMQ stores critical data in the `RABBITMQ_MNESIA_BASE` directory, typically located at `/var/lib/rabbitmq/mnesia`. The pre-exec rule exports RabbitMQ topology definitions and stops the application, while the post-exec rule starts the application after the backup is complete, ensuring a consistent and reliable backup process for RabbitMQ data and messages.

Was this page helpful?