Moodle Storage Migration to Longhorn

Overview

Moodle Storage Migration to Longhorn moves a stateful workload from a node-pinned storage posture to managed cluster storage through a controlled in-cluster copy and cutover, then adds a verified GCS backup path.

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 or backup path, so the workload remained tied to one node.
• Challenge: migrating a live stateful workload without losing application data or binding the service to an unverified target.
• 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 with the migrated data intact.

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 inside the existing cluster.
• Argo CD reconciles the updated deployment after the PVC reference is changed.
• GCS backup runs against the Longhorn volume after the target is healthy and bound.

Architecture

The target PVC is created and bound before the copy begins. The deployment moves after the in-cluster copy completes, and the source storage remains available until Longhorn health, application smoke testing, and backup verification establish the new operating state.

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

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

Platform state

Moodle data volume attached and healthy on Longhorn.

Application served successfully from the migrated storage path.

Recurring backup policy attached to 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 inside the existing cluster; application cutover is handled through deployment reconciliation rather than external migration tooling.
• Deployment update: the Moodle deployment manifest is updated to reference the new PVC; Argo CD reconciles the change.
• 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

Further reading

• Moodle Longhorn migration verification runbook
• RKE2 HA Platform Foundation

Related

Related reading

• RKE2 HA Platform Foundation
• Verify Moodle Longhorn Migration State

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.