How would be an idiomatic way of restoring PVC to PV maps in a single-node K3s cluster?

[nikp123]

Hi,
I came into a quite frustrating issue with etcd (which for some reason was enabled by default on NixOS) where it kept one of the CPU threads locked at 100%. The solution I've found is to make it use sqlite instead, but doing so I have found a major pain-point of Kubernetes in general.

Since I'm working with a single-node setup, there is absolutely no need to use cloud-backed PVs, hence early on I decided to use rancher's own local-path provisioner to handle PVCs.
However, I did run into a issue: How can I sanely back up PVC to PV mappings after I rebuild a cluster. As in, how can I tell k3s "oh that PVC named X is at location Y backed by storageClass Z...etc". Is there a sane way to restore this information.

So far I've tried: kubectl get pv -o yaml > backup_pv.yaml and then restoring said file on the new cluster with no luck. The PV stays at Released and wont let new PVCs bind to it.

Any advice when it comes to this is appreciated.

PS: Also I have considered volsync but restoring stuff in the order of multiple of hundreds of gigabytes per cluster rebuild is wildly unreasonable.

[nikp123]

As for the rest of the cluster its managed by Flux and Gitops so that side works amazingly. It's only the persistence of volumes which is insanely hard to manage.

[theboringhumane]

Check spec.claimRef.uid on the restored PV. A PVC recreated by Flux has a new UID even if its name and namespace are unchanged, so the exported PV may still be reserved for the old claim. That would explain the Released state.

For a repeatable restore, keep clean PV/PVC manifests: preserve the PV's actual storage source/path and node affinity, set persistentVolumeReclaimPolicy: Retain, and set the PVC's spec.volumeName to that PV. Reserve the PV with claimRef.name and namespace, without the old claim UID. Don't copy the old object UID, resourceVersion or status. Kubernetes documents pre-binding an existing volume; storage class, access modes and size still have to match. Check that the node-affinity hostname matches the rebuilt node too.

For the already-restored PV, the stale claim reference needs to be cleared before rebinding. Set and verify Retain before deleting any claims or doing cleanup: local-path's normal deletion path removes the data directory. This reuses the existing storage if it is intact; it still needs a separate data backup.

[nikp123]

I've since migrated to a Velero-backed solution but I feel this is the answer for people still seeking this. Thank you.