Velero Restore Runbook

Dieses Runbook beschreibt die Wiederherstellung von Kubernetes-Ressourcen mit Velero anhand verschiedener Praxisbeispiele.

Voraussetzungen

  • Velero ist betriebsbereit.

  • Zugriff auf den Kubernetes-Cluster ist vorhanden.

  • Das gewünschte Backup oder Schedule existiert.

  • Das Ziel-Cluster verfügt über die erforderlichen StorageClasses.

Verfügbare Backups anzeigen:

velero backup get

Verfügbare Schedules anzeigen:

velero schedule get

Restore überwachen

Aktive Restores anzeigen:

velero restore get

Details eines Restores anzeigen:

velero restore describe <restore-name> --details

Restore-Logs anzeigen:

velero restore logs <restore-name>

Einfacher Restore aus einem Schedule

Stellt alle im Schedule enthaltenen Ressourcen wieder her.

velero restore create \
  --from-schedule tamay-cloud

Restore mit Namespace-Mapping

Stellt Ressourcen wieder her und schreibt diese in einen anderen Namespace um.

Beispiel:

  • Quelle: roundcube

  • Ziel: mail

velero restore create \
  --from-schedule tamay-cloud \
  --namespace-mappings roundcube:mail

Restore von spezifischen Ressourcen

In einem Backup, das mehrere Objekte beinhaltet, möchte man möglicherweise nur eine PVC von vielen wiederherstellen. Das lässt sich entweder über include-resources oder über selector mit Labels lösen.

Beispiel:

Das sind die PVCs vor dem restore. Angenommen die PVC media-paperless-ngx-0 wurde gelöscht und soll wiederhergestellt werden.

kubectl -n paperless-ngx get pvc --show-labels
NAME                    STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS    VOLUMEATTRIBUTESCLASS   AGE   LABELS
data-paperless-ngx-0    Bound    pvc-4050e163-80aa-45dc-9aa7-cda9327e78db   10Gi       RWO            linstor-r02     <unset>                 17h   app.kubernetes.io/name=paperless-ngx,paperless-usage=data
media-paperless-ngx-0   Bound    pvc-f9692c6d-c5ef-4e1e-accb-1274035895ba   10Gi       RWO            linstor-r02     <unset>                 17h   app.kubernetes.io/name=paperless-ngx,paperless-usage=media

Explizite Ressourcen Wiederherstellung über include-resources:

velero restore create <RESTORE_NAME> \
  --from-schedule home-tamay-cloud \
  --include-namespaces paperless-ngx \
  --include-resources persistentvolumeclaims/media-paperless-ngx-0

Und über Labels:

velero restore create <RESTORE_NAME> \
  --from-schedule home-tamay-cloud \
  --include-namespaces paperless-ngx \
  --selector paperless-usage=media

Restore mit Manifest-Anpassungen

Während des Restores können Ressourcen mit einer Resource Modifier ConfigMap verändert werden.

Beispiel:

velero restore create \
  --from-schedule tamay-cloud \
  --namespace-mappings roundcube:mail \
  --resource-modifier-configmap remove-pvc-selector

Beispiel ConfigMap

Die folgende ConfigMap entfernt PVC-Selectoren während des Restores.

apiVersion: v1
kind: ConfigMap
metadata:
  name: remove-pvc-selector
  namespace: velero
data:
  config.yaml: |
    version: v1
    resourceModifierRules:
    - conditions:
        groupResource: persistentvolumeclaims
      patches:
      - operation: remove
        path: "/spec/selector"

Restore mit StorageClass-Migration

Velero kann während des Restores StorageClasses umschreiben.

Dies ist hilfreich bei:

  • Cluster-Migrationen

  • Storage-Migrationen

  • Wechsel des CSI-Treibers

Beispiel ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: change-sc-piraeus-storage
  namespace: velero
  labels:
    velero.io/change-storage-class: RestoreItemAction
    velero.io/plugin-config: ""
data:
  linstor-r01: linstor-local
  linstor-r02: linstor-local

Dabei werden folgende StorageClasses ersetzt:

Quelle Ziel

linstor-r01

linstor-local

linstor-r02

linstor-local

Restore starten:

velero restore create \
  --from-schedule tamay-cloud

Restore aller Namespaces außer bestimmter Namespaces

Bestimmte Namespaces können vom Restore ausgeschlossen werden.

Beispiel:

  • Alle Namespaces wiederherstellen

  • immich und baikal ausschließen

velero restore create \
  --from-schedule tamay-cloud \
  --exclude-namespaces immich,baikal

Restore einzelner Namespaces

Nur ausgewählte Namespaces werden wiederhergestellt.

Beispiel:

velero restore create \
  --from-schedule tamay-cloud \
  --include-namespaces baikal

Mehrere Namespaces:

velero restore create \
  --from-schedule tamay-cloud \
  --include-namespaces baikal,roundcube,immich

Restore eines konkreten Backups

Falls kein Schedule verwendet werden soll, kann direkt ein Backup angegeben werden.

Verfügbare Backups anzeigen:

velero backup get

Restore starten:

velero restore create \
  --from-backup <backup-name>

Restore in ein leeres Zielcluster

Typischer Ablauf für Disaster Recovery oder Cluster-Migrationen:

  1. Velero im Zielcluster installieren.

  2. Backup Storage Location konfigurieren.

  3. Zugriff auf Backup Repository sicherstellen.

  4. Erforderliche Restore ConfigMaps erstellen.

  5. Restore starten.

  6. PVCs, Pods und Ingresses prüfen.

Beispiel:

velero restore create \
  --from-schedule tamay-cloud

Nacharbeiten

PVCs prüfen:

kubectl get pvc -A

Pods prüfen:

kubectl get pods -A

Ingresses prüfen:

kubectl get ingress -A

Events prüfen:

kubectl get events -A --sort-by=.lastTimestamp

Bekannte Probleme

WaitForFirstConsumer StorageClasses

Bei StorageClasses mit WaitForFirstConsumer kann ein Restore hängen bleiben.

Siehe:

Velero Restore mit WaitForFirstConsumer StorageClasses

Fehlende StorageClasses

Wenn eine StorageClass im Zielcluster fehlt, bleiben PVCs im Status Pending.

Prüfen:

kubectl get storageclass

Namespace existiert bereits

Vorhandene Ressourcen können Restore-Konflikte verursachen.

Vor dem Restore prüfen:

kubectl get namespace

Referenzen