Backup dei Persistent Volume di Kubernetes: strumenti, CronJobs e pattern di ripristino

In questo contributo spiego in modo pratico come pianificare e gestire in modo affidabile i Kubernetes-Persistent-Volume-Backups. La parola chiave focalizzata Kubernetes-Persistent-Volume-Backups viene posta subito all’inizio, perché i backup di storage nei container hanno prerequisiti, rischi e schemi di ripristino diversi rispetto ai backup classici a livello di filesystem. Il pubblico di riferimento sono amministratori, system engineer e gestori: al termine devono poter decidere quali strumenti e processi si adattano ai loro SLA e come operationalizzare routine, test e strategie di fallback.

Perché i backup dei Persistent Volume in Kubernetes sono diversi

PersistentVolume (PV) è in Kubernetes l’oggetto di storage astratto; un PersistentVolumeClaim (PVC) è la richiesta di un’applicazione a un PV. StorageClass descrive la provisioning (es. basato su blocchi o NFS). Nei sistemi classici si eseguono backup di filesystem o dispositivi a blocchi direttamente. In Kubernetes si aggiungono complessità supplementari:

• Cicli di vita volatili: Pod/StatefulSet possono essere ricollegati dinamicamente.
• Più percorsi di accesso: le condivisioni NFS/SMB e lo storage a blocchi si comportano in modo diverso con gli snapshot.
• Consistenza dell’applicazione: i database richiedono quiescenza o snapshot coordinati.

Queste differenze implicano: lo strumento di backup, il meccanismo di snapshot e gli schemi di ripristino devono essere allineati.

Kubernetes-Persistent-Volume-Backups: panoramica degli strumenti

Esistono tre approcci diffusi, che si completano o si sostituiscono a vicenda:

• CSI-Snapshots: snapshot point-in-time supportati dal provider di storage tramite il Container Storage Interface (CSI). Adatti per copie rapide e consistenti a livello di blocco; non sostituiscono un backup esterno se è richiesta protezione aggiuntiva contro il guasto dello storage.
• Operatori di backup come Velero o Kasten: orchestrano snapshot, salvano metadati e possono copiare i volumi in repository esterni (object storage). Velero è Open Source e ampiamente diffuso; Kasten è commerciale con più integrazioni.
• Backup a livello file/image con RESTic/Borg/rsync: montare il volume in un Job/Pod e copiare i file in un repository. Indicato per NAS/condivisioni file e quando gli snapshot CSI nativi non sono disponibili.

I criteri di scelta sono RTO (Recovery Time Objective), RPO (Recovery Point Objective), tipo di storage (NAS vs blocchi), requisiti di crittografia e compliance. Gli snapshot CSI offrono RTO ridotti; i repository esterni aumentano la resilienza contro il guasto dello storage.

CSI-Snapshots vs backup completi

Uno snapshot CSI è un’operazione a livello di metadati implementata internamente dal backend di storage. È veloce e spesso consistente per volumi singoli. Perché non è sempre sufficiente:

• Gli snapshot risiedono sullo stesso backend: un guasto hardware o un errore del cluster può danneggiare sia i dati sorgente sia quelli degli snapshot.
• Gli snapshot di norma non sono versionati come i backup su object storage; le politiche di retention possono essere più complesse.
• Per la consistenza tra applicazioni (es. DB distribuiti) sono necessari meccanismi di quiescenza coordinata.

Per questo molti team combinano snapshot CSI (per ripristini rapidi) con backup esterni regolari (per il disaster recovery).

CronJob di backup in Kubernetes: pattern e best practice

Per backup semplici di file o backup complementari, gli operatori usano i CronJob di Kubernetes (oggetto Kubernetes per job pianificati). Sono fondamentali idempotenza, locking, logging e codici di uscita chiari.

Esempio: CronJob che monta un PVC in un pod di backup ed esegue rsync su un NAS. Questo pattern è adatto per NFS-PV o quando i CSI‑Snapshots non sono disponibili.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: pvc-rsync-backup
spec:
  schedule: "0 2 * * *" # täglich 02:00
  jobTemplate:
    spec:
      template:
        spec:
          RESTartPolicy: OnFailure
          volumes:
            - name: data
              persistentVolumeClaim:
                claimName: my-app-pvc
          containers:
            - name: backup
              image: alpine:3.18
              command: ["/bin/sh", "-c"]
              args:
                - |
                  set -euo pipefail
                  mountpoint -q /data || (echo "PVC not mounted"; exit 2)
                  rsync -a --delete /data/ /backup-nfs/my-app/$(date +%F)/
              volumeMounts:
                - name: data
                  mountPath: /data
          nodeSelector:
            backup: "true"

Perché questo pattern funziona: un Job monta il PVC in un pod autonomo, esegue una copia a livello di file e scrive su una condivisione NAS separata, esterna allo storage di Kubernetes. Questo disaccoppia la retention del backup dal backend del PV.

Quando fallisce: se i file sono aperti, i dati vengono scritti in modo incoerente (WAL del database non flushato), o se il pod di backup gira su un nodo che non ha percorsi di rete adeguati verso il NAS.

Integrazioni pratiche per i CronJob

• Locking tramite ConfigMap/Lease, per evitare che più job girino contemporaneamente.
• Logging esposto (es. stdout → Log‑Collector) e politica sui codici di uscita, per evitare failure silenziosi.
• Resource Limits e NodeSelectors per stabilità di rete e I/O.

Esempio: Locking con ConfigMap

Un locking semplice può essere realizzato tramite ConfigMap o Lease. Questo pattern impedisce l’esecuzione parallela dei job:

#!/bin/bash
set -euo pipefail
LOCK_NAME=my-backup-lock
NAMESPACE=backup
# Try to create ConfigMap as lock
kubectl -n "$NAMESPACE" create configmap "$LOCK_NAME" --from-literal=owner=$(hostname) --dry-run=client -o yaml | kubectl apply -f -
# Check owner (simple approach)
OWNER=$(kubectl -n "$NAMESPACE" get configmap "$LOCK_NAME" -o jsonpath='{.data.owner}')
if [ "$OWNER" != "$(hostname)" ]; then
  echo "Another backup is running (owner=$OWNER)"; exit 3
fi
# Run backup here
# On exit (trap) delete lock

Pattern di RESTore: PVC‑RESTore, clone e Application Recovery

Il RESTore ha più livelli: ripristino del volume, ricollegamento del Pod/StatefulSet e ricostruzione dell’applicazione (es. recovery di database). Tre pattern comuni:

1. Volume‑RESTore tramite backend di storage (CSI Snapshot RESTore): Snapshot → nuovo PV → PVC si associa al nuovo PV. Vantaggio: veloce, a livello di blocco. Svantaggio: eventualmente gli stessi rischi dello storage.
2. Object/Repository → ripristino a livello file: copiare il backup da object storage o NAS in un nuovo PVC. Vantaggio: verifica facile prima del mount in produzione. Svantaggio: richiede tempo.
3. RESTore application‑aware: es. point‑in‑time del DB con WAL‑replay. Qui il RESTore deve ripristinare lo stato dell’applicazione (schema, log, indici).

Esempio: ripristinare un PVC da object‑backup (livello file)

Passaggi:

• Creare un nuovo PVC con la stessa StorageClass, ma con nome temporaneo.
• Avviare un pod che monta il PVC e copia il backup nel volume.
• Eseguire controlli di integrità (checksum, conteggio dei file).
• Indirizzare l’applicazione di produzione e sostituire il PVC oppure adattare il Deployment.

# Beispiel: RESTore-Skript im RESTore-Pod
set -euo pipefail
BACKUP_PATH=/backup-nfs/my-app/2026-07-27/
TARGET=/data
rsync -a --delete "$BACKUP_PATH" "$TARGET/"
# einfache Integritätsprüfung
find "$TARGET" -type f -exec sha256sum {} ; > /tmp/RESTore.sha256
# optional: vergleichen mit manifestierter Prüfsumme

Consistenza per i database e NAS: Quiesce, Flush e WAL

Per i database, una semplice copia dei file spesso non è sufficiente. Sono necessari:

• Quiesce o flush: istruire l’applicazione a svuotare le cache (es. MySQL FLUSH TABLES WITH READ LOCK) in modo che i file siano coerenti.
• WAL/Transaction Logs: per il Point-in-Time-Recovery (PITR) i log delle transazioni devono essere archiviati separatamente.

Per condivisioni NAS (NFS/SMB) possono sorgere problemi aggiuntivi: handle aperti, lock sui file e UID/GID distribuite. Il job di backup deve gestire i file aperti e, idealmente, avviare processi coordinati al momento della copia.

NAS‑How‑To: best practice, troubleshooting e lista di controllo

Le condivisioni NAS in Kubernetes vengono spesso esposte tramite NFS o SMB. Queste condivisioni presentano insidie specifiche che causano problemi ricorrenti in produzione.

Priorità

• Coerenza UID/GID: gli ID utente e di gruppo devono corrispondere tra cluster e NAS o essere risolti tramite un livello di mapping; altrimenti i permessi non saranno corretti dopo il RESTore.
• Verificare handle aperti: prima del backup rilevare file-handle e lock aperti, perché rsync/copy altrimenti può operare su dati incoerenti.
• Quote e monitoring: i volumi target del NAS devono essere monitorati, altrimenti lo storage dei backup si riempie e i job falliscono silenziosamente.

Passi di verifica concreti (Troubleshooting)

Comandi di esempio utili durante il troubleshooting:

# offene Handles auf einem gemounteten NAS prüfen
lsof +D /data | head
# prüfen, welche Prozesse auf NFS Dateien halten
fuser -m /data
# Platz prüfen auf NAS-Mount
df -h /backup-nfs
# Berechtigungen eines Beispieldatei prüfen
stat -c '%U %G %a' /data/somefile

Interpretazione: lsof/fuser mostrano i processi con handle aperti. Se processi DB critici mantengono log aperti, prima del backup è necessario eseguire un flush/quiesce o utilizzare snapshot/meccanismi supportati dal provider.

Rsync: Chunking e pRESTazioni

Per grandi volumi di file conviene suddividere e trasferire in parallelo, combinato con un target deduplicante (es. NAS con de-dup o object storage con dedupe). Esempio con GNU Parallel e rsync:

# chunked rsync: find list of top-level dirs and sync in parallel
cd /data
find . -maxdepth 1 -mindepth 1 -type d -print0 | 
  xargs -0 -n1 -P4 -I{} rsync -a --delete "{}" /backup-nfs/my-app/$(date +%F)/"{}"

Attenzione: il sync parallelo può generare picchi di I/O; adattare il numero di processi paralleli ai limiti di I/O del nodo.

Checklist per i backup NAS

• Prima: verificare le quote dello storage, pianificare spazio target > 2× della dimensione prevista del backup.
• Prima del job: controllare handle aperti (lsof/fuser) ed eseguire il DB‑flush.
• Durante il job: misurare logging, exit code e rate di trasferimento.
• Dopo il job: verificare checksum, conteggio file e pulizia delle retention (Purge).

Velero & repository di oggetti: breve workflow pratico

Velero (open source) orchestra backup a livello di cluster di risorse e volumi. Per i PV Velero utilizza CSI‑snapshot (se disponibile) o backup di volumi basati su plugin. I passaggi tipici sono:

1. Installazione con provider‑plugin (es. S3/MinIO/AWS S3).
2. Configurazione dei piani di backup e integrazione RESTic/CSI per i dati dei volumi.
3. Eseguire esercitazioni di RESTore regolari.

CLI‑Beispiel: Backup eines Namespace inklusive Volumes (Velero & RESTic):

# Velero Backup starten
velero backup create myapp-backup-$(date +%F) --include-namespaces my-app-namespace --snapshot-volumes
# Status prüfen
velero backup get
# RESTore (in Test-namespace)
velero RESTore create --from-backup myapp-backup-2026-07-27 --namespace-mappings my-app-namespace:RESTore-test

Velero bietet Metadaten‑Management und einfache RESTore‑Orchestrierung; RESTic‑Integration ist sinnvoll, wenn Sie Dateiebene in Objekt‑Storage speichern wollen.

Kubernetes-Persistent-Volume-Backups: Monitoring, Metriken und Alerts

Operationalisieren heißt Kennzahlen messen. Wichtige Metriken:

• Backup success rate (Anteil erfolgreicher Jobs).
• Backup duration (Zeitdauer je Job).
• RESTore duration und RESTore success rate.
• Repository free space und Growth rate.

Prometheus eignet sich zur Erfassung; Beispiel AlertRule für fehlgeschlagene Backups:

groups:
- name: backup.rules
  rules:
  - alert: BackupFailures
    expr: increase(kube_job_status_failed{job="pvc-rsync-backup"}[24h]) > 0
    for: 1h
    labels:
      severity: page
    annotations:
      summary: "Backup-Job fehlgeschlagen"
      description: "Mindestens ein Backup-Job ist innerhalb der letzten 24h fehlgeschlagen."

Wichtig: Alerts sollten mit Runbooks verknüpft sein, die prüfen, ob es sich um Konfigurations-/Storage‑Probleme oder um transienten Netzwerkausfall handelt.

RESTore‑Validation: Automatisierte Prüfungen und Testplan

Validation ist Pflicht. Ein Wiederherstellungs‑Test sollte immer folgende Schritte automatisiert abarbeiten:

1. RESTore in Isolationsnamespace durchführen.
2. Mounten des wiederhergestellten PVCs und Ausführen von File‑Integrity‑Checks (Checksummen, Dateizähler).
3. Anwendungssmoke: Health‑Endpoint, minimaler Geschäftsprozess durchspielen.
4. DB‑Konsistenz: Prüfen von Indizes, Replikationsstatus, WAL/Replikations‑Lag.
5. Zeiterfassung: Dokumentation der benötigten Zeit (für RTO‑Reporting).

Beispiel Smoke‑Check als Script (siehe oben im Artikel). Automatisieren Sie solche Tests in einer CI/CD‑Pipeline oder als Teil der Backup‑Job‑Kette, damit tägliche Sanity‑Checks ohne manuellen Aufwand laufen.

Praxisfälle, Risiken und typische Stolperfallen

Häufige Ursachen für fehlgeschlagene Backups/RESTores:

• Volles Backup‑Repository oder NAS: Jobs schlagen still fehl, wenn kein Platz da ist.
• NetzwerkRESTriktionen: Backup‑Jobs auf Nodes ohne Zugriff auf das Objekt‑Storage oder NAS laufen ins Leere.
• Permissions‑Mismatch nach RESTore: UID/GID oder ACLs passen nicht, Anwendungen starten nicht.
• Ignorierte Exit‑Codes: CronJobs, die Fehler nicht exportieren, sehen erfolgreich aus, obwohl Kopiervorgänge fehlschlugen.

Checkliste vor Produktionsbetrieb:

• SLA‑Mapping: RTO/RPO definieren.
• Storage‑Provisioning testen (CSI Snapshot & RESTore).
• Netzwerk‑Pfad vom Backup‑Node zum Repository verifizieren.
• Automatisierte RESTore‑Verifikation implementieren.

Sicherheits- und Compliance-Aspekte

La crittografia, la gestione delle chiavi e la registrazione degli accessi sono obbligatorie per i dati sensibili. I repository dovrebbero essere crittografati lato server; inoltre è consigliabile conservare le chiavi separatamente, ad esempio in un HSM o in Vault (HashiCorp Vault è uno strumento per la gestione dei segreti che gestisce le chiavi in modo sicuro). I log di audit e le somme di controllo aiutano nelle evidenze di compliance.

Strategia di rollback e di emergenza

Un ripristino può fallire. Prevedete rollback a più livelli:

1. Failover verso uno standby (se disponibile).
2. Ripristino in un namespace di isolamento per la validazione.
3. Ricollegare la produzione al PVC testato solo dopo smoke test riusciti.

Documentate i passaggi del rollout e le responsabilità, in modo che in caso di incidente non si perda tempo in coordinamenti.

Raccomandazioni e conclusione

In sintesi, raccomando il seguente piano pragmatico:

1. Definite RTO/RPO e verificate la funzionalità di StorageClass/CSI‑Snapshot.
2. Combinate CSI‑Snapshots (per ripristini rapidi) con backup di repository esterni (per scenari DR e compliance).
3. Utilizzate i CronJobs solo per backup a livello di file, se il CSI non è disponibile; implementate meccanismi di locking e logging accurato.
4. Misure specifiche per NAS: verificare handle aperti, garantire la consistenza UID/GID e pianificare trasferimenti chunked.
5. Automatizzate e testate regolarmente i percorsi di ripristino; integrate smoke test nelle pipeline CI/CD.

Con questa struttura riducete i rischi operativi e create processi di ripristino ripetibili che rendono gestibile la quotidianità di amministratori e team operativi.

Ulteriori letture e opzioni per collegamenti interni

Questo contributo è concepito come guida tecnica e può essere esteso con articoli esistenti su manutenzione dei backup, architettura di rete per le finestre di backup e validazione del ripristino. Link interni a checklist e playbook di ripristino possono essere inseriti qui in modo utile.

FAQ

Le principali domande e risposte per un orientamento rapido le trovate nella sezione seguente.