Backup-Übersicht¶

Übersicht¶

Die Polycrate API bietet eine zentrale Read-Only-Ansicht auf Velero- und **CloudNativePG-**Backups und -Schedules in verbundenen Clustern.

Architektur¶

Das Backup-Monitoring ist in den Polycrate Operator integriert. Der Operator erkennt Velero-Installationen im Cluster und synchronisiert Backup-Status automatisch mit der Polycrate API.

graph TB
    subgraph cluster1[Kubernetes Cluster 1]
        VELERO1[Velero]
        OP1[Polycrate Operator]
        BACKUP_CRD1[Backup CRs]

        VELERO1 --> BACKUP_CRD1
        OP1 -->|Liest| BACKUP_CRD1
    end

    subgraph cluster2[Kubernetes Cluster 2]
        VELERO2[Velero]
        OP2[Polycrate Operator]
        BACKUP_CRD2[Backup CRs]

        VELERO2 --> BACKUP_CRD2
        OP2 -->|Liest| BACKUP_CRD2
    end

    subgraph api[Polycrate API]
        OVERVIEW[Aggregierte Übersicht]
        DASHBOARD[Status-Dashboard]
        ALERTS[Alerts bei Problemen]
        HISTORY[Historie & Trends]
    end

    OP1 -->|Push Status| api
    OP2 -->|Push Status| api

Operator-basiertes Backup-Monitoring (Standard)¶

In Kubernetes-Clustern mit installiertem Polycrate Operator werden Backups automatisch erkannt und an die API übermittelt:

1. Velero-Erkennung: Operator prüft bei Cluster-Reconciliation auf Velero-Installation
2. CRD-Lesen: Liest Backup, Schedule und BackupStorageLocation CRs
3. Status-Push: Synchronisiert Backup-Status an die Polycrate API
4. S3-Verknüpfung: Verknüpft Backups mit S3-Buckets aus BackupStorageLocation

Vorteile des Operator-basierten Ansatzes:

• ✅ Automatische Velero-Erkennung
• ✅ Echtzeit-Updates bei Backup-Status-Änderungen
• ✅ Keine manuelle Konfiguration erforderlich
• ✅ Funktioniert auch bei temporären API-Ausfällen

Fallback: API-Pull (ohne Operator)¶

Für Workspaces ohne verbundenen Polycrate Operator kann die API Backup-Status direkt vom Cluster abrufen:

graph LR
    subgraph cluster[Cluster ohne Operator]
        VELERO[Velero]
        BACKUP_CRD[Backup CRs]
    end

    API[Polycrate API]

    API -->|Pull Status| BACKUP_CRD

Was Sie sehen können¶

Backup-Dashboard¶

Unter Kubernetes → Backups finden Sie:

Backup-Status¶

Backup-Details¶

Für jedes Backup sichtbar:

• Erstellungszeitpunkt: Wann wurde gesichert?
• Ablaufzeit (Expiration): Wann wird das Backup gelöscht?
• Retention Policy: TTL-Konfiguration (z.B. "96h")
• Provider: Backup-Tool (Velero, CloudnativePG, etc.)
• S3-Bucket: Wo wird das Backup gespeichert?
• Velero-Statistiken: Volume Snapshots, Warnings, Errors

Backup-Arten¶

Backup Schedules¶

Der Operator erkennt auch Velero Schedules und zeigt diese im Cluster-Detail. Polycrate überwacht jeden Schedule und zeigt an, ob das letzte Backup überfällig ist.

Überfällig-Status¶

Ein Backup Schedule gilt als überfällig (overdue), wenn seit dem letzten erfolgreichen Backup mehr Zeit vergangen ist als das konfigurierte Intervall. Polycrate prüft diesen Status alle 5 Minuten anhand des tatsächlichen letzten Backups (last_backup_at).

Überfällige Schedules werden im Operations-Dashboard unter "Overdue Backup Schedules" hervorgehoben und lösen eine Benachrichtigung aus – so werden verpasste Backups sofort sichtbar, ohne manuell suchen zu müssen.

# Beispiel: Erkannter Schedule
name: daily-backup
schedule: "0 2 * * *"
template:
  includedNamespaces: ["*"]
  snapshotVolumes: true
status:
  phase: Enabled
  lastBackup: "2025-01-27T02:00:00Z"

Cluster-übergreifende Übersicht¶

Die Polycrate API zeigt Backups aller verbundenen Cluster in einer einzigen Ansicht:

Vorteile der zentralen Übersicht¶

• Schnelle Problemerkennung: Fehlgeschlagene Backups sofort sichtbar
• Kein Cluster-Hopping: Alle Backup-Status an einem Ort
• Trend-Analyse: Erkennen von wiederkehrenden Problemen
• Compliance-Nachweis: Dokumentation der Backup-Ausführung

Metriken & Trends¶

Das Dashboard zeigt aggregierte Informationen:

• Backup-Erfolgsrate: % erfolgreiche Backups (letzte 7/30 Tage)
• Fehler-Trend: Nehmen Backup-Fehler zu oder ab?
• Durchschnittliche Backup-Größe: Pro Cluster/Namespace
• Letzte erfolgreiche Backups: Pro kritischem Namespace

Velero-Konfiguration (im Cluster)¶

Backup triggern¶

# Im Kubernetes-Cluster
velero backup create manual-backup-$(date +%Y%m%d) \
  --include-namespaces production

Restore ausführen¶

# Im Kubernetes-Cluster
velero restore create --from-backup daily-backup-20250115

Schedule konfigurieren¶

# Im Kubernetes-Cluster
velero schedule create daily-backup \
  --schedule="0 2 * * *" \
  --include-namespaces production \
  --ttl 168h

Best Practices¶

Monitoring-Empfehlungen¶

1. Polycrate Operator installieren: Für automatisches Backup-Monitoring
2. Alert-Konfiguration prüfen: Stellen Sie sicher, dass Backup-Alerts aktiviert sind
3. Regelmäßige Dashboard-Checks: Täglicher Blick auf Backup-Status
4. Trend-Beobachtung: Achten Sie auf abnehmende Erfolgsraten

Bei Backup-Fehlern¶

1. In der Polycrate API: Alert-Details und Fehlermeldung prüfen
2. Im Cluster: Velero-Logs analysieren

   kubectl logs -n velero deployment/velero
   

3. Storage prüfen: Ist der Backup-Storage erreichbar?
4. Manuelles Retry: Backup manuell neu starten

Wichtige Namespaces überwachen¶

Stellen Sie sicher, dass kritische Namespaces regelmäßig gesichert werden:

• Produktions-Workloads
• Datenbanken und stateful Services
• Konfigurationen und Secrets

Unterstützte Backup-Provider¶

Siehe auch¶

• Polycrate Operator
• Organisationen & Workspaces