How to Set Up Reliable Kubernetes Backup & Restore Using Longhorn

Rounded avatar

Mohammad Madanipour

Jun 8, 2025
Header image

Why This Matters: Core Data Protection in Kubernetes

For any application running on Kubernetes, safeguarding data against loss and ensuring rapid recovery from disruptions are crucial. Businesses need to prevent data loss, maintain operational continuity, and often meet compliance mandates, all while managing complexity and cost. This guide demonstrates how Longhorn, an open-source, cloud-native storage solution, addresses these critical needs. By integrating directly with Kubernetes, Longhorn provides a reliable and cost-effective way to implement robust backup and restore strategies, empowering you to protect your stateful applications effectively.

Unlike many open-core or commercial options, Longhorn delivers essential features like snapshotting, backups, and restores — without licensing costs or vendor lock-in. In this guide, I’ll walk you through a hands-on backup and restore workflow using Longhorn — a practical setup you can adapt for your own Kubernetes workloads.

For this demonstration, we’ll use Wiki.js as the target application to protect.

We’ll go through the following steps:

  • Deploy Wiki.js in Kubernetes
  • Create a sample page inside Wiki.js
  • Perform a backup of its persistent volume using Longhorn
  • Delete the page from the application
  • Restore the volume from the backup to recover the deleted content

This process simulates a real-world disaster recovery use case using open-source tooling end-to-end.

Let’s begin.

Configuring the Backup Target

The first step in enabling backups with Longhorn is to configure a backup target, which typically points to an S3-compatible object storage service.

To define the target, use the following URI format:
s3://BUCKET_NAME@REGION/

Additionally, you must configure a Kubernetes Secret containing the credentials for accessing your backup target. This secret must reside within the longhorn-system namespace and should include three essential keys:

  • AWS_ACCESS_KEY_ID
  • AWS_ENDPOINTS
  • AWS_SECRET_ACCESS_KEY

longhorn-0.png

Creating a Demo Document in Wiki.js

Next, we will create a simple demo document in Wiki.js. This action simulates a real-world change to the application's data that we will later back up and then intentionally remove to test the restore process. The creation of this document is shown.

longhorn-1.png

Performing a Persistent Volume Backup

With our application data modified, we will now take a backup of the Wiki.js persistent volume. This backup will capture the state of the volume, including the newly created document.

Follow these steps within the Longhorn UI:

  • Navigate to the VOLUME tab.
  • Locate the persistent volume associated with your Wiki.js deployment and click on its name.
  • On the volume details page, click the CREATE BACKUP button.

This action initiates the backup process for the selected persistent volume.

As you can observe, the new backup has been successfully created and is ready for use.
You can verify the existence and details of your new backup by clicking on the BACKUP tab located at the top of the Longhorn UI.

longhorn-2.png

Simulating a Disaster: Deleting the Document

To simulate a data loss event or disaster scenario, we will now delete the document we created earlier within Wiki.js. This action confirms that the data is gone from the live application, setting the stage for our restore test. The deletion process is depicted.

longhorn-3.png

Preparing for Volume Restore

Before we can restore the persistent volume from our backup, we need to ensure that the existing volume is not in use by the application. In this scenario, the first necessary step is to delete the current Wiki.js database deployment and its corresponding PersistentVolumeClaim (PVC).

longhorn-4.png

After deleting the deployment and PVC, if you check the status of the volume in the Longhorn UI, you will notice its status has changed to DETACHED. At this point, it is safe and necessary to delete the detached volume, as shown.

Restoring the Volume from Backup

Now that the old volume is removed, we can proceed with restoring the volume from the backup we created earlier.

  • Navigate back to the BACKUP tab at the top of the page.
  • Find your previously created backup in the list.
  • Click on the OPERATION options associated with that backup and select Restore.

As shown, you will be prompted to specify a name for the restored volume. You have the option to provide a new name or use the previous volume name. For simplicity and to align with the previous PVC configuration, selecting Use previous name is often the most straightforward approach.

longhorn-6.png

Binding the Restored Volume to a PVC

Once the restore process is complete, you will have a new persistent volume created from the backup. The next step is to bind this newly restored PersistentVolume (PV) to a PersistentVolumeClaim (PVC) that your application can use.

  • Go back to the VOLUME tab and find your newly restored volume.
  • Select the restored volume.
  • Click on the CREATE PV/PVC option available for that volume.
  • As illustrated, choose USE PREVIOUS PVC to create a new PVC with the same name as the one used previously by the Wiki.js deployment.

Completing these steps will create a PVC with the correct name, automatically binding it to the restored PV.

longhorn-7.png

As the terminal output confirms, the new PVC with its previous name has been successfully created and bound to the restored Persistent Volume.

longhorn-8.png

Verifying the Successful Restore

With the PVC bound to the restored volume, you can now redeploy the Wiki.js database deployment. The deployment will automatically utilize the newly created PVC, which contains the data restored from the backup.

longhorn-9.png

Finally, let's return to the Wiki.js web interface to confirm that the document we previously deleted has been successfully restored. As shown, the document is present, signifying a successful backup and restore operation using Longhorn. Congratulations!

While visual confirmation of data restoration is crucial, a thorough verification often involves checking system and application logs to ensure everything is functioning as expected post-recovery. For a complete approach to monitoring your cluster's operations and diagnosing issues, consider implementing effective Kubernetes logging with Grafana Alloy and Loki, which can provide invaluable insights during and after recovery processes.

Need Help Implementing a Robust Kubernetes Backup Strategy?

Protecting your valuable data on Kubernetes with a reliable backup and restore solution like Longhorn is essential. While this guide provides a comprehensive walkthrough, we understand that every environment has unique challenges and requirements.

If you're looking to implement a resilient and cost-effective disaster recovery strategy for your Kubernetes workloads using Longhorn, or need assistance tailoring this solution to your specific needs, our team of DevOps experts is here to help.

Contact us today to discuss how we can help you safeguard your Kubernetes investments.