Backup- und Replikationsstrategien

Kurze Zusammenfassung

Eine robuste Datenstrategie steht auf drei Säulen: Backup, Replikation, Recovery. Das Replikat reduziert die RTO (Recovery Time), das Backup garantiert RPO (Data Loss) und schützt vor logischen Fehlern/Ransomware. Grundprinzipien: 3-2-1-1-0 (3 Kopien, 2 Arten von Medien, 1 ist Offsite, 1 ist unveränderlich, 0 Fehler bei Inspektionen), regelmäßige DR-Tests und Immutabilität kritischer Sets.

Begriffe und Ziele

RPO - wie viele Daten können verloren gehen (z. B. ≤ 5 Minuten).
RTO - wie viel Zeit ist zulässig, um wiederherzustellen (zum Beispiel ≤ 15 Minuten).
PITR (Point-in-Time Recovery) - Wiederherstellung „zum Zeitpunkt X“ mit einem Replikat der Protokolle.
SLO von Daten ist ein Service-Level-Vertrag für RPO/RTO und den Erfolg von Backup-Aufgaben.

Beispiel einer Matrix:

Datenklasse	RPO	RTO	Die Anmerkungen
Transaktionen/Wallet	≤ 1-5 min	≤ 5-15 min	Protokolle + synchrone Kernel-Replikation
Berichterstattung/PII	≤ 1 h	≤ 1 h	WORM/immutability, Archiv
Protokolle/Rohereignisse	≤ 24 h	≤ 4 h	Objekt, lifecycle

Fehlertoleranz und Replikationsmodelle

Topologievarianten

Aktiv-Passiv (heiß/warm/kalt): einfachere, vorhersehbare Failover.
Active-Active: hohe Verfügbarkeit, aber komplizierter als Konflikt-Resolve und Konsistenz.
Multi-Zone/Region/Cloud: Ausgleich von Verzögerungen und Kosten.

Synchron vs Asynchron

Synchron: RPO≈0, höhere Latenz, Entfernungsbegrenzung.
Asynhron: nahe Null RTO mit kleinem RPO (Minuten), widersteht Regionen/Wolken.
Hybrid: Synchron innerhalb der Zone, Asynchron in die entfernte Region.

Replica ≠ Backup

Das Replikat trägt Fehler/Löschungen nach der Quelle. Backup - Off-Path-Kopie mit Versionierung, Prüfungen und Isolierung.

3-2-1-1-0-Richtlinie und Unbeweglichkeit

3 Kopien (Prod + Local Backup + Offsite).
2 Medientypen (Block/NAS/Objekt/Bänder).
1 Offsite (andere Site/Cloud/Band).
1 unveränderliche Kopie (WORM: Object Lock, immutable snapshots/tape).
0 Fehler: regelmäßige Integritätsprüfung (checksum/verify/restore-Tests).

Praxis:

Aktivieren Sie Versionierung und Objektsperre (Compliance/Governance) für Objekte mit kritischen Backups.
Für NAS/Blöcke - immutable Snapshots mit Retention und Löschverbot bis zur Deadline.

Arten von Backups und Zeitplänen

Full ist eine vollständige Kopie.
Incremental - nur Änderungen vom letzten Backup.
Differential - Änderungen seit der letzten vollständigen.
Forever-incremental mit GFS-Plan (Grandfather-Father-Son): Tagesinkremente, wöchentliche und monatliche „Synthetic Full“.

Empfehlung (Beispiel):

Prod DB: täglich voll (oder synthetisch voll), Inkremente/Protokolle alle 5-15 Minuten (PITR).
Dateiserver: Wöchentlich voll, täglich inkrementell, monatlich archiviert.
Objekt: lifecycle + Versionen; cold - in die Archivspeicherklasse/Band.

Anwendungen und DB: PITR-Praktiken

PostgreSQL

Aktivieren von WAL-Archivierung und Basis-Backup; PITR über 'restore _ command'.
Werkzeuge: 'pgBackRest', 'wal-g' (Objekt), 'pg _ basebackup' für vollständig.
Trennen von Volumes: Daten und WAL; WAL auf schnelle NVMe mit PLP schreiben.

MySQL/MariaDB

Binäres Log für PITR, komplett über 'Percona XtraBackup' (Hot Backup).
GTID-Replikation; für DR - asynchron in die Region/Cloud.

MongoDB

Oplog für PITR; Schnappschüsse auf Thorajebene + 'mongodump' für logische Kopien.
Testen Sie die Konsistenz des Replikats vor dem Backup.

Redis/Caches

Nicht als Backup betrachten: Halten Sie RDB/AOF + Offsite; Wiederherstellen als Warm-Cache oder von der Quelle der Wahrheit.

Kubernetes und Container

etcd Cluster - ein separates kritisches Ziel (häufige Schnappschüsse, Offsite).
Velero: Backup von Manifesten/Ressourcen + CSI-Snapshots/PV; Speicherung in einem S3-kompatiblen Baquet (mit Object Lock).
Stateful-Loading: app-consistent snapshots (pre/post hooks), ansonsten crash-consistent.
Versionierung von Objektartefakten (Modelle/Medien) - auf Baket-Ebene.

Virtualisierung und Dateiserver

VM-Snapshots: Verwenden Sie CBT (Changed Block Tracking), speichern Sie Offsite, machen Sie regelmäßig Guest-Aware Quiesce (VSS für Windows).
Dateiserver (NAS): Snapshots + Replikate und regelmäßige Katalog-Restore-Tests (Datei-Sampling).

Sicherheit für Backups

Verschlüsselung im Ruhezustand (LUKS/ZFS/Cloud KMS/Vault) und während der Übertragung (TLS/mTLS).
Schlüsselmanagement: Einzelrollen, Dual-Control, Rotation, Offline-Schlüsselablage.
Isolation: Backup-Software-Konten ohne Rechte zum Löschen von unbeweglichen Kopien; getrennte Netzwerke/VLANs.
Ransomware-Resistenz: immutable, air-gap (Bänder/isoliertes Konto/Labor).
Audit: Protokoll der Back-up-System-Operationen, Warnungen über die Entfernung/Reduzierung retenschno.

Planen von Fenstern und Bandbreite

Backup-Fenster vs Last: I/O/Netzwerk-Trottling, Deduplizierung, Kompression.
Netzwerk: Inkremente alle N Minuten, einzelne Kanäle/VPN, Nachbau bei Nacht oder dauerhaft mit QoS.
Change Block Tracking/CDC zur Reduzierung des Datenverkehrs.
Große Basen: parallele Streams/Streaming, Mehrkanalmultipart zum Objekt.

Überwachung, Metriken und SLOs

Tech-Metriken:

Erfolg der Backup-/Replikationsaufgaben (%), Dauer, Geschwindigkeit, Log-Lag (WAL/binlog/oplog).
Speicherplatz für Backups, Dedup-Faktor, sonstige Kosten.
Zeit und Erfolg der Testerholungen.

SLO (Beispiel):

Erfolgsquote der Backups ≥ 99. 9 %/30 Tage.
RPO wird ≥ 99% der Zeit eingehalten (Log-Lag ≤ Ziel).
RTO (Test Restore) ≤ 15 Minuten für die Brieftasche ≤ 1 Stunde für die Berichterstattung.
Monatlicher DR-Drill: 100% der Routineszenarien sind abgeschlossen.

Alerts:

Verpasstes/fehlgeschlagenes Backup, PITR-Lag> Schwellenwert, sinkender Deduplizierungsgrad, Platzmangel, Änderung der Retention-Richtlinie, kein neuer Test-Restore.

DR-Übungen und Überprüfung von Wiederherstellungen

Tabellarisch (table-top): Rollenkoordination, Kontakte, Kommunikation.
Technisch: Recovery „in die Sandbox“, RTO-Messung, Checksummen/Datenvergleich.
Black-Start: Vollständige Wiederherstellung auf „blanke Hardware/sauberer Cluster“.
Datenverzeichnisse: Vordefinierte Wiederherstellungsschritte (Runbooks) für jede Systemklasse.
Automatisierung: periodische „kanarische“ Wiederherstellung und Abstimmung von Prüfsummen.

Praktische Vorlagen

1) PostgreSQL (pgBackRest + WAL-Archiv zum Objekt)

ini
[global]
repo1-type=s3 repo1-path=/pgbackups repo1-s3-endpoint=minio. local:9000 repo1-s3-bucket=pg-wal repo1-s3-key=ACCESSKEY repo1-s3-key-secret=SECRET repo1-retention-full=8 start-fast=y compress-type=zst

2) wal-g (Beispiel ENV)

bash export WALG_S3_PREFIX=s3://pg-wal/prod export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export WALG_COMPRESSION_METHOD=zstd

3) Velero (K8s - Objekt + Unbeweglichkeit des Baketts)

yaml apiVersion: velero. io/v1 kind: BackupStorageLocation metadata: { name: default, namespace: velero }
spec:
provider: aws objectStorage:
bucket: k8s-backups config:
s3Url: https://minio. example s3ForcePathStyle: "true"
publicUrl: https://minio. example

4) Object Lock Policy (Beispiel 'mc')

bash mc version enable my/backups mc retention set --default COMPLIANCE 365d my/backups

5) Beispiel GFS-Zeitplan (Konzept)

Täglich: Inkremente alle 15 Minuten (Zeitschriften), täglich synthetisch voll.
Wöchentlich: eine „voll“ (synthetisch), 8 Wochen lagern.
Monat: vollständig, 12-24 Monate speichern (Archiv/Band).

Checkliste für die Implementierung

Definierte Datenklassen, Eigentümer, RPO/RTO/SLO.
Ausgewählte Replikations- (sync/async) und Topologiemodelle (AZ/Region/Cloud).
Backups konfiguriert: full/incremental/PITR, Zeitpläne, Verzeichnisse.
Immutability (WORM/Object Lock/immutable snapshots) und Offsite/air-gap sind enthalten.
Verschlüsselung und KMS/Vault, getrennte Rollen und Schlüsselrotationen.
Monitoring: Aufgabenerfolg, Log-Lag, Ort, Test-Restore; Alertas.
Runbooks Wiederherstellung und Failover; Kontakte, Eskalationen, Kommunikationsmuster.
Monatliche DR-Übungen + Bericht, Anpassung der Pläne.
Budget und FinOps: Speicherkosten/egress, Archivierungs-/Tiering-Projekt.

Typische Fehler

„Die Replik ist da - kein Backup nötig“: Logische Löschungen und Verschlüsselungen gehen auf die Replik.
Keine Wiederherstellungstests - Backup existiert „theoretisch“.
Das Fehlen von Immutabilität und Offsite ist ein einziger Risikopunkt.
Das gleiche Konto/Schlüssel für Prods und Backups - kompromittieren = alles verlieren.
Zu lange Backup-Fenster → Konflikt mit Spitzen; kein Trotting und QoS.
PITR ohne Log-Lag-Kontrolle.
Ignoriere app-konsistente Snapshots - „schmutzige“ wiederherstellbare Volumes.

Spezifität für iGaming/Fintech

Geldbörse/Zahlungskern: RPO ≤ 1-5 min, RTO ≤ 15 min; Logs (WAL/binlog) in ein Objekt mit WORM; Synchron in der Zone + Asynhron Region.
Berichterstattung/Regulierung: unveränderliche Speicherung, lange Retention (Jahre), überprüfbare Integrität, klare Verfahren für die Datenfreigabe an die Regulierungsbehörden.
Die Hohlwege/feuchten Ereignisse/antifrod: der billige langlebige Aufbewahrungsort (ob'ektka) + lifecycle; Indizes und Vitrinen - getrennt.
Peaks (Matches/Turniere): Backup-Fenster außerhalb der Peaks, throttling; DR-Pläne für den Zeitraum der Ereignisse; kanarische Restore vor Aktien.

Summe

Datenschutz ist eine architektonische Disziplin: 3-2-1-1-0, Versionierung und Immutabilität, RPO/RTO als SLO, regelmäßige DR-Übungen und Faktencheck-Recovery. Kombinieren Sie die Replikation für Aptyme und schnelle Failover mit Backups für logische Fehler und Kompromisse. Automatisieren, messen, dokumentieren - und Sie haben immer einen Arbeitsweg zurück, auch am schlechtesten Tag.