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.
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.
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
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]
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"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-pvcStorage-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: trueCeph 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"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
EOFPre-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: ContinueQuiescing-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-configMulti-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"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-pvcDeduplication-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: 5Replikationsbasierte 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"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 30dBackup-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"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)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"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-certsBackup-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"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 \
--waitStorage-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
}
}
]
}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 tableEncryption-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: CRC32CAutomated 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 -lLocal-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-pvcResource-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