Moodle Storage Migration to Longhorn¶

Overview¶

Moodle Storage Migration to Longhorn shows how HybridOps moves a stateful workload from a fragile, node pinned storage posture to managed cluster storage with an automated backup path, without taking the service offline.

The source was a hostPath volume fixed to a single control plane node. The target is a Longhorn-managed PVC that can be inspected through the Longhorn UI, backed up automatically to GCS, and operated through the same cluster storage layer as the rest of the platform.

Case study¶

Context: Moodle data was stored on a hostPath PV pinned to rke2-cp-03. There was no replication, no backup path, and no tolerance for node loss; a single node failure would have taken the Academy LMS offline permanently.
Challenge: migrating a live stateful workload to managed cluster storage without taking the service offline and without risking data loss during the transfer window.
Approach: the Longhorn PVC (education-moodle-data, storageClass: longhorn-moodle, 20Gi RWO) was created and bound before the migration window. A one-shot rsync pod transferred data from the hostPath source to the new volume. The Moodle deployment was updated to reference the new PVC and Argo CD reconciled the state.
Outcome: the recorded migration bound the PVC through Longhorn and moved the service off the node pinned hostPath lane. Backup to hyops-dev-longhorn-backups-gcp03-a1 was verified, the login smoke test confirmed the service with migrated data, and the migration completed without data loss or extended downtime.

Covers PVC binding through Longhorn, rsync data transfer, Argo CD reconciliation, login smoke test, and verified GCS backup after migration.

Outcome¶

The result is a resilient, observable storage posture for the Academy LMS.

Moodle data is no longer tied to a single cluster node.
Longhorn presents the volume as a standard RWO PVC with its backup path and operational state exposed through the platform.
The recorded migration verified automated backup to a GCS bucket.
The service returned to a healthy state without data loss or extended downtime.

Operating model¶

Longhorn provides the cluster storage layer and exposes the volume state and backup contract to operators.
The Longhorn storage class (longhorn-moodle) is provisioned before the migration begins.
Data transfer uses a one-shot rsync pod rather than a live Kubernetes volume migration, minimising the risk window.
Argo CD reconciles the updated deployment after the PVC reference is changed.
GCS backup runs automatically against the Longhorn volume after the migration is complete.

Architecture¶

Moodle storage migration architecture showing a node-pinned hostPath source, a controlled rsync and Argo CD migration window, and a Longhorn-managed PVC with automated backup after cutover.

The migration avoids a live volume move. Data is transferred through a one-shot rsync pod during a controlled window. The old PV is left in place until the new volume is confirmed healthy.

Before and after¶

Property	Before	After
Storage class	`hostPath`	`longhorn-moodle`
PVC	manual, node pinned	`education-moodle-data`, 20Gi RWO
Node dependency	`rke2-cp-03.hybzone.local`	Longhorn-managed PVC instead of a host-local path
Runtime control	manual host path	Longhorn-managed volume
Backup	none	GCS: `hyops-dev-longhorn-backups-gcp03-a1`

Migration sequence¶

Longhorn storage class and backup target were configured before the migration window.
The new PVC (education-moodle-data, storageClass: longhorn-moodle, 20Gi) was created and bound.
A one-shot rsync pod transferred data from the source hostPath path to the new volume.
The Moodle deployment was updated to reference the new PVC.
Argo CD reconciled the updated state. Longhorn confirmed the volume as healthy.
A login smoke test confirmed the service was live with the migrated data.
Backup to GCS was verified against the recorded bucket target.

Platform state¶

Longhorn volume detail: education-moodle-data attached and healthy, with replica state, attachment record, and snapshot section visible

HybridOps Academy page served by the migrated Moodle workload after the Longhorn cutover, showing the application running beyond the login screen

Longhorn recurring jobs view showing the academy-moodle-backup-hourly backup policy with hourly schedule, retention, and labels for the Moodle storage lane

IP addresses, hostnames, and instance identifiers visible in screenshots and recordings reflect the ephemeral infrastructure provisioned during the recorded exercise.

Implementation¶

Storage class: longhorn-moodle is a dedicated Longhorn storage class for the Moodle volume, separate from the default cluster storage path.
Data transfer: a one-shot rsync pod performs the hostPath → PVC copy within the existing cluster; no external tooling or downtime window required.
Deployment update: the Moodle deployment manifest is updated to reference the new PVC; Argo CD reconciles the change without manual intervention.
Backup path: Longhorn is configured with a GCS backup target; automated backup starts once the volume is healthy and bound.

Key components¶

Longhorn storage class: longhorn-moodle
PVC: education-moodle-data (namespace: moodle, 20Gi RWO)
GCS backup bucket: hyops-dev-longhorn-backups-gcp03-a1
Data transfer: one-shot rsync pod (hostPath source → Longhorn PVC target)
GitOps: Argo CD reconciled the deployment update during the migration window

Where it fits¶

Stateful workloads running on node pinned storage that need to move to a supported managed storage posture
Academy and LMS deployments where data integrity and recoverability are required
Teams adopting Longhorn on an existing RKE2 cluster with production workloads already in place

References¶

What was verified¶

Verified during the recorded HybridOps v1.0.1 migration. The PVC was bound through longhorn-moodle, Argo CD reported the workload healthy, the login endpoint returned 303, and the GCS backup target was configured and validated.