37 Backup-Strategien

Backup-Strategien für OpenShift-Storage implementieren umfassende Datenschutz-Frameworks durch mehrstufige Backup-Ansätze, die Anwendungsdaten, Metadaten und Konfigurationszustand erfassen. Diese Resilienz-Architekturen gewährleisten Business-Continuity und Disaster-Recovery-Fähigkeiten durch systematische Datenschutzplanung und automatisierte Wiederherstellungs-Workflows.

37.1 Grundlagen von Container-Storage-Backup

Container-Storage-Backup erfordert holistische Ansätze, die sowohl Persistent-Volume-Daten als auch Anwendungszustand und Kubernetes-Metadaten erfassen. Diese mehrdimensionale Backup-Strategie gewährleistet vollständige Anwendungswiederherstellbarkeit über Infrastrukturausfälle hinaus.

37.1.1 Die Herausforderung der Zustandsverwaltung

Zustandsverwaltungs-Komplexitäten in Container-Umgebungen erfordern Koordination zwischen anwendungsebenen Konsistenz und speicherebenen Snapshots. Diese Zustandskoordination gewährleist transaktionskonsistente Backups für komplexe zustandsbehaftete Anwendungen.

Typische Backup-Szenarien: - Stateless Applications: Nur Konfiguration und Container-Images - Stateful Applications: Daten + Zustand + Konfiguration - Databases: ACID-konforme Snapshots mit Transaktionslog-Konsistenz - Multi-Tier Applications: Koordinierte Backups über Anwendungsschichten

37.1.2 Disaster-Recovery-Planung

Disaster-Recovery-Planung für Container-Plattformen umfasst Cluster-Recovery, Anwendungswiederherstellung und Datenwiederherstellung-Szenarien mit verschiedenen Recovery-Time-Objectives (RTO) und Recovery-Point-Objectives (RPO):

Szenario RTO RPO Backup-Strategie
Einzelner Pod-Ausfall < 1 Min 0 Replikation, automatischer Restart
Node-Ausfall < 5 Min < 5 Min Volume-Snapshots, Pod-Migration
Cluster-Ausfall < 30 Min < 15 Min etcd-Backup, Cross-Cluster-Replikation
Site-Ausfall < 4 Std < 1 Std Off-Site-Backup, DR-Site

[Diagramm: Backup-Strategy-Architektur mit verschiedenen Backup-Ebenen]

37.1.3 DevOps-Integration

Backup-Strategie-Integration mit DevOps-Workflows ermöglicht Backup-as-Code-Ansätze mit versionskontrollierten Backup-Policies:

# Backup-Policy als Code
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-backup
  namespace: velero
spec:
  # Cron-Schedule für tägliche Backups
  schedule: "0 2 * * *"
  template:
    # Backup-Konfiguration
    includedNamespaces:
    - production
    - staging
    excludedResources:
    - events
    - events.events.k8s.io
    # Retention-Policy
    ttl: 720h0m0s  # 30 Tage
    # Pre/Post-Backup-Hooks
    hooks:
      resources:
      - name: postgres-backup
        includedNamespaces:
        - production
        labelSelector:
          matchLabels:
            app: postgres
        pre:
        - exec:
            command:
            - /bin/bash
            - -c
            - "PGPASSWORD=$POSTGRES_PASSWORD pg_dump -h localhost -U $POSTGRES_USER $POSTGRES_DB > /tmp/backup.sql"

37.2 Volume-Snapshot-Mechanismen

37.2.1 CSI-Snapshot-Integration

CSI-Snapshot-Integration standardisiert Volume-Snapshot-Operationen über verschiedene Storage-Backends durch Container Storage Interface Extensions:

# VolumeSnapshotClass Definition
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-aws-vsc
driver: ebs.csi.aws.com
deletionPolicy: Delete
parameters:
  # Snapshot-Tags für Kostenverfolgung
  tagSpecification_1: "backup-policy=daily"
  tagSpecification_2: "retention=30days"

---
# Volume Snapshot erstellen
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: webapp-data-snapshot
  namespace: production
spec:
  volumeSnapshotClassName: csi-aws-vsc
  source:
    persistentVolumeClaimName: webapp-data-pvc

37.2.2 Storage-Backend-Snapshots

Storage-Backend-Snapshots nutzen native Storage-System-Fähigkeiten für effiziente Point-in-Time Volume-Kopien mit minimalem Performance-Impact:

AWS EBS Snapshots:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-snapshot-enabled
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  # Automatische Snapshot-Erstellung
  encrypted: "true"
  # Snapshot-Retention
  deleteOnTermination: "false"
allowVolumeExpansion: true

Ceph RBD Snapshots:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: ceph-rbd-snapshot-class
driver: rbd.csi.ceph.com
deletionPolicy: Delete
parameters:
  clusterID: ceph-cluster
  pool: kubernetes-rbd
  # Snapshot-Replikation
  replication: "3"

37.2.3 Copy-on-Write Optimierung

Copy-on-Write (COW) Snapshot-Implementierung minimiert Storage-Overhead durch inkrementelle Änderungsverfolgung:

# Snapshot-Größe und Overhead monitoren
kubectl get volumesnapshot webapp-data-snapshot -o jsonpath='{.status.readyToUse}'

# Snapshot-Details anzeigen
kubectl describe volumesnapshot webapp-data-snapshot

# Snapshot-Restore-Performance testen
kubectl create -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restored-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  dataSource:
    name: webapp-data-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
EOF

37.3 Anwendungskonsistente Backup-Strategien

37.3.1 Pre- und Post-Backup-Hooks

Pre-Backup-Hooks implementieren anwendungsspezifische Vorbereitungsschritte wie Database-Flushing oder Transaktionsabschluss vor Snapshot-Erstellung:

# Database-Backup mit Pre/Post-Hooks
apiVersion: velero.io/v1
kind: Backup
metadata:
  name: database-consistent-backup
spec:
  includedNamespaces:
  - database
  hooks:
    resources:
    - name: postgresql-backup-hook
      includedNamespaces:
      - database
      labelSelector:
        matchLabels:
          app: postgresql
      pre:
      - exec:
          command:
          - /bin/bash
          - -c
          - |
            # Transaktionen abschließen
            psql -c "SELECT pg_start_backup('velero-backup', true);"
            # WAL-Logs flushen
            psql -c "SELECT pg_switch_wal();"
          onError: Fail
          timeout: 30s
      post:
      - exec:
          command:
          - /bin/bash  
          - -c
          - |
            # Backup-Modus beenden
            psql -c "SELECT pg_stop_backup();"
          onError: Continue

37.3.2 Quiescing-Mechanismen

Quiescing-Mechanismen implementieren temporäre Anwendungspause für konsistente Zustandserfassung:

# Application Quiescing für Multi-Container-Pods
apiVersion: v1
kind: Pod
metadata:
  name: app-with-quiescing
  annotations:
    backup.velero.io/backup-volumes: data-volume,config-volume
    pre.hook.backup.velero.io/command: '["/bin/bash", "-c", "kill -USR1 1"]'
    post.hook.backup.velero.io/command: '["/bin/bash", "-c", "kill -USR2 1"]'
spec:
  containers:
  - name: app
    image: myapp:latest
    volumeMounts:
    - name: data-volume
      mountPath: /data
    - name: config-volume
      mountPath: /config
  volumes:
  - name: data-volume
    persistentVolumeClaim:
      claimName: app-data-pvc
  - name: config-volume
    configMap:
      name: app-config

37.3.3 Multi-Volume-Konsistenzgruppen

Multi-Volume-Konsistenzgruppen koordinieren Snapshot-Erstellung über mehrere verwandte Volumes für konsistente Multi-Komponenten-Anwendungsbackups:

# Konsistenz-Gruppe für Multi-Volume-Application
apiVersion: groupsnapshot.storage.k8s.io/v1alpha1
kind: VolumeGroupSnapshot
metadata:
  name: app-consistency-group
spec:
  volumeGroupSnapshotClassName: consistent-group-class
  source:
    selector:
      matchLabels:
        app: distributed-database
        tier: data
---
apiVersion: groupsnapshot.storage.k8s.io/v1alpha1
kind: VolumeGroupSnapshotClass
metadata:
  name: consistent-group-class
driver: csi-driver.example.com
deletionPolicy: Delete
parameters:
  consistencyLevel: application
  quorumSize: "3"

37.4 Inkrementelle und differentielle Backup-Muster

37.4.1 Block-Level-Inkrementelle Backups

Block-Level-Inkrementelle Backups verfolgen geänderte Blöcke seit dem letzten Backup für storage-effiziente inkrementelle Updates:

# Restic-Backup mit Deduplication
apiVersion: batch/v1
kind: CronJob
metadata:
  name: incremental-backup
spec:
  schedule: "0 */4 * * *"  # Alle 4 Stunden
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: restic/restic:latest
            env:
            - name: RESTIC_REPOSITORY
              value: "s3:s3.amazonaws.com/backup-bucket/openshift-backups"
            - name: RESTIC_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: backup-secret
                  key: password
            command:
            - /bin/sh
            - -c
            - |
              # Inkrementelles Backup mit Deduplication
              restic backup /data --tag daily
              # Cleanup alter Snapshots
              restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 3
              restic prune
            volumeMounts:
            - name: data
              mountPath: /data
              readOnly: true
          volumes:
          - name: data
            persistentVolumeClaim:
              claimName: app-data-pvc

37.4.2 Deduplication und Compression

Deduplication-Mechanismen eliminieren doppelte Datenblöcke über mehrere Backups für Storage-Optimierung:

# Backup-Repository mit Deduplication
apiVersion: v1
kind: ConfigMap
metadata:
  name: backup-config
data:
  config.yaml: |
    repository:
      type: s3
      endpoint: s3.amazonaws.com
      bucket: enterprise-backups
      prefix: openshift-cluster-prod
    compression:
      algorithm: zstd
      level: 3
    deduplication:
      enabled: true
      blockSize: 64KB
      algorithm: sha256
    retention:
      daily: 30
      weekly: 12
      monthly: 12
      yearly: 5

37.5 Cross-Cluster und Multi-Site-Backup

37.5.1 Replikationsbasierte Backup-Strategien

Replikationsbasierte Backup-Strategien implementieren asynchrone Datenreplikation zu entfernten Storage-Standorten:

# Cross-Cluster-Backup mit Velero
apiVersion: velero.io/v1
kind: BackupStorageLocation
metadata:
  name: primary-backup-location
  namespace: velero
spec:
  provider: aws
  objectStorage:
    bucket: primary-backup-bucket
    prefix: cluster-prod
  config:
    region: us-west-2
    s3ForcePathStyle: "false"

---
apiVersion: velero.io/v1
kind: BackupStorageLocation  
metadata:
  name: dr-backup-location
  namespace: velero
spec:
  provider: aws
  objectStorage:
    bucket: dr-backup-bucket
    prefix: cluster-prod
  config:
    region: us-east-1
    s3ForcePathStyle: "false"

37.5.2 Cloud-Storage-Integration

Cloud-Storage-Integration für Off-Site-Backup nutzt Object-Storage-Services für kosteneffektive langfristige Datenaufbewahrung:

# Multi-Cloud-Backup-Strategie
apiVersion: v1
kind: Secret
metadata:
  name: cloud-credentials
type: Opaque
data:
  # AWS-Credentials für primäres Backup
  aws-access-key-id: <base64-encoded>
  aws-secret-access-key: <base64-encoded>
  # Azure-Credentials für DR-Backup
  azure-storage-account: <base64-encoded>
  azure-storage-key: <base64-encoded>
  # GCP-Credentials für Archive
  gcp-service-account: <base64-encoded>

---
apiVersion: batch/v1
kind: CronJob
metadata:
  name: multi-cloud-sync
spec:
  schedule: "0 6 * * 0"  # Wöchentlich
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: sync
            image: rclone/rclone:latest
            command:
            - /bin/sh
            - -c
            - |
              # Sync zu Azure für DR
              rclone sync s3-primary:backup-bucket azure-dr:backup-container
              # Archive zu GCP für Langzeitaufbewahrung
              rclone copy s3-primary:backup-bucket gcp-archive:backup-archive --max-age 30d

37.6 Backup-Verifikation und Testing

37.6.1 Backup-Integritäts-Validierung

Backup-Integritäts-Validierung implementiert automatisierte Backup-Verifikation durch Checksum-Berechnung:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup-verification
spec:
  schedule: "0 8 * * *"  # Täglich nach Backup
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: verify
            image: backup-verify:latest
            env:
            - name: BACKUP_LOCATION
              value: "s3://backup-bucket/daily"
            command:
            - /bin/bash
            - -c
            - |
              # Backup-Checksums verifizieren
              for backup in $(aws s3 ls $BACKUP_LOCATION/ | awk '{print $4}'); do
                echo "Verifying $backup..."
                aws s3 cp s3://backup-bucket/daily/$backup - | sha256sum -c
                if [ $? -ne 0 ]; then
                  echo "FEHLER: Backup $backup ist korrupt!"
                  exit 1
                fi
              done
              echo "Alle Backups sind integer"

37.6.2 Recovery-Testing-Automation

Recovery-Testing-Automation führt regelmäßige Recovery-Simulationen durch für Recovery-Prozedur-Validierung:

# Automatisierter Recovery-Test
apiVersion: batch/v1
kind: CronJob
metadata:
  name: disaster-recovery-test
spec:
  schedule: "0 2 * * 6"  # Wöchentlich am Samstag
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: recovery-test-sa
          containers:
          - name: recovery-test
            image: velero/velero:latest
            command:
            - /bin/bash
            - -c
            - |
              # Test-Namespace erstellen
              kubectl create namespace recovery-test-$(date +%s)
              
              # Letztes Backup restore in Test-Namespace
              LATEST_BACKUP=$(velero backup get -o json | jq -r '.items[0].metadata.name')
              velero restore create test-restore-$(date +%s) \
                --from-backup $LATEST_BACKUP \
                --namespace-mappings production:recovery-test-$(date +%s)
              
              # Warten auf Restore-Completion
              sleep 300
              
              # Application-Health-Check
              kubectl get pods -n recovery-test-$(date +%s)
              
              # Cleanup nach Test
              kubectl delete namespace recovery-test-$(date +%s)

37.7 Metadaten und Konfigurations-Backup

37.7.1 Kubernetes-Metadaten-Backup

Kubernetes-Metadaten-Backup erfasst Cluster-Konfiguration, RBAC-Policies und Custom Resource Definitions:

#!/bin/bash
# Cluster-Metadaten-Backup-Script

BACKUP_DIR="/backup/cluster-metadata-$(date +%Y%m%d)"
mkdir -p $BACKUP_DIR

# Cluster-Info
kubectl cluster-info dump > $BACKUP_DIR/cluster-info.yaml

# Alle Namespaces
kubectl get namespaces -o yaml > $BACKUP_DIR/namespaces.yaml

# RBAC-Konfiguration
kubectl get clusterroles -o yaml > $BACKUP_DIR/clusterroles.yaml
kubectl get clusterrolebindings -o yaml > $BACKUP_DIR/clusterrolebindings.yaml
kubectl get roles --all-namespaces -o yaml > $BACKUP_DIR/roles.yaml
kubectl get rolebindings --all-namespaces -o yaml > $BACKUP_DIR/rolebindings.yaml

# Custom Resources
kubectl get crd -o yaml > $BACKUP_DIR/crds.yaml

# Storage-Konfiguration
kubectl get storageclass -o yaml > $BACKUP_DIR/storageclasses.yaml
kubectl get pv -o yaml > $BACKUP_DIR/persistent-volumes.yaml

# Network-Konfiguration
kubectl get networkpolicies --all-namespaces -o yaml > $BACKUP_DIR/networkpolicies.yaml

# Secrets (verschlüsselt)
kubectl get secrets --all-namespaces -o yaml | \
  gpg --encrypt --armor -r backup@company.com > $BACKUP_DIR/secrets.yaml.gpg

# ConfigMaps
kubectl get configmaps --all-namespaces -o yaml > $BACKUP_DIR/configmaps.yaml

echo "Cluster-Metadaten-Backup abgeschlossen: $BACKUP_DIR"

37.7.2 etcd-Backup-Strategien

etcd-Backup-Strategien implementieren Kubernetes Control Plane State Backup für komplette Cluster-Recovery-Szenarien:

# etcd-Backup Job
apiVersion: batch/v1
kind: CronJob
metadata:
  name: etcd-backup
  namespace: openshift-etcd
spec:
  schedule: "0 */6 * * *"  # Alle 6 Stunden
  jobTemplate:
    spec:
      template:
        spec:
          nodeSelector:
            node-role.kubernetes.io/master: ""
          tolerations:
          - operator: Exists
          hostNetwork: true
          containers:
          - name: etcd-backup
            image: quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:...
            command:
            - /bin/bash
            - -c
            - |
              # etcd-Snapshot erstellen
              /usr/local/bin/etcd-snapshot-backup.sh /backup/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db
              
              # Alte Snapshots bereinigen (> 7 Tage)
              find /backup -name "etcd-snapshot-*.db" -mtime +7 -delete
              
              # Backup-Verifikation
              LATEST_SNAPSHOT=$(ls -t /backup/etcd-snapshot-*.db | head -n1)
              /usr/local/bin/etcdctl snapshot status $LATEST_SNAPSHOT
            volumeMounts:
            - name: backup-storage
              mountPath: /backup
            - name: etcd-certs
              mountPath: /etc/kubernetes/static-pod-certs
              readOnly: true
          volumes:
          - name: backup-storage
            persistentVolumeClaim:
              claimName: etcd-backup-pvc
          - name: etcd-certs
            hostPath:
              path: /etc/kubernetes/static-pod-certs

37.8 Automation und Orchestrierung

37.8.1 Backup-Policy-Engines

Backup-Policy-Engines implementieren regelbasierte Backup-Zeitplanung mit Anwendungs-Tagging:

# Kasten Policy für automatisierte Backups
apiVersion: config.kio.kasten.io/v1alpha1
kind: Policy
metadata:
  name: gold-tier-backup-policy
  namespace: kasten-io
spec:
  comment: "Gold-Tier Applications - Daily Backup, 30-day retention"
  frequency: "@daily"
  retention:
    daily: 30
    weekly: 12
    monthly: 12
  selector:
    matchLabels:
      backup-tier: gold
  actions:
  - action: backup
    backupParameters:
      profile:
        name: s3-backup-profile
        namespace: kasten-io
  - action: export
    exportParameters:
      frequency: "@weekly"
      profile:
        name: s3-export-profile
        namespace: kasten-io
      receiveString: "s3://dr-backup-bucket/exports"

37.8.2 Workflow-Orchestrierung

Workflow-Orchestrierung koordiniert komplexe Backup-Operationen über mehrere Komponenten:

# Argo Workflow für komplexes Backup
apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: enterprise-backup-workflow
spec:
  entrypoint: backup-pipeline
  templates:
  - name: backup-pipeline
    dag:
      tasks:
      - name: pre-backup-validation
        template: validate-cluster
      - name: database-quiesce
        template: quiesce-databases
        depends: pre-backup-validation
      - name: application-backup
        template: backup-applications
        depends: database-quiesce
      - name: metadata-backup
        template: backup-metadata
        depends: pre-backup-validation
      - name: etcd-backup
        template: backup-etcd
        depends: pre-backup-validation
      - name: post-backup-validation
        template: verify-backups
        depends: application-backup && metadata-backup && etcd-backup
      - name: cleanup-and-notify
        template: cleanup-notification
        depends: post-backup-validation
        
  - name: validate-cluster
    script:
      image: kubectl:latest
      command: [bash]
      source: |
        # Cluster-Health-Check
        kubectl get nodes | grep -q "Ready" || exit 1
        # Storage-Verfügbarkeit prüfen
        kubectl get pv | grep -q "Available\|Bound" || exit 1
        echo "Cluster validation passed"
        
  - name: backup-applications
    script:
      image: velero/velero:latest
      command: [bash]
      source: |
        # Velero-Backup mit Labels
        velero backup create automated-backup-$(date +%Y%m%d-%H%M) \
          --selector backup-enabled=true \
          --wait

37.9 Cost-Optimierung und Lifecycle-Management

37.9.1 Storage-Tier-Migration

Storage-Tier-Migration für Backup-Daten implementiert automatische Datenverschiebung zwischen Storage-Tiers:

# S3 Lifecycle Policy für Backup-Optimierung
apiVersion: v1
kind: ConfigMap
metadata:
  name: s3-lifecycle-config
data:
  lifecycle.json: |
    {
      "Rules": [
        {
          "ID": "BackupLifecycle",
          "Status": "Enabled",
          "Filter": {
            "Prefix": "backups/"
          },
          "Transitions": [
            {
              "Days": 30,
              "StorageClass": "STANDARD_IA"
            },
            {
              "Days": 90,
              "StorageClass": "GLACIER"
            },
            {
              "Days": 365,
              "StorageClass": "DEEP_ARCHIVE"
            }
          ],
          "Expiration": {
            "Days": 2555  // 7 Jahre für Compliance
          }
        }
      ]
    }

37.9.2 Retention-Policy-Automation

Retention-Policy-Automation implementiert automatische Backup-Löschung basierend auf Alter und Compliance-Anforderungen:

#!/bin/bash
# Backup-Retention-Management-Script

BACKUP_LOCATION="s3://backup-bucket"
DAILY_RETENTION=30
WEEKLY_RETENTION=12
MONTHLY_RETENTION=12
YEARLY_RETENTION=7

# Tägliche Backups bereinigen (> 30 Tage)
aws s3api list-objects-v2 \
  --bucket backup-bucket \
  --prefix "daily/" \
  --query "Contents[?LastModified<'$(date -d "-${DAILY_RETENTION} days" --iso-8601)'].Key" \
  --output text | \
  xargs -I {} aws s3 rm s3://backup-bucket/{}

# Wöchentliche Backups bereinigen (> 12 Wochen)  
aws s3api list-objects-v2 \
  --bucket backup-bucket \
  --prefix "weekly/" \
  --query "Contents[?LastModified<'$(date -d "-${WEEKLY_RETENTION} weeks" --iso-8601)'].Key" \
  --output text | \
  xargs -I {} aws s3 rm s3://backup-bucket/{}

# Cost-Report generieren
aws s3api list-objects-v2 \
  --bucket backup-bucket \
  --query 'Contents[*].[Key,Size,StorageClass]' \
  --output table

37.10 Security und Compliance-Integration

37.10.1 Verschlüsselung und Zugriffskontrolle

Encryption-at-Rest für Backup-Daten gewährleistet Datenschutz durch kryptographischen Schutz gespeicherter Backup-Daten:

# Verschlüsselte Backup-Konfiguration
apiVersion: velero.io/v1
kind: BackupStorageLocation
metadata:
  name: encrypted-backup-location
spec:
  provider: aws
  objectStorage:
    bucket: encrypted-backup-bucket
    prefix: cluster-prod
  config:
    region: us-west-2
    # KMS-Verschlüsselung
    kmsKeyId: "arn:aws:kms:us-west-2:123456789012:key/12345678-1234-1234-1234-123456789012"
    serverSideEncryption: AES256
    # Access-Control
    checksumAlgorithm: CRC32C

37.10.2 Compliance-Reporting

Automated Compliance-Reports für regulatorische Audit-Unterstützung:

# Compliance-Report-Generator
apiVersion: batch/v1
kind: CronJob
metadata:
  name: compliance-reporter
spec:
  schedule: "0 9 1 * *"  # Monatlich
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: reporter
            image: compliance-reporter:latest
            env:
            - name: REPORT_TYPE
              value: "SOX_COMPLIANCE"
            command:
            - /bin/bash
            - -c
            - |
              # Backup-Compliance-Report generieren
              echo "Backup-Compliance-Report für $(date +%B\ %Y)"
              echo "=================================="
              
              # RTO/RPO-Compliance prüfen
              velero backup get --output json | jq -r '
                .items[] | 
                "Backup: \(.metadata.name), Erstellt: \(.metadata.creationTimestamp), Status: \(.status.phase)"
              '
              
              # Verschlüsselungs-Compliance
              aws s3api head-object --bucket backup-bucket --key latest-backup.tar.gz | \
                jq '.ServerSideEncryption'
              
              # Retention-Compliance
              find /backup-reports -name "*.json" -mtime -30 | wc -l

37.11 Single-Node-Backup-Überlegungen

37.11.1 Lokale Backup-Storage-Integration

Local-Backup-Storage-Integration für Single-Node-Umgebungen nutzt lokale Storage-Ressourcen für vereinfachte Backup-Infrastruktur:

# Lokales Backup für Single-Node
apiVersion: v1
kind: PersistentVolume
metadata:
  name: local-backup-pv
spec:
  capacity:
    storage: 500Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-backup
  local:
    path: /mnt/backup-storage
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - single-node-host

---
# Backup-Job für Single-Node
apiVersion: batch/v1
kind: CronJob
metadata:
  name: local-backup
spec:
  schedule: "0 3 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: backup-tools:latest
            command:
            - /bin/bash
            - -c
            - |
              # Lokales tar-Backup aller PVCs
              for pvc in $(kubectl get pvc -o name); do
                kubectl cp ${pvc#*/}:/data /backup/$(date +%Y%m%d)-${pvc#*/}.tar.gz
              done
              
              # Alte Backups bereinigen (> 14 Tage)
              find /backup -name "*.tar.gz" -mtime +14 -delete
            volumeMounts:
            - name: backup-storage
              mountPath: /backup
          volumes:
          - name: backup-storage
            persistentVolumeClaim:
              claimName: local-backup-pvc

37.11.2 Ressourcen-schonende Backup-Zeitplanung

Resource-Constraint-Aware-Backup-Scheduling berücksichtigt begrenzte Ressourcen in Single-Node-Umgebungen für nicht-störende Backup-Operationen:

# Ressourcen-schonender Backup-Job
apiVersion: batch/v1
kind: CronJob
metadata:
  name: lightweight-backup
spec:
  schedule: "0 2 * * *"  # Nachts bei niedriger Last
  jobTemplate:
    spec:
      template:
        spec:
          # Niedrige Priorität für Backup-Jobs
          priorityClassName: low-priority
          containers:
          - name: backup
            image: restic/restic:latest
            resources:
              requests:
                cpu: 100m      # Minimale CPU-Nutzung
                memory: 128Mi  # Geringer Memory-Footprint
              limits:
                cpu: 500m      # CPU-Limit für System-Schonung
                memory: 512Mi
            env:
            - name: GOMAXPROCS
              value: "1"       # Nur einen CPU-Kern nutzen
            command:
            - /bin/sh
            - -c  
            - |
              # Nice-Level für niedrige Priorität
              nice -n 19 restic backup /data \
                --limit-upload 10240    # 10MB/s Upload-Limit
                --limit-download 10240  # 10MB/s Download-Limit