Schedule and Automate Postgres Backups on Kubernetes

What is the Postgres Database?

Postgres, also known as PostgreSQL, is a powerful open-source relational database that has been around for over 30 years. It has a strong reputation for reliability, scalability, and performance, which is why it is used by a wide range of organizations, from small businesses to large enterprises, across various industries. Whether you need to store and retrieve large amounts of data, run complex queries, or support business-critical applications, Postgres can handle it all.

Postgres is a transactional database, which means that it supports the ACID properties of Atomicity, Consistency, Isolation, and Durability. This makes it a great choice for applications that require high levels of data integrity and consistency. However, its use with these applications means that it is important to ensure Postgres backups and restores are in place in case of failures, user errors, or disasters. This is because any data loss or corruption can have a significant impact on the consistency and integrity of the database.

Considerations for Performing a Postgres Backup

When it comes to Postgres backup and recovery, it is important to perform application-consistent backups. This means that the Postgres backup process should capture the entire state of the Postgres database, including the data files and transaction logs, at a specific point in time. This ensures that the database can be fully restored to its exact state at the time of the backup, including all transactions that were completed. However, traditional file-level backups may not capture all completed transactions, and this can lead to data loss.

Postgres databases running on Kubernetes clusters require additional considerations for backup and recovery. These environments are dynamic, and the databases are often distributed across multiple nodes, making it challenging to perform Postgres backups and recoveries. Traditional backup solutions may not be well-suited for these environments, which is where CloudCasa’s Kubernetes Backup as a Service (BaaS) comes in. CloudCasa’s BaaS provides a simple, automated, and application-consistent backup solution for Postgres databases running on Kubernetes clusters. Let’s see how it leverages Kubernetes’ native capabilities to perform Postgres backups and recoveries, ensuring that the data is safe and can be quickly restored in case of any disaster.

PostgreSQL Server Setup in a Kubernetes Cluster

If you don’t already have Postgres installed, you can install a version of it for testing using the following process.

Note: We are using MiniKube for this demo, but CloudCasa supports nearly any Kubernetes distribution or managed Kubernetes services such as AKS, EKS, and GKE.

Let’s use Helm for the database creation. Helm is a package manager for Kubernetes that makes it easy to take applications and services that are either highly repeatable or used in multiple scenarios and deploy them to a typical K8s cluster.

Download the PostgreSQL Helm Chart locally.
Update the storageClass as csi-hostpath-sc in values.yaml. Please ensure that the relevant CSI driver is installed on the cluster.
Use helm install . –generate-name –create-namespace –namespace postgres to install PostgreSQL.
It will also provide you with further commands to access PostgreSQL Database.
While connecting with the database, make sure to change the restart parameter to Always.

CloudCasa Application Hooks

Application hooks or “App Hooks” is a feature of CloudCasa that allows users to execute custom code at specific points in the backup and restore process like pre-backup, post-restore etc. This can be useful for performing additional actions that are not supported out-of-the-box by CloudCasa, such as backing up non-Kubernetes resources or integrating with other tools and services.
When performing a backup, you can specify one or more commands to execute in a pod when that pod is being backed up. The commands can be configured to run before PVs are backed up (pre hooks), or after PVs are backed up (post hooks).

In this blog we will leverage it for taking an application consistent snapshot of PostgreSQL. Where the use case under consideration is to quiesce the database while the backup operation is in process. We can achieve this with a CloudCasa backup job by simply providing a pre-backup App hook that will automatically quiesce write operations, and a post-backup App hook that will resume write operations in PostgreSQL.

Using App hooks in CloudCasa is very simple, we can directly use the templates provided by default or we can customize them based on our needs with very little effort. Once defined, App Hooks can be referenced from backup or restore definitions. Refer to the blog on MySQL database backups on your Kubernetes Cluster using CloudCasa to learn more about the details of using App Hooks.

Installation of CloudCasa on the Kubernetes Cluster

Before we perform a backup, we need to install the CloudCasa agent on the Kubernetes cluster.

From the menu bar, go to Configuration > Clusters in the General section.
Click Add cluster + to open the Add cluster pane.
Fill in the required fields and click Register.
Install the agent using any of the supported methods. Automatic installation is available on several cloud platforms. Several methods for manual installation are also available.
After installing the agent, verify that the cluster is shown as Active in the CloudCasa UI before proceeding.

Taking a Postgres Backup

Let’s define a Kubernetes backup with App Hooks included.

Move to the Dashboard and click on Define Backup.
Enter a backup name, choose the cluster, and click on Next.
Choose either the full cluster or just the namespace that includes your Postgres database (postgres if you followed the installations instructions above), and toggle on the Include Persistent Volumes options.
Toggle the Enable App Hooks option if you are using App Hook.
Click on Next, Next and again click on Next.
Enter the retention days as per your need, toggle Run Now on and click on Create.

Tracking Postgres Backup Status

You can track the Postgres Backup Activity in the Activity Panel of the Dashboard. You will be able to get the activity details and logs by clicking on the Job name.

That’s it. We now have a successful Postgres backup! You can also find the processLogs.txt file in your environment.

**Fun Fact: Post in PostgreSQL refers to Postgres, which was the name of the original database management system developed at the University of California, Berkeley. The name Postgres itself was derived from the project’s origins as a successor to the Ingres database management system.

Simulating PostgreSQL Data Loss

There are several common causes of data loss with PostgreSQL on Kubernetes. These include power failures, hardware failures, and software bugs. Other potential causes of data loss include user errors, such as accidental deletion of important data, and security breaches, such as cyberattacks.
In our example, let’s delete some rows from the table to demonstrate a data loss event:

As we can see, we no longer have the row (user2, pwd2) in our table.

Restoring Data From the Postgres Backup

Let’s try to restore the lost data.

On the Dashboard, find the Postgres Backup Job you just created. Click on Restore.
Choose the Recovery Point from the panel. Click on Next.

3. Select Namespace and click Next.

4. We can also create a new cluster or namespace with the restore and Click Next.

5. To create a new namespace, click on Rename namespaces, add a preferred prefix/suffix or set new name and Click Next. You can now add App-hooks as per your requirement and then click on Next.

6. Provide a Job name for the restore and click on Restore.

7. You can track the restore progress in the Activity panel in the dashboard.

8. Let’s check if we have our deleted data back.
Note: As we had chosen to restore the data in a new namespace, we need to track down the new namespace(restored-postgres).
We will exec the client postgresql pod of the new namespace with the same credentials of the one we backed up as shown below.

9. We can see from the above screenshot that the deleted rows are back with us from the Postgres backup.

It’s That Simple

We just saw how easy and straightforward it is to do a Postgres backup and restore to protect your Kubernetes databases using CloudCasa. This is just a fraction of what CloudCasa does.
Indeed, CloudCasa is a powerful and easy-to-use Kubernetes backup service for DevOps, Platform Engineering, and IT Ops teams, that is fully integrated with Azure Kubernetes Service (AKS), Amazon EKS (Elastic Kubernetes Service), and Google Kubernetes Engine (GKE), as well as supporting all other major distributions and managed services and provides several amazing features like auto-scaling and multi-cloud Kubernetes backup and Any2Cloud recovery. CloudCasa pushes the boundaries of traditional data protection by offering both a free SaaS plan, SaaS Pro plans, and self-hosted options.

Resources

Support